Say my company wishes to sponsor the opensource work of Scala 3 macro annotations, how should we go about it?
If the funds are funneled to the Scala Center (as a one-time thing or membership), there is no “guarantee” that the relevant features comes out of it. I believe in companies directly supporting opensource work, but with a directed approach and not just “throwing around” money for good effort (supporting maintenance and general evolution is of course also very important).
Who will do this work? If the Scala Center has the funds to do so, then do they need to hire a specific person just for this task (what happens after they are done?) or wait until a developer that is currently on a payroll be free from other tasks to tend to this one? Can they outsource it as a contract work?
How can we find other companies out there that wish to join together and fund this as well?
And on the flip side, I’d love to know how people with some free time can get involved to do sponsored work on projects like this. And also what workers can expect in regard to rates, eg. does the Scala Centre just pay a flat rate or does it vary depending on the piece of work being sponsored.
Currently, the Scala Center does not really provide a framework for sponsoring work on specific projects.
There is a pool of advisory board proposals that are voted, and taken into account by the Scala Center when it comes to prioritizing the coming work. So, one thing you can currently do is to reach out to the community representatives, Bill Venners and Rob Norris, to present your idea to them, and eventually submit an advisory board proposal.
Moreover, keep in mind that, in the case of macro annotations, that touches the language itself, which makes things much more delicate than, say, implementing a third-party tool. Adding macro annotations to the language is not a light thing and needs to go to various levels of approvals. I might be digressing but I would be very interested in learning more about why you think macro annotations are a good solution for your problem compared to alternative solutions that are already available today.
That being said, assuming you could find an implementation that would not involve the Scala 3 compiler itself (e.g., as a compiler plugin, or a code generation tool like simulacrum), maybe you can investigate solutions like OpenCollective or BountySource, which have been designed for the specific use-case of directing funds towards a specific problem.
Just one simple example (there are various similar occurrences).
I need a macro annotation that changes @df class Foo into class Foo(using DFC) extends DFDesign
Because:
This is a DSL that beginners can use and I don’t want them to learn about implicit and the implicit context gets in the way of that.
This pattern occurs quite a lot, and this saves the user unnecessary boilerplate.
Code generation is not an option.
Standard Scala 3 plugins do not support this because they can only come after typer. To use nighlty/snapshots with an experimental plugin is unacceptable.
Basically, I had this working in Scala 2. In Scala 3, all options are currently blocked or not implemented. I’m willing to invest the time and funds so my (future) users will have an easier time using the DSL. How can we make this work?
Thank you for sharing your use case. I don’t know exactly what users can do with the context parameter DFC, but one thing you can do in Scala 3 is to use context functions. Users would then write:
df {
// ...
}
And, between the braces, there would be a DFC instance available.
@soronpo do you think annotation processors, like the ones existing in java land, could solve your problem? Annotation macros have the massive downside of producing non observable code, as the generated class is not something you can see. This is different to method macros which obey a method signature and in general you don’t need to see what’s in it.
Annotation processors have the advantage of producing source code and tools already work nice with automatic generated sources.
In your case, your user could write @df class FooDef and it would output (in the generated sources directory) class Foo(using DFC) extends DFDesign. If you haven’t already, please take a look at Immutables.org a java annotation processor.
Frankly, I’m 95% sure annotation macros are an instant rejection by Odersky et al, but I seem to remember they were sympathetic to code generation.
We are working on annotation macros (as part of a Master’s project). Annotations as implemented in this project will expand after typer, and their results will not be visible for other Scala code. So macro annotations effectively can only generate code that embeds Scala in a host environment. For instance by expanding @main annotations or by generating protobuf wrappers. This is by design.
If you want typer-visible changes, you need to a preprocessor. Something like Lombok. I know this will make it difficult for many projects that are worthwhile in isolation, but the decision was taken for the greater unity of the language ecosystem, which is a very important meta property.
I’m curious if the planned macro annotations would permit the @memoize macro we have internally. It transforms a def into a memoized method by adding a memoization table to the surrounding scope and changing the implementation of the def to check the table first. It’s fine if this runs after the typer because the type signature of the def does not change, but it mutates the def’s true and also adds stuff outside of its scope. None of this needs to be “visible” to other Scala code, but of course in practice it is right now.
I’m aware that there are other solutions (like learning Scalaz — Memo) and we have implemented one ourselves internally, but these solutions require changing the def to a val among other things. I’m not aware of anything as seamless as @memoize.
That’s a good test case. I don’t see why it should not work, actually. But I am not the one doing the project. That is @nicolasstucki and Zhendong Ang.
Yes, first-class support for memoization would be great! We used ConcurrentHashMaps to make it threadsafe, and I couldn’t quite tell what the plan was there. We also had an @arrayMemoize that was backed by a fixed-size array for extra performance, which I assume would be unlikely to get first-class support in the compiler though.