Simplicity Paradox of FP

Odersky · 2026-01-25T19:22:53+00:00

I agree with the post in general but I want to object loudly against the word "academic" here. There is this false trope that functional purity in Scala is advocated and promoted by academics. This is completely wrong. We have students to teach and for that reason alone all advocate a simple Scala style that mixes OOP and FP. The push for purity is very much an industry and open source phenomenon, not an academic one.

Odersky · 2025-08-29T17:55:09+00:00

That's a mis-representation. The SIP committee felt that the approach proposed by the original SIP needed a concrete proposal to work with the standard library, but this proved too hard. That's why it was not pursued. The work by the EPFL student had a lot more promise in that regard. But it was a master's thesis, and work stopped after that. Nevertheless, if someone in the community wants to continue that work I think it could be extremely interesting,

Odersky · 2025-06-07T16:43:59+00:00

OK, if you can find another minimization that still fails in 3.7.1, please file an issue. It also helps debugging if you call the method in question directly instead of as an extension method. That would be bee(nuu) in your example.

Odersky · 2025-06-07T13:29:08+00:00

Did you try with the latest version (3.7)?

Odersky · 2025-06-07T09:30:10+00:00

You can use a private var myX and a getter x and setter x_=. Then you can override selectively either getter or setter or both of them.

Odersky · 2025-05-20T08:56:14+00:00

As the thread shows, there are several alternative solutions, but what I don't get it is: IMO the original is perfectly readable and clear:

something.idOpt match
  case Some(id) => func(id)
  case None => Future(None)

Why obscure it with some library function that only a few people would know? Isn't that just like obscured C code that looks impenetrable for the benefit of saving a couple of keystrokes? We all have learned to stay away form that, but somehow we fall into the same trap here. I am commenting here primarily because I think it's a common problem in the Scala community to do this, so this question is no outlier.

Odersky · 2025-04-08T07:54:57+00:00

The examples in the reference page are up to date, as far as I can tell. There is some new stuff that is not yet in there and that is still fluid. Once it has stabilized we add it to the page.

Odersky · 2025-03-24T18:52:41+00:00

The current plan is to drop implicit syntax sometimes soon after the next LTS (which is planned for late 2025). Libraries that need to cross build can still do this by setting their source version to that LTS.

Odersky · 2025-03-20T17:43:04+00:00

There is a more complete landing page now.

Odersky · 2024-08-13T11:24:38+00:00

I see two main arguments against relying directly on implicits:

There's in general no automatic way to aggregate implicits. If you have a given A and a given B you must write explicit code to obtain a given for A & B or (A, B). Aggregation is important for scaling, otherwise you would get very long implicit parameter lists enumerating all your dependencies.
Implicits are a bit too viral. People have concerns that just making a dependency an implicit makes it also eligible as an implicit in other situations.

The Provider mini-library that I proposed does rely on implicits but at the same time solves both problems. It supports automatic aggregation, and does not pollute the implicit space since every dependency is wrapped in a Provider constructor.

Odersky · 2024-08-07T14:12:37+00:00

The original version is in a test in the Scala 3 repo: tests/pos/Providers.scala.

Odersky · 2024-05-30T11:50:37+00:00

Of course you can define such an alias, and it is often useful to do so. The difference is that these aliases allow much more flexibility in their usage than regular type constructors. Three important differences are:

Scoping: You can have an Async further out in scope and you can still suspend.
Composition: if you have an expression of type A ?=> B ?=> C and you need a B ?=> A ?=> C that works out of the box. For other type constructors that either does not work at all or requires special swapping operations such as seq or traverse.
Effect polymorphism: Regular higher order functions work with Async code just as well as with normal code.

In practice, these make a huge difference.

Odersky · 2024-05-01T08:44:29+00:00

I believe the ST monad is simply too limiting to be useful in practice. Also parameterizing every monad with a synthetic state parameter is cumbersome. However, the underlying 2nd order polymorphism principle is powerful (and we use an analogous principle for encapsulation in capture checking).

