Implementation of the Optional macro

[liufengyun]

Implementation of the Optional macro:

https://github.com/scalamacros/macrology201/blob/part1/macros/src/main/scala/Macros.scala

[liufengyun]

Implementation of this macro shows that writing macros in gestalt is much easier than scala.reflect, as programmers don't have to deal with owners. Due to the separation of typed and untyped trees, this implementation is also much solid.

[xeno-by]

I wonder whether just using tempValDef.name should be enough here.

[liufengyun]

Actually not, because tempIdent has to be a typed tree.

[xeno-by]

Why's that?

[liufengyun]

Because transform take typed tree to typed tree.

[xeno-by]

Is the tpd => tpd transform essential to this macro, or we can be just fine with untpd => untpd?

[xeno-by]

Here's a quick idea. How about we prohibit all non-fresh/non-fullyqualified names in untyped portions of macro expansions? This will make new macros even more robust.

[liufengyun]

Yes, we should write fully qualified name, but here Optional is in the empty package.

[xeno-by]

I think we should add support for _empty_, much like we have support for _root_. Wdyt?

[liufengyun]

It seems difficult to impose this constraint in a simple and consistent way -- there are also local variables.

[xeno-by]

Best practice in macrology involves gensymming local variables. Otherwise, there's always the danger of inadvertent name capture (and, in the case of Scala, potentially import conflicts).

[xeno-by]

There is definitely a degree of inconvenience that would be imposed on macro programmers, but it'll also fix the hygiene problems that plague almost all macro tutorials and presentations.

[liufengyun]

Ah, I see -- then it means we can remove the constructors for untyped Ident and Select, then we have hygiene for free? That's a very good idea.

[xeno-by]

You could spin it like that, too. I'm not sure I fully understand the consequences of this particular implementation, but I'm really looking forward to seeing further experiments!

[liufengyun]

That's indeed a very cool idea -- we also solve the hygiene problem in the new macro system. I'll experiment on it tomorrow.

[xeno-by]

@liufengyun The new macro system is indeed significantly more robust that the old one.

What I find extremely satisfying is that all these robustness guarantees are achieved by simply separating typed and untyped trees in API signatures, without any additional APIs like currentOwner, changeOwner, newSymbol, etc.

[liufengyun]

I don't think we can avoid newSymbol, it's required to write mindless like macros to create dummy ident to be subst later.

[xeno-by]

Not trying to make any argument whether monadless should or shouldn't be supported - that'll be a different discussion. Just noted that this discussion is orthogonal to the already non-trivial benefits provided by the new macro system.

[liufengyun]

Typed to typed transform is essential. Le 15 mai 2017 19:22, "Eugene Burmako" <notifications@github.com> a écrit :

…

***@***.**** commented on this pull request. ------------------------------ In macros/src/main/scala/gestalt/macros/Optional.scala <#77 (comment)>: > + + val temp = toolbox.fresh("_temp") + val tempIdent = Ident(temp) + + q""" + val $temp = $prefix + if ($tempIdent.isEmpty) $alt else $tempIdent.value + """ + } + + def map[B >: Null](f: A => B)(implicit m: toolbox.WeakTypeTag[A] @uncheckVar): Optional[B] = meta { + import toolbox._ + + val Function(param :: Nil, body) = f + val tempValDef = ValDef(toolbox.fresh("_temp"), prefix) + val tempIdent = Ident(tempValDef.symbol) Is the tpd => tpd transform essential to this macro, or we can be just fine with untpd => untpd? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#77 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAuDyaqZTuRT9o7b8G1e93bAVoUN2M1Qks5r6InsgaJpZM4NbaQY> .

[liufengyun]

Yes, I agree it's fine to delay the support for monadless, and it's also good to delay the support for problematic extractors. Showing Optional is also a big progress.

But generally, I see there's no escape from hiding the concept type and symbol from meta-programmers. Any efforts in the direction is problematic, in my opinion.

[liufengyun]

Another observation: macro writers (including me) tend to use extractors directly in patmat a lot:

https://github.com/arosenberger/nalloc/blob/master/macros/src/main/scala/org/nalloc/bitb/kcits/macros/Inliner.scala#L50

My guess is that in patmat, extractors give us more certainty -- there's always some obscurity about what's happening behind quasiqutoes.