Two macro-related feature requests

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Two macro-related feature requests

Cauê W.
Hey guys!

I'm working heavily with macros for some time now, and I have two feature requests that would be great to include when working with macros:

  • I don't know how difficult it is, but it would be awesome if the macro interpreter could work by lazily parsing what it needs as it interprets. This way there would be almost no more context-related problems because of forgotten #if macro constructs, and in the end it could run faster. Somehow related, if there was a way to dynamically import classes on the macro parser, it would be great. Context.getType() will only add the type to the build context. By now I'm doing a hack, which makes a macro call inside a macro context that will return the types that I want to dynamically import. But this only works for my special case, because I already know all classes I will need at that point.
  • The possibility to have metadata on function arguments, and specially on code expressions. This could only work in a macro context, or follow the @: convention for passing compiler parameters. This would actually be an awesome feature to have also for the fully typed expression on the targets, so we can annotate certain expressions in a better way.

Really thanks! It's been so awesome to work with haxe + macros!
Cauê

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Two macro-related feature requests

Matthew Spencer-2

+1.

On Oct 16, 2011 10:43 AM, "Cauê Waneck" <[hidden email]> wrote:
Hey guys!

I'm working heavily with macros for some time now, and I have two feature requests that would be great to include when working with macros:

  • I don't know how difficult it is, but it would be awesome if the macro interpreter could work by lazily parsing what it needs as it interprets. This way there would be almost no more context-related problems because of forgotten #if macro constructs, and in the end it could run faster. Somehow related, if there was a way to dynamically import classes on the macro parser, it would be great. Context.getType() will only add the type to the build context. By now I'm doing a hack, which makes a macro call inside a macro context that will return the types that I want to dynamically import. But this only works for my special case, because I already know all classes I will need at that point.
  • The possibility to have metadata on function arguments, and specially on code expressions. This could only work in a macro context, or follow the @: convention for passing compiler parameters. This would actually be an awesome feature to have also for the fully typed expression on the targets, so we can annotate certain expressions in a better way.

Really thanks! It's been so awesome to work with haxe + macros!
Cauê

--
haXe - an open source web programming language
http://haxe.org

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Two macro-related feature requests

Nicolas Cannasse
In reply to this post by Cauê W.
Le 16/10/2011 19:41, Cauê Waneck a écrit :
> Hey guys!
>
> I'm working heavily with macros for some time now, and I have two
> feature requests that would be great to include when working with macros:
>
>   * I don't know how difficult it is, but it would be awesome if the
>     macro interpreter could work by lazily parsing what it needs as it
>     interprets.

That is actually not possible with the way the compiler works now. In
particular because before being executed, the macro code needs to be
actually typed, which requires all dependent types to be included.

That is why I'm keeping the package restrictions in macro mode while we
could have had some kind of stub class generated that would throw
runtime error only when accessed. Doing so would not encourage users to
separate macros from actual code and make them slower because of the
double typing + compilation it would require.

>     Somehow related, if there was a way to
>     dynamically import classes on the macro parser, it would be great.
>     Context.getType() will only add the type to the build context. By
>     now I'm doing a hack, which makes a macro call inside a macro
>     context that will return the types that I want to dynamically
>     import. But this only works for my special case, because I already
>     know all classes I will need at that point.

Same remark here : we could _maybe_ add classes dynamically to the macro
side but they would then not be accessible (unless you're using only
reflection). Using Context.getType + marking the type as extern if you
don't want it to be generated by the main context might be better.

>   * The possibility to have metadata on function arguments, and
>     specially on code expressions. This could only work in a macro
>     context, or follow the @: convention for passing compiler
>     parameters. This would actually be an awesome feature to have also
>     for the fully typed expression on the targets, so we can annotate
>     certain expressions in a better way.

Any specific reason why you would need metadata everywhere ? I mean,
with macros you can manipulate the whole expression and you can actually
encode a lot of things inside both expression and type.

The metadata is originally meant to be retrievable at runtime, which
makes it hard to add it to function parameters and impossible for
expressions.

Best,
Nicolas

--
haXe - an open source web programming language
http://haxe.org