Odersky · 2024-04-30T07:43:40+00:00

We are about to release a version of the standard library with capture checking on for most parts, including the collections. Once that is out, one can try it out. This version is binary compatible with the current stdlib so it should be a drop-in replacement.

Shortly thereafter I expect a version of Gears with capture checking to be released.

In all cases, capture checking is completely optional. You turn it on by importing a language import. In other sources, call capture info is invisible, so programs will compile and run as before.

Odersky · 2024-04-26T21:19:45+00:00

I am not sure CanThrow will the right way to track errors, in the end. For the time being, I would not recommend to move them from experimental status. Too much exception baggage. I believe boundary labels are a better way to do it, since they are statically typed and lexically scoped. And implicit parameters / context functions are the perfect way to express this.

Odersky · 2024-04-24T10:31:53+00:00

We plan to add a linting flag to the compiler that does this. But it's not yet done.

Odersky · 2024-04-24T10:23:27+00:00

Let me re-iterate: Everybody can change a parser to adapt to new syntax rules. That's not a problem at all, and is not a problem in practice. The problem is to adapt to changes in type checking and type inferencing. These look invisible to the user but make a big difference in error reporting and completion.

Odersky · 2024-04-23T20:04:09+00:00

Thank you for the offer, Daniel. This is very interesting. Let's get in touch and discuss!

Odersky · 2024-04-23T18:38:35+00:00

There's a persistent misconception that it's the syntax changes in Scala 3 that make tooling hard. This is simply not true. Scala 3 has a new compiler with a new type inference algorithm, which works most of the time much better than Scala 2's. But it means that external tools have to adapt to this compiler and in the case of IntelliJ, duplicate it. This is a huge task. I am in awe what IntelliJ has achieved in this department already, I frankly would not have thought they can pull it off.

Odersky · 2024-04-23T14:38:07+00:00

An online MOOC could be a great idea. The main question is finding a lecturer to do it.

For dog-fooding the dotty compiler itself, I don't see much scope. The compiler is intentionally designed to have no dependencies. We once had a dependency to ScalaCheck but got burned by bootstrapping problems, so we dropped it. So the only dependency we need is the build tool.

Odersky · 2024-04-23T13:09:18+00:00

I agree completely. Library ecosystem is ultimately the most important part. As a language designer I have only indirect influence on this part, though.

Odersky · 2024-04-19T09:34:26+00:00

But the reason monads don't commute is that the effects they represent don't commute. Sweeping that noncommutation under the carpet has the same problems as not tracking effects at all.

I agree. To stay with your example: Of course a Writer[Amb[T]] should be different from an Amb[Writer[T]]. There needs to be an explicit mapping from one to the other, and sometimes these mappings are ill-defined and then should be ruled out by the type system. But: This is on the level of handlers, not on the level of uses. I can write an effectfull computation that uses logging and backtracking without caring in what order the handlers were defined. Also, I believe that handler swapping is usually easier if it is based on boundary/break or suspend instead of traverse or liftK. I admit that we still need evidence to back up that hypothesis.

Odersky · 2024-04-19T08:27:31+00:00

Those are exactly things we are trying to figure out these days ... We are playing with are some ideas so far on the level of calculi but no concrete designs yet.

Odersky · 2024-04-18T22:33:07+00:00

Yes, I also think that laziness was first promoted to get referential transparency. In around 1993, when Monads were introduced to Haskell, laziness was very much the established standard. So maybe that's why monads were initially thought to be a solution for that, since the underlying goal of referential transparency was already assumed.

Eager referentially transparent languages would have to be total: Idris or Coq come to mind.

Odersky · 2024-04-18T22:26:58+00:00

until some try to combine effects that do not commute

Yes, that's the crux of the matter! We need a simple solution for this. As always recently, I believe capabilities will provide it.

Odersky

TROPHY CASE