Fix #60 :support WeakTypeTag

[liufengyun]

Fix #60: Together with following commit, this implements compile-time WeakTypeTag.

https://github.com/liufengyun/dotty/commit/f32b71f11c5794e21c1930b4ff873b71b64fbc27

[xeno-by]

Continuing the discussion from #60. Why don't we bring M and Monad from that example into scope? Either by creating synthetic parameters in advance in the implementation method, or by changing the macro typechecker to create these parameters on demand.

[liufengyun]

It's not clear to me how to compile the example with separate compilation in a simple way. For example, how to bring it in to scope, or what are the typing rules to synthesize it as a type tree. To me, WeakTypeTag seems to be the simplest and consistent way to achieve the goal. And I see no drawbacks doing it. Le 28 avr. 2017 20:08, "Eugene Burmako" notifications@github.com a écrit :

Continuing the discussion from #60 https://github.com/liufengyun/gestalt/issues/60. Why don't we bring M and Monad from that example into scope? Either by creating synthetic parameters in advance in the implementation method, or by changing the macro typechecker to create these parameters on demand.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/liufengyun/gestalt/pull/64#issuecomment-298068046, or mute the thread https://github.com/notifications/unsubscribe-auth/AAuDyaz8PCgAlKL_AL6p06EDcyWuonasks5r0is6gaJpZM4NLwJ2 .

[liufengyun]

I just found that the nice way of doing this is that we actually don't need to change the compiler, the macro transform rule remains simple, the API protocol to macro writers is simple as well.

If we try to do some automatic synthesising, I guess we need to do free type variable analysis first, and it complicates the scoping rule of what's accessible in the meta block. I think it's good to make the scoping rule simple and stupid to protect macro writers from insane errors.

[liufengyun]

This TypeTag they are just compile-time, it's impossible for programmers to abuse them at runtime or non-macros context. They are platform-independent.

[xeno-by]

This exemplifies the tradeoff between implementor and user simplicity that we also faced with reflect macros.

Sure, we may require users to write typetags explicitly (if we go that way, then for consistency reasons, we should also require typetags for the type parameters of inline methods). This will make our lives easier, but that's just because we delegated the burden to the users.

In reflect, we often made decisions that optimized implementation simplicity, and I don't like where it got us. I think we can and should do better in the new macro system.

[liufengyun]

Inline doesn't have separate compilation, so I guess it's much simpler to do. Also, I think inlining is itself a robust meta-programming feature, there's no need to for it to be related to macros (under separate compilation).

The current approach not only eases our implementation, but also means the scoping rules and API protocol are simpler for programmers. Otherwise, it's difficult to explain to meta-programmers what's accessible or not in macros -- why fields and methods cannot be accessed in macros while type members can? What type members of outer classes and constructor type params? I can foresee there's going to be many confusions and errors happen with scoping. It seems to me better to make the rule simple and stupid.

The burden current approach puts on macro writers is trivial, and only people writing advanced macros need to use that. It's very simple to use and easy to understand. Sometimes, simplicity in implementation means simplicity for users.

If we are doing a very complex and error-prone implementation, it might imply there may be something wrong with the approach.

[liufengyun]

I'm going to merge it now to continue playing with Monadless implementation. I'm happy to change it when we've more concrete and better proposals to deal with it.