Skip to content
This repository has been archived by the owner on Oct 12, 2019. It is now read-only.

Fix #60 :support WeakTypeTag #64

Merged
merged 2 commits into from
May 1, 2017
Merged

Fix #60 :support WeakTypeTag #64

merged 2 commits into from
May 1, 2017

Conversation

liufengyun
Copy link
Owner

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

liufengyun/dotty@f32b71f

@xeno-by
Copy link

xeno-by commented Apr 28, 2017

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
Copy link
Owner Author

liufengyun commented Apr 28, 2017 via email

@liufengyun
Copy link
Owner Author

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
Copy link
Owner Author

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
Copy link

xeno-by commented Apr 28, 2017

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
Copy link
Owner Author

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
Copy link
Owner Author

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.

@liufengyun liufengyun merged commit 413f47c into master May 1, 2017
@liufengyun liufengyun deleted the typetag branch May 1, 2017 14:32
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants