Monadless test case - Githubissues

liufengyun / gestalt

gestalt : portable and solid macros for Scala

https://github.com/scalacenter/macros

31 stars 3 forks source link

Monadless test case #67

Closed liufengyun closed 7 years ago

liufengyun commented 7 years ago

This is an example implementation of a subset of Monadless in gestalt, the tests pass.

A list of additions in semantic API:

add WeakTypeTag
add TypedSplice
add Type.companion, Type.widen and Type.denot
add extractor and API for MethodType
add extractor for ByNameType

Some findings or changes:

Two bugs of scala.meta quasiquotes
Fix one bug about UntypedTreeMap in Dotty
Synthesise prefix if it's null for def macros
Todo: missing auto lifting from String to identifier makes quasiquote inconvenient
Fix bug in quasiquote lifting of ValDefs

liufengyun commented 7 years ago

In the implementation I found quasiquote construction doesn't work smoothly, partly due to bugs in scala.meta, partly due to missing implicit lifters or inconsistencies in the constructors. This hurts user experience a lot.

It seems macro writers never inspect the structure of TypeTrees, instead they inspect the types of TypeTrees. Dealing with types seems to be necessary, and they need to have untrivial knowledge about types, such as why there exists widen.

Another experience is that in pattern matches, using extractors is much cleaner and safer than using quasiquotes most of the time. For example, it's easy for them to forget that else branch is optional or ValDef may have modifiers.

There's one case that quasiquote-based patterns are simpler because of path select verbosity in extractors:

case q"unlift[$t]($v)"       => Some(v)
case q"$pack.unlift[$t]($v)" => Some(v)

But the above use case is problematic in def macros, doing syntactic comparison in def macros is dangerous, a safer approach is to check the symbol of the apply tree.

liufengyun commented 7 years ago

Exposing widen in the API needs a justification that it's an essential property of the language, other than some accidental stuff in a particular compiler implementation.

The justification is that singleton type is a Scala language feature, not some accidental language implementation.

Programmers also cannot use MethodType in source code, but it seems safe to assume that all Scala compilers have this type internally, which meta-programmers have to learn.

liufengyun commented 7 years ago

Regarding the usage of quasiquote in patterns, I summarize my experience below:

For trees that have modifiers and option components, extractor patterns are better, e.g. case If(cond, ifTrue, Some(ifFalse)) =>.
For trees without options, quasiquote patterns is a clear winner, e.g. case q"$fun[$tp]($v)" if isUnlift(fun.tpe) => Some(v).

I disprove myself: extractor patterns are NOT always better than quasiquote patterns. The observation above shows when they are better according to my experience.

liufengyun commented 7 years ago

@xeno-by I'd like to get this in and work on separation based on this PR. Could you please review when you have time?

@valdisxp1 Also feel free to comment and review.

xeno-by commented 7 years ago

@liufengyun Thanks for the invitation! I'll provide a review during the weekend.

xeno-by commented 7 years ago

LGTM. I will provide review in subsequent PRs. For now, we need a stable reference point, and I'm happy for it to be this.