SIP-NN: Inline/meta

inline-meta.md

Superseded by scala/docs.scala-lang#567

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.