OSS and Professional thoughts on migrating to Scala 3

I think this hits the point of what @rgwilton and the rest of us are saying regarding simplicity. The new given system is not simple (and definitely isn’t simpler than before), and it will make it harder for people to migrate (or newly adopt Scala).

There are alternatives for making this much simpler, and I would’ve loved if someone from the SIP committee would take a look at those alternatives and actually consider them.

1 Like

Let’s take discussions about individual features in the threads where they belong. I should not to have responded to @rgwilton here, my mistake.

5 Likes

I believe it would be a huge undertaking to re-implement Scala 3 macros in Scala 2. A solution that’s simpler to implement was proposed by @dwijnand: Allow parallel Scala 3 and Scala 2 implementations of the same macro in the same source file. The effort to write these dual implementations is not worse than writing everything with Scala 3 macros if we take into account that the Scala 2 versions exist already.

That would then allow cross building libraries without separate version specific files (but maybe such versions are still needed for other reasons). I’d be interested in feedback from library maintainers whether such a feature would help in cross-building.

3 Likes

The motivation for this idea was to allow libraries to transition to the Scala 3 compiler, while still keeping Scala 2.13 support for their libraries. Kind of like an interim stage in migrating a library from Scala 2 to Scala 3.

1 Like

Where is that proposal

Apologies. I have posted my reply to Updated Proposal: Revisiting Implicits

I just don’t see how we can avoid almost completely duplicating our code bases for cross compilation due to the implicit -> given changes. This is not a minor detail. Yes we can somewhat avoid this with not changing anything and relying on Scala 2 support, but once we want to make the move into the new syntax, we might as well create a whole new branch for our libraries.

I just don’t see how we can avoid almost completely duplicating our code bases for cross compilation due to the implicitgiven changes. This is not a minor detail. Yes we can somewhat avoid this with not changing anything and relying on Scala 2 support, but once we want to make the move into the new syntax, we might as well create a whole new branch for our libraries.

implicits are still around, so for cross-building with 3.0 this will not be an issue. The intention is that as long as cross-building is widely needed, the large language subset that is common between 2 and 3 will be maintained.

Then would it be possible to leave the given implicit rework to Scala 3.1 or 3.2?

It seems this would make the switch to Scala 3 and Dotty much less controversial overall, and I think the given redesign still needs more work and experimentation.

The books can always be rewritten when Scala 3.x comes out (for a small value of x) with the new implicits, and can still be called things like “Programming in Scala 3”.

4 Likes

I too think that the new given syntax is not yet quite there.

Every time someone mentions the implicits redesign, five new proposals pop up, addressing some of the issues but introducing others. Which then leads to new proposals, and so on. This needs more time to ripen. I’d rather have it not ready for 3.0 and make sure the design is solid than rushing it and getting it wrong.

It would also make it easier to maintain code that can be compiled with both 2.13 and 3.0

5 Likes

Yes, please let’s leave the implicit redesign out until we come up with something much more unanimous.

I do wish some of the tweaks that were suggested for the existing implicit syntax would have been implemented, though.

1 Like

I believe it’s worth noting that the design of givens has been stable and in widespread use for about a year now. The only thing that changed was what terms to use for the new concepts. The semantics, by contrast has stayed the same over that time. In retrospect, I believe even the very first proposal from October 2018 (witness/with) would have been fine. Not optimal - I think we do have reached some improvements since - but acceptable and clearly better than the status quo. At some point there needs to be an end to discussions and a decision needs to be reached. I believe that point is overdue.

I do follow all comments that are made on the various threads and take them into account. I don’t reply to all of them since I do not want to monopolize the conversation and my days are finite. But if something is really interesting I even go to the length of trying a new proposal in depth by redoing all the doc and spec pages according to it. I did that at several points in the past, most recently a couple of weeks ago when I gave defaults a second chance. After all these experiments my feeling is that the current design is actually really good, and I see that feeling shared by more and more people. I know it will never be unanimous, for that current implicits are too entrenched.

7 Likes

For clarity, please can you send a pointer to the latest documentation. E.g. is it derivation.html or derivation-new.html at https://dotty.epfl.ch/docs/reference, or is it somewhere else.

Thanks,
Rob

It says so at the start of each section, e.g. for derivation.html you’ll see:

Note The syntax described in this section is currently under revision. Here is the new version which will be implemented in Dotty 0.22.

I’m not sure what you mean by “widespread use”. The whole point behind this discussion is to note how most developers migrate slowly, so I would imagine most developers do not even experiment with newly unreleased features, especially when they can only be experimented with an entire new compiler that is (currently) incompatible with most developers’ code.

This is perhaps because most of the previous alternative proposals have been focusing on minor syntactic details rather than addressing the motivation – simplifying implicits – by tackling the semantics. Again, I implore you to take a look at my alternative proposal; it views the semantics of implicits differently than before, aiming at honing the semantics towards the higher-level use cases and design patterns rather than the underlying lower-level abstractions.

1 Like

Again, I implore you to take a look at my alternative proposal;

I have already stated that I have looked in depth at all comments, including your proposal. I don’t think it goes in the right direction for the reasons @ichoran already brought up.

2 Likes

I had hoped you would’ve replied this earlier on the alternative proposal thread, as this thread is probably not the place to discuss this.

However, what’s still relevant to this discussion is how different approaches to the implicits rework have not been attempted, and that the current proposal seems to many of us a step backwards in simplicity, which will greatly make it harder for people to migrate to Scala 3.

Given that the social dynamics on online forums is such that negative opinions are voiced more willingly than positive ones, I guess I’ll take the effort to say that I do actually like 0.21 implicits quite a lot. Had a couple of issues with what I’ve seen in 0.22 that I raised in the “revisiting…” thread.

3 Likes

Oh, and that I’d prefer a single extension method syntax that is as ergonomic as the one with the extension keywod but accomodates for receivers of different types, something along the lines of

  given Ctx[A]
    extend (theA : A)
      def f (otherA : A) = ???
      def g (otherA : A) = ???
      def [B] h(theB : B) = ???
    extend (nested: Ctx[Ctx[A]])
      def flatten() = ???
1 Like

but yeah, I think what we have overall is likeable. Not exclusively, other proposals might be nice too, but I find what’s there good. (just to steer my comments back to the intended positiveness :slight_smile: )

1 Like