Expression macro method forwarding

[Simn]

HaxeFoundation/haxe-evolution#18

[back2dos]

I just reread the proposal and got a slightly different idea for implementation that requires less metadata. Since we have support for ModuleName.platform.hx I wonder if we could "simply" use ModuleName.macro.hx to host the macros for ModuleName.hx, e.g.:

//Main.hx
class Main {
    static function main() {
        js.Browser.console.log("Version " + getVersion());
    }

    static macro function getVersion();
}
//Main.macro.hx
class Main {
     static function getVersion() 
          return macro $v{haxe.Json.parse(sys.io.File.getContent('haxelib.json')).version};//or whatever
}

This would achieve a clean separation, be consistent with an existing convention and avoid having the user come up with additional names as MyMacroTools which tend to be awkward and clutter completion.

[nadako]

I remember having some idea with Module.macro.hx naming as well, but IIRC it was something about choosing the correct context for completion within macros, like if we're in a .macro.hx file, we know we need to apply macro context here, so we can have correct IDE services.

I guess these ideas complement each other and could work together quite well...

[back2dos]

I guess these ideas complement each other and could work together quite well...

Can you elaborate on how you would use them together?

[nadako]

I mean, they are not really related, you just reminded me about it :) I thought that having macro code in .macro.hx files will help compiler selecting the correct context for completion services (so it doesn't try to provide completion for non-macro functions that are actually part of macro code in a non-macro context as it does now).

I also like your idea, it looks pretty convenient, thought I'm a little concerned that one might end up with redundant modules if they want to forward to the same macro function implementation from different places.

[nadako]

I thought that having macro code in .macro.hx files will help compiler selecting the correct context for completion services

I'm now wondering, maybe that already just works through the .platform.hx mechanism...

[frabbit]

using .macro.hx to implement the macro part of a class may be possible, but macro method forwarding is much more flexible and can be used from different classes.

[Simn]

I also wonder what happens with .platform.hx. You might have to name it eval instead of macro.

On another note, maybe our planned auto-using feature could solve this as a subset.

[back2dos]

Dan:

if they want to forward to the same macro function implementation from different places.

Heinz:

macro method forwarding is much more flexible and can be used from different classes.

Me:

Is this a thing though?

That's a genuine question. How often do you use the same implementation for two different macros. I do quite often have common logic that is extracted to standalone classes, sure. But the same macro twice? On a sufficiently regular basis to warrant for a syntax that's honestly not all that self-explanatory? You'll forgive my skepticism, but the evolution proposal doesn't even mention this use case.

For me the root problem motivating the proposal is the problematic bleeding together of the macro and target context. It's a recurring problem that can scare away newbies way more than it has to (and is still rather annoying to experienced macro users). If we would simply tell them that they should put the implementation of their macros in a .macro.hx file, it's something that is easy to communicate and to follow. Certainly trumps "put your implementation in another class and reference it with @:forwardMacro(full.path.to.that.Class.theImplementation)" ... would you not agree?

It's not like the features are mutually exclusive. But if the .macro.hx approach sufficiently covers the relevant use cases for @:forwardMacro (which is something you should answer realistically) then I would suggest to settle for just the former.

---

I also wonder what happens with .platform.hx. You might have to name it eval instead of macro.

Yup, I've checked it works with .eval.hx, but I think that's unfortunate:

1. the name of the interpreter is an implementation detail
2. the .eval.hx file is also used if your target platform is eval (for --run/--interp), which means the separation fails.

[frabbit]

Well ok, in my special case i have a macro that merges static APIs, it also has to do with the limited abilities of the module/import system. It works very good for static methods, but for macros i have to add them piece by piece to the api. The following example should make that clear (Source and Source 2). The idea is that you can build your api in a modular way, but have the possibility to merge them together for ease of use.

https://tryhaxe.frabbit.de/#F9373

[frabbit]

but yes, for other cases .macro.hx could work fine and i also like it.

[nadako]

I looked a bit into implementing that and the thing described by @back2dos is just working accidentally already. The only minor issue there is that the signature of the macro function is not checked for consistency with the signature of the corresponding function in the .macro.hx module, which can lead to some confusion.

So, now I wonder whether we really want @:forwardMacro then :)

[frabbit]

I still think that metadata is a much more flexible and more generic solution. It's also something that can be generated when building a class inside of a macro etc. There is currently no way to add macros to those classes, but with meta data this may be possible.

[nadako]

Okay, let's have both, but after 4.0 I guess. I'll add a test for Juraj's example though :)

[kLabz]

@nadako does this proposal still make enough sense nowadays?

With .macro.hx, using (and @:using) and such, I'm not sure what the proposal would solve (also brings some other issues).

[Simn]

I'm making the decision that we don't need this. There were doubts before, and by now we have enough tools to deal with this situation. There are also some other problems which the original proposal doesn't address, like how call arguments are to be unified between the two functions.

Not closing yet to make sure we update the haxe-evolution accordingly.

[nadako]

Yeah I think .macro.hx is sufficient, IIRC it wasn't quite working at the time when that proposal was made.