Dead (parts of) libraries in Scala 3?


#1

I see many advancements on the Scala 3 (dotty) front, but I still can’t help noticing many macro-related features that I’m directly or indirectly using and there are still no alternatives out there that are even discussed. I’ll layout the features I’m missing, so maybe someone can shed some light:

  1. illTyped from shapeless. Used for testing puposes, illTyped verifies that the specific code fed to it does not compile. It is also possible to compare the compiled error message to verify its contents. Under-the-hood the macro uses c.typecheck. Is there a viable alternative?
  2. The refined library enables (using macros) applying compile-time constraints on arguments. While most of its features may be somehow replaceable by meta-programming features of dotty, I have no idea how Eval (link) can be implemented since it uses c.eval under-the-hood.
  3. The sourcecode library provides common source code context for any program via implicit macros. Is there an alternative in dotty? Maybe somehow to reflect context-sensitive TASTY trees to the program?
  4. The singleton-ops library is the library I’m most dependent on (and help maintain).
  • It provides compile-time arithmetic/logic type/value calculations and constraints.
  • It provides a mechanism to transfer a type expression to a value expression, falling back to runtime calculations and checks if not all information is available during compile-time (see this thread).
  • It provides a mechanism to reroute compile-time @implicitNotFound error messages to the proper symbol (using this trick from shapeless).
  • It works around the compiler’s eager widening policy.
    Currently, I see no way to bridge over these gaps.

cc-ing relevant library maintainers: @milessabin, @fthomas, @lihaoyi


#2

I’m not sure about 2 and 4, but:


#3

Directly invoking the compiler is bound to be very slow compared to a macro. Macro also has access to local symbols and imports, so it’s way more convenient to test witt


#4

If it’s really useful, we could consider making it a built-in of the language.

This is very cool but way beyond what macros should be able to do I think. There’s a possibility we’ll get refinement types built-in / available via some kind of plugin (see https://github.com/gsps/dotty/commit/5ee52adde487c9ff86bf74ad6a44b70ba8fd0544 by @gsps for a preview of what this could look like).

This can be done using tasty reflection: https://github.com/dotty-staging/minitest/blob/dotty/shared/src/main/scala/minitest/api/SourceLocation.scala and imho should be built into the standard library so people don’t have to reinvent it.

This is also probably beyond what macros should be able to do, but we could consider having some of this built-in the language (experience reports on how these things are used would help a lot to make this kind of decisions!)


#5

Thanks for the feedback.

I have a huge code-base (library) that demonstrates the use-cases. I reckon I’ll publish it within the next months after I properly document and polish it.

@smarter, how do you propose I continue pursuing these (missing?) language features. Should I open tickets on the dotty tracker?


#6

Yes that’s a good idea, but each ticket should have a reasonable amount of motivation. Alternatively if you already have a precise idea of how this could be integrated into the language, you could open a pre-sip thread on contributors


#7

Like illTyped, ScalaTest has assertCompiles. It looks like it’s implemented the same way. https://github.com/scalatest/scalatest/blob/57151f83937a4adb23d402efecfe76d4c96c73ac/scalatest/src/main/scala/org/scalatest/CompileMacro.scala#L301