published: 2012-03-18

SIP-18 is a Scala Improvement Proposal. Its intent is ... well ... to be honest. I don't get it. But the plan is to introduce a feature in Scala which would disable some of Scalas features. In order to turn these features back on you would have to import them with statement like these:

import language.macros

import language.{structuralTypes, existentials}

So this feature is rather simple and kind of obvious to understand. But what is its intent? The proposal itself says:

The hope is that this will provide a good balance between the wish to provide the most powerful abstraction facilities possible and the wish to control of these features by making their usage more explicit.


Smart people say when looking for the real reason for anything one shouldn't stop at the first answer to the question "why?" but instead ask again: Why does anybody whish to make the usage of these features more explicit?

Knowledgeable people seem to agree that you can use these features without actually wanting to with quite unfortunate side effects:

It's quite easy for structural types to creep into a public API unintentionally [..] To give you an idea of the magnitude of the problem, the textual representation of the inferred type was 225kb. Yes, kilobytes.


So there is actually good reason for a way disable some features for those that don't want punch holes in their feet. We have a problem and we have a solution so everything should be fine, right? I don't think so.

Lets look at possible alternative solutions first.

  1. code reviews and proper education of developers ... mmh, ok that won't work in most cases.
  2. tools separate from the the language. I think Scala has a perfect setup for this. It allows compiler plugin and naive as I am I would think it should be perfectly feasible to write a tool or a compiler plugin that checks for usage of certain features. It would easily enforceable by a continuous integration setup which by now everybody should use who is working on some serious code.

Lets look at the consequences of the proposed solution second.

  1. It is another language feature, so it makes the beast that is so difficult to tame for many even more difficult. And it is a bad kind of feature in itself. It uses an existing Feature (Imports) in order to do something completely different than the normal usage does (enabling of features vs. managing of namespaces)
  2. It is zero protection for those not understanding the risk or willing to take it or both, even when they are only the minority of the team (note this is not possible with a compiler plugin or a separate tool used in the CI build)
  3. It makes usage of the existing features even more difficult, because now all the little hints and tips found in the internet fail to mention that from version X on you have to make an import to use a certain feature. I'm already waiting for the stackoverflow questions "I want to do Y and do just as described HERE and it doesn't work"



There is a never ending discussion going on if Scala is complex or complicated or difficult. I think this SIP acknowledges this to be true. Which is a good thing (the acknowledgment). After all you don't make guns saver be telling everybody these things are harmless.

Martin Odersky, Scala to stay a lean language:

In the future my ambition is to make Scala an smaller language, not a larger one.

Why would he want to introduce such a weird feature of dubious value?

As said before: I don't get it. Anybody wants to explain it to me in the comments? Serious, it would be welcome.

Talks

Wan't to meet me in person to tell me how stupid I am? You can find me at the following events: