Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Choose Primitives for Typelevel and Meta Programming in Scala 3.0 #5086
Over the summer, we investigated a range of techniques to do typelevel and meta programming in
These are valuable experiments, but we still have to settle on a set of techniques to support in Scala 3.0. As always, we want a minimal set of constructs that covers the use cases we envision.
We classify use cases according to their priority.
These should definitely be supported:
These are "good to haves" if they are natural fits for the techniques we consider:
These are probably out of scope for Scala 3.0, but might become interesting at some point in the future:
To evaluate a combination of techniques, we should consider the following concerns.
Note that some of these concerns conflict each other (e.g. 3/4).
A first classification of techniques is whether they support data generic programming through generic code, or/and whether they support specialization of code to specific types. Specialization is important for efficiency. The covered techniques support these as follows:
Quotes & splices are a given since they support blackbox macros and code introspection. My current tendency is to also take match types as a given. They are the only technique that ensures
Match types can be combined with rewrite methods or typeof to achieve data genericity, but one might also use them with normal code, if we can come up with good typing rules that link match expressions with match types. So I believe further evaluation is needed whether match types should be complemented by some other typelevel technique, or whether they are good enough alone.
That leaves specialization. The minimalist standpoint here would be to use quote&splice for that, since we have it already. On the other hand, rewrite matches provide a lot of expressive power and convenience for specializing code (e.g. see how generic tuples can be specialized in #4964, file
A Strawman Proposal
It's quite a bit of work, so we should discuss whether that's what we want before embarking on an implementation.
Why Drop Rewrite Methods?
Since I worked for much of the summer on rewrite methods, and pushed them to the point where they are now merged into master, I should explain why I now advocate dropping them.
Points in favor of rewrite methods:
However, there are also downsides:
The main motivation to drop rewrite methods would be the adoption of match types. If we have match types, then rewrite methods become largely redundant. They overlap with match types in their generative aspects and they overlap with quotes&splices in their specialization power. Occam's razor then would suggest dropping them.
I mentioned in a meeting that these issues relates to GADTs — I ran into #4176 which is a partial example (tho not perfect) — it's a failed attempt to write length-indexed vectors with pure GADTs.
Two questions from the unwashed masses: