search

waneck / testrepo

0 stars 0 forks source link

Issue 1805 - TMeta - haxe #1805

Open waneck opened 11 years ago

waneck commented 11 years ago

[Google Issue #1805 : http://code.google.com/haxe/issues/detail?id=1805] by si...@haxe.org, at 2013-05-10T11:55:13.000Z Should be introduce an equivalent of EMeta for the typed AST? It could carry some information through to the code generators, where we could replace some of the current hack methods.

I can think of some other use cases as well, e.g. retain some information when inlining fields or preserve expressions when "using" a macro.

waneck commented 11 years ago

[comment from waneck, published at 2013-05-10T11:58:47.000Z] I'd really like to see this implemented! untyped something() feels very awkward, we may lose typing of everything that's inside, and now that Void types aren't allowed by Haxe, it's sometimes a little hard to box some platform-specific code into a function. Take for example, cs.Lib.fixed ( https://code.google.com/p/haxe/source/browse/trunk/std/cs/Lib.hx#189 ). I had to use type parameters to be able to let the typer allow void expressions there. ;)

waneck commented 11 years ago

[comment from ncanna...@gmail.com, published at 2013-05-10T12:30:17.000Z] I'm fine with TMeta, but I don't think we should do too much replacements of hack methods, or maybe only the ones that are not used by end users, the most rare ones. Also, it only works if the hack method has a single parameter (or else using @:hack [p1,p2,p3], but it seems a bit abusive call syntax)

waneck commented 11 years ago

[comment from si...@haxe.org, published at 2013-05-10T14:23:33.000Z] Implementation-wise, my main concern is that this means respecting TMeta in every matched pattern in the generators, and then recurse. While this is no problem for most of the matches, it's easy to miss this on matches expecting certain patterns and defaulting to something on _.

I'm not sure how feasible this really is.

waneck commented 11 years ago

[comment from waneck, published at 2013-05-10T14:31:30.000Z] Maybe what we could do is have a filter pass that will only maintain the platform's specific metadata. In the case where platform-specific metadata applies, a match would be missed anyway if untyped behaviour was used. In order to avoid having yet another filter pass, we could add as part of Codegen.filters that already run before the target. We could register relevant keywords by using platform_config

waneck commented 11 years ago

[comment from ncanna...@gmail.com, published at 2013-05-10T14:50:31.000Z] @Simon : I think that's already (the (case (for (parenthesizes))))

waneck commented 11 years ago

[comment from si...@haxe.org, published at 2013-05-10T15:11:48.000Z] I guess you're right, looking for TParenthesis matches should yield all cases where this kind of recursion is necessary.