SIP-NN: Inline/meta

inline-meta.md

Superseded by scala/docs.scala-lang#567

In order to centralize the discussion, post your questions, feedback and ideas to http://gitter.im/scalameta/sips.

One request. Please abstract away any JVM specific or specific Scala implementation related things from the implementation so it remains portable to to SN and SJS.

Hello @xeno-by,

Great proposal, it's a pleasure to see the dedication that you've put into it and how detailed the explanations are!

As the SIP Process Lead, I'd like to point out some minor issues before you submit this as an official SIP. Most of them are regarding the format, because the contents are excellent. I find that we could somehow manage without the language features section. It is important, but I would suggest putting it into an independent document and pointing to it from the official proposal, so that people who actually read this one get a general idea of what you propose without getting into all the details. That is, a structure more akin to the SIP/SLIP process template. I would also clarify some of the current shortcomings, like the conflict between toString and decodedName.

On a side note, I would suggest creating a repo showcasing your example's old macros-based implementation, so that people unfamiliar with Scala Reflect can get a feeling of how it works and compare it with the proposed system. In the future, when a full-fledged implementation for Meta exists, you can update that repo with the new implementation. Having everything on a runnable project will concisely explain the design differences and how simple Scala Meta is. Note that this is not a requirement, just a suggestion.

Having said this, I would invite you to submit the final draft to the SIP Committee so that we can study it as soon as possible. There's no time to waste! The time flies and the Scala community craves for a better way of doing metaprogramming.

Attentively,
Jorge

Hi Eugene,

Thanks for writing such a detailed summary of what's been going on - I enjoyed reading it. Nice work!
Here are some of my comments:

• In Intuition, you write Select and Map interchangeably.

• One of the big problems with writing macros was source location for error messages. A syntax or type error after macro expansion did not show where the error is, only the callsite of the macro. As a result, macro writers had to print and manually analyze entire expanded ASTs, while macro users could only try randomly refactoring their code. Is this being addressed?

• In the current macro world, one had to frequently untypecheck the AST, because mixing already typed ASTs coming from the macro callsite, and untyped ASTs constructed in the macro definition, resulted in typechecking errors. On the other hand, calling untypecheck discarded the much needed type information (and it resulted in hacks like this, used to implement an artificial typer). Will this be addressed in the new API?

• In the inline/meta section, why the import scala.meta._ inside the meta block? Could it not have been imported at the top-level?

• Does the new API expose information about whether a parameter is by-name (for example, when we're matching a def tree)?

• About inlining by-name parameters - "while by-name arguments remain as they were" - does this mean that occurrences of by-name parameters in the inlined method are replaced with the argument expressions when inlining the method? Maybe an example would be useful here.

• Composability of inline methods - can an inline method call another inline method? Or this only possible inside meta blocks, by using the tree transformers induced by inline methods?

• How does one write generic macros with respect to different arities? While full whiteboxity is probably a bad idea, it seems useful to be able to adapt a function with arity N into an equivalent class with a single method of arity N - e.g. to implement SAM types, coroutines, or do function type lifting?

• Can some of the use-cases for whitebox macros be covered with type-parametrized inline methods, where the type parameter is inferred only after expansion? I.e. something like this:

  inline def foo[T](typeName: String): T = meta {
    q"new $typeName$
  }
  

  In other words, can delayed type-inference of the return type help with simplifying the interaction of the macro expansion and the typechecker?

Cheers,
Alex

@axel22 Really sorry for not noticing your message before. It looks like gists don't notify authors about comments. I will answer to your comments tomorrow.

1. That's a typo.

2. We plan to handle this via facilities for interactive macro expansion in IDEs. With these facilities, it should become possible to expand macros on case-by-case basis, seeing exactly what's wrong with macro expansions using the standard "red squiggles" idiom of the IDE workflow.

3. We plan to address this with scala.meta, because its language model doesn't have the problems of owner chain corruption. Additional experimentation is required to see how far we can get. I'm fairly optimistic.

4. Yes, the import could be moved to the top level without any change to the semantics of the code.

5. Yes, it will.

6. Yes, you're right. I will provide more examples here.

7. It is possible to call inline methods inside the bodies of inline methods.

8. Could you provide an example of what you'd like to achieve?

9. This handles applications 1, 3 and 4 of whiteboxity, which are the most important ones anyway. Dynamic manipulation of availability of implicits wouldn't be covered, but maybe that's not something that we want to support in the future.

I'd like to ask everyone to use the gitter link above for discussion. I don't get notifications about comments, so it is possible that I won't notice your feedback in a timely manner.