RIP-12

[Ruud Vlaming]

Recently, the SIP committee decided SIP-12 was not worth adopting. After being considerable time in the process (maybe even too long) the decision was made to reject: http://docs.scala-lang.org/sips/minutes/sip-10th-august-minutes.html

From the title of this post it may become clear that i very much regret this decision. Indeed, the SIP was not often spoken about, but surely this was also because most of the people in favor believed that it would be adopted in the end, being a proposal of Martin Odersky himself. He, as no other, has a clear view on the esthetics of the language. People do not choose Scala because the syntax resembles Java so much but for its power in combination with it syntactical beauty. That would have been enhanced even further with SIP-12 accepted, thereby not denying the difficulties that were raised in the meeting.  

This is an invitation to the committee to show courage and reevaluate the decision, preferable at a time when Prof. Odersky can be present to plea on its behalf.

Ruud Vlaming

[Hanns Holger Rutz]

Hi Ruud,

I haven't followed the development, but let me just say I totally agree
with all what you write here. I think SIP-12 would make Scala much more
regular and pleasant in terms of its syntax. I don't buy the argument
that asking Java people to insert the `then` keyword after the `if`
predicate makes for a "significant migration pain" -- that would be
arguably the _least_ problem for people with Java background learning
Scala. I also don't see a benefit in itself to "look like Java and C"
(when it's not).

So here's my vote to keep this SIP open.

Best, .h.h.

> --
> You received this message because you are subscribed to the Google
> Groups "scala-sips" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to scala-sips+...@googlegroups.com
> <mailto:scala-sips+...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.

[Rex Kerr]

You make some reasonable points, but I never liked the proposal much, for three reasons.

1. It introduces a syntactic ambiguity where there was none.

2. It either requires lots of busywork changes in existing code bases, or enlarges the spectrum of different ways to express the same thing in Scala code.  So there is a big one-time cost or a small ongoing cost to readers.  Either way, there is a not insignificant cost.

3. It pulls the if-construct even farther away from what can be emulated in a library.  One of the nicest things about Scala is that so many things feel built-in because the ones that actually are built-in have almost exactly the same syntax as those that aren't.  Point-free syntax just can't do the if-then thing.  (It already fails at if-else.)

Some of these concerns are also expressed in the minutes.

Rather than saying "please keep it open", perhaps you can address the concerns, or suggest a modification of the proposal that would address them better?

Here's one that addresses #3, for example: add the idea of _ephemeral classes_.  An ephemeral class is one that cannot escape its expression.  In the type hierarchy it would actually _not_ be a subtype of Any.  The only thing you can do is call methods on it (and pass it to other functions that take an ephemeral class of the right type) until it returns some non-ephemeral class.

You could then say that the methods of an ephemeral class have a uniquely low precedence when used in point-free notation, which would allow safe `if/then`-style constructs, especially if implicit conversion to a non-ephemeral class was allowed if the ephemeral class was not explicitly consumed by a method call.

For example:

package example;

ephemeral class ConditionalOn(test: Boolean) {

  def then[A](onSuccess: => A) = ConditionForTrue[A](test, onSuccess)

}

ephemeral class ConditionForTrue[A](test: Boolean, onSuccess: => A) {

  def `else`[A1 >: A](onFailure: => A): A1 = if (test) onSuccess else onFailure

  private[example] def evaluate: Unit = { if (test) onSuccess }

}

implicit def trueConditionEvaluates[A](cft: ConditionForTrue[A]): Unit = cft.evaluate

def `if`(b: Boolean) = ConditionalOn(b)

Now we can

`if` 42 < life then "Adams" else "never mind"

which would, once `if` was hit, be parsed looking for ephemeral methods using parentheses inference as such:

`if`(42 < life).then ...

And since `then` has a `ConditionForTrue` return value, it switches over to looking for methods on that:

`if`(42 < life).then("Adams").else("never mind")

Alternatively if we simply said

`if` bottlesOfBeer > 0 then sing(s"$bottlesOfBeer bottles of beer on the wall...")

then the implicit would kick in and the expression would be evaluated if the conditional were true.

Now we have a language feature that allows us the if-then construct, which removes my objection #3.  (Note--this is not the only way to do this.  But it is _a_ way to do it.)

  --Rex

--
You received this message because you are subscribed to the Google Groups "scala-sips" group.

To unsubscribe from this group and stop receiving emails from it, send an email to scala-sips+unsubscribe@googlegroups.com.

[Ruud Vlaming]

These are valid points points Rex,

However, I wrote this post from a Scala user perspective, not a Scala language or Scala library designer one. Naturally, the latter two groups have more influence in the decision making process, and judge proposals on feasibility and complexity of implementation. But the Scala users are the larger group, a mostly silent majority if you will, certainly in these channels, but are in the end the reason for which this whole project exist, set aside research.

Now, from this point of view, let me address your concerns.

1) “It introduces a syntactic ambiguity where there was none.”

True, but a solution path was also presented in the SIP. Personally i would opt for a compiler flag. First something like “-withSIP12” so that old style is default and with the flag the new syntax is accepted (and the old refused) and in the next version “-withoutSIP12” so that new style is default and with the flag old style is accepted (and the new refused). 

2) “It either requires lots of busywork change ...”

With the solution above, you do not need to accept different ways in the same codebase. As a developer, not just Scala, but also C++ (mostly for computational physics), C (for embedded systems) and Javascript and Dart (for front ends). I wrote approx 20.000 lines of Scala code in three separate projects this year. Changing that to a new syntax indeed is work, but this should not be exaggerated. With some tooling, this can be done in a day or two. And for code that is “finished” and needs recompiling the compiler switch can be used. I would rather have that, than a language where the syntax cannot be improved anymore, just because some small but loud voiced group of people is whining about the work that needs to be done.  

3)  “It pulls the if-construct even farther away ...”

As said, i am no language designer, so i do not understand the full impact of this problem, but your solution seems very clever. Certainly you are not saying that an opinion about a SIP only has value if the poster can solve all the problems that arise? When something is impossible, that is an other matter of course. But as fas as i can see the committee has enough brainpower to crack this nut.    

Let me conclude with the following. Please remember that a small language like Scala (position 33 on Tiobe) needs vision to become large, not consensus. Focus on the strong parts and amplify them. The rest (such as keeping everybody satisfied) is of lesser importance. Recently i got an e-mail from Heinz Nabielek, and want to relay quote: “I was a little involved in creating a programming language "ADA" in the eighties. Because it was a programming language created by a committee, it was a huge failure.....”. 

Formulated differently:  Prof. Odersky certainly had vision when he creating Scala, and he is as modest as visionary. So you need damn good reasons to put aside his proposals, and the fact that he can veto them (which he could not this time by the way) is not one of them. 

I wish you and the committee much wisdom in the upcoming meetings. 

Ruud Vlaming.

Op zondag 16 oktober 2016 22:14:52 UTC+2 schreef Rex Kerr:

To unsubscribe from this group and stop receiving emails from it, send an email to scala-sips+...@googlegroups.com.

[Justin du coeur]

On Wed, Oct 19, 2016 at 4:42 PM, Ruud Vlaming <ru...@betaresearch.nl> wrote:

But the Scala users are the larger group, a mostly silent majority if you will, certainly in these channels, but are in the end the reason for which this whole project exist, set aside research.

That's true -- but please keep in mind that you aren't authorized to speak for that majority either.  I mean, as one of those pure "users", I personally found SIP-12 pretty uninteresting.  Not necessarily *bad*, but of the SIPs out there, it's one of my *very* lowest priorities, and in the grand scheme of things I'm not sure I am even in favor of it.

So please be careful about "silent majority" arguments.  That majority isn't necessarily with you here...

[Ruud Vlaming]

"That's true -- but please  ... That majority isn't necessarily with you here"

I humbly agree with you, maybe the force is ;) Anyway, my post was to show there may be an other perspective to this SIP. Different from SIP-26 for example, which i also regret is rejected, because i like these types a lot. But, the point has come across by now i think (hope). Let's see what happens.

Op woensdag 19 oktober 2016 23:12:37 UTC+2 schreef Justin du coeur:

[Rex Kerr]

On Wed, Oct 19, 2016 at 1:42 PM, Ruud Vlaming <ru...@betaresearch.nl> wrote:

These are valid points points Rex,

However, I wrote this post from a Scala user perspective, not a Scala language or Scala library designer one. Naturally, the latter two groups have more influence in the decision making process, and judge proposals on feasibility and complexity of implementation. But the Scala users are the larger group, a mostly silent majority if you will, certainly in these channels, but are in the end the reason for which this whole project exist, set aside research.

Now, from this point of view, let me address your concerns.

1) “It introduces a syntactic ambiguity where there was none.”

True, but a solution path was also presented in the SIP.
 

How do you parse this under the new proposal:

do foo while bar do baz while quux

? Is it

do foo while bar

do baz while quux

or is it

do

  foo

  while bar do baz

while quux

?

Is it so blindingly obvious that even if I indent it as if I mean the wrong one that basically everyone will understand it as the right one?

 

2) “It either requires lots of busywork change ...”

With the solution above, you do not need to accept different ways in the same codebase. As a developer, not just Scala, but also C++ (mostly for computational physics), C (for embedded systems) and Javascript and Dart (for front ends). I wrote approx 20.000 lines of Scala code in three separate projects this year. Changing that to a new syntax indeed is work, but this should not be exaggerated. With some tooling, this can be done in a day or two.

Sure, but a couple days of work times a few thousand developers (there are probably more) is multiple man-years of work.  You want to be sure it's worth it.  It didn't sound like the SIP committee was convinced it was worth it.

Also, since it introduces a new keyword (then), it's a bigger change than you might think.  I have all kinds of "now" and "then" variables running around in my time-handling code.

 

3)  “It pulls the if-construct even farther away ...”

As said, i am no language designer, so i do not understand the full impact of this problem, but your solution seems very clever. Certainly you are not saying that an opinion about a SIP only has value if the poster can solve all the problems that arise?

My "solution" is so different that it would have to be a completely different SIP.  Not every issue needs to be solved, but it's a good idea to at least recognize the potential issues surrounding a SIP more-or-less as written.

 

Prof. Odersky certainly had vision when he creating Scala, and he is as modest as visionary. So you need damn good reasons to put aside his proposals

Sure, but I leave it to him to communicate whether he's really exhaustively considered a proposal and is very certain that it's a central part of the vision, or whether he thinks something seems like a good idea but is counting on the SIP process to vet the idea.

Personally, if I were a language designer I would like to be able to be in the latter situation sometimes, because not everything I want to suggest is something that I'm utterly confident is an awesome idea.

  --Rex

 

[Hanns Holger Rutz]

Well, you are making up a very constructed thing, to prove what? Before
anyone ever coarsely implements a parser, you don't know what kind of
cases you will have to deal with. That's true with current syntax and
true with new syntax.

I would thus recommend to judge the proposal foremost by its aesthetic
qualities and the consistency it brings to Scala syntax in general. In
both cases of which I think it performs favourably.

I think what it needs is a sandbox project, like Li Haoyi did with the
Python-syntax for Scala (indentation instead of parentheses). Then you
can play around and actually measure how it feels.

Best, ..h.h..

> --
> You received this message because you are subscribed to the Google
> Groups "scala-sips" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to scala-sips+...@googlegroups.com

> <mailto:scala-sips+...@googlegroups.com>.

[Simon Ochsenreither]

Yes, I would very much liked to see it, but I think the time wasn't right. Until the much-fabled rewrite tool actually exists, every proposal that changes syntax has a lot of obstacles to climb.

Personally, the proposal made me think about the way I structure my code at the microlevel, and I transitioned from

if (foo) bar
else baz

to

if  (foo)
     bar
else baz

and I couldn't be happier.

I'll start enforcing this for a 50.000 lines codebase as soon as the tools are ready.

[Bardur Arantsson]

On 2016-10-20 09:54, Hanns Holger Rutz wrote:
> Well, you are making up a very constructed thing, to prove what? Before
> anyone ever coarsely implements a parser, you don't know what kind of
> cases you will have to deal with. That's true with current syntax and
> true with new syntax.
>
> I would thus recommend to judge the proposal foremost by its aesthetic
> qualities and the consistency it brings to Scala syntax in general. In
> both cases of which I think it performs favourably.

Language changes don't exist in a vacuum and pretending otherwise is not
very constructive, IMO.

The effort to convert the huge amount of code out there is non-trivial.
(And it's not just a one-time job either. Consider that many
organizations may need to maintain multiple branches of their code for a
long time.)

>
> I think what it needs is a sandbox project, like Li Haoyi did with the
> Python-syntax for Scala (indentation instead of parentheses). Then you
> can play around and actually measure how it feels.
>

Are you volunteering to put forth that effort?

Regards,

[martin odersky]

I did not object to closing the SIP even though I originally proposed it. My reasons were:

 - it's relatively minor, we have much bigger fish to fry

 - the timing to put this in now was not right. Once dotty is out and we have a good rewrite tool we can always reconsider.

 - there's currently an effort to move SIPs faster to a conclusion, which is very much the right thing IMO. I did not want to uphold this movement by insisting on stalling the SIP further.

Cheers

 - Martin

--
You received this message because you are subscribed to the Google Groups "scala-sips" group.

To unsubscribe from this group and stop receiving emails from it, send an email to scala-sips+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Martin Odersky
EPFL and Lightbend

[Hanns Holger Rutz]

On 20/10/16 16:13, Bardur Arantsson wrote:
> On 2016-10-20 09:54, Hanns Holger Rutz wrote:
>> Well, you are making up a very constructed thing, to prove what? Before
>> anyone ever coarsely implements a parser, you don't know what kind of
>> cases you will have to deal with. That's true with current syntax and
>> true with new syntax.
>>
>> I would thus recommend to judge the proposal foremost by its aesthetic
>> qualities and the consistency it brings to Scala syntax in general. In
>> both cases of which I think it performs favourably.
>
> Language changes don't exist in a vacuum and pretending otherwise is not
> very constructive, IMO.

I'm not pretending anything. I'm answering to Rex who argued that there
could be corner cases for the parser. But the reality IMHO is, that
those corner cases exist in any syntax variant (and certainly there are
other languages which do have the `then`). So I'm saying it is
narrow-minded to reject the overall proposal based on the possibility
that there are corner cases.

> The effort to convert the huge amount of code out there is non-trivial.
> (And it's not just a one-time job either. Consider that many
> organizations may need to maintain multiple branches of their code for a
> long time.)

I would never assume that such changes take place without an automatic
rewrite tool, or a transition period where both old and new style are
allowed. Very much with what will happen to the procedure syntax.

>> I think what it needs is a sandbox project, like Li Haoyi did with the
>> Python-syntax for Scala (indentation instead of parentheses). Then you
>> can play around and actually measure how it feels.
>>
>
> Are you volunteering to put forth that effort?

No, I'm afraid I have no resources. I will try to contribute to the
discussion as far as I can.

best, .h.h.

[Ruud Vlaming]

Op donderdag 20 oktober 2016 16:28:25 UTC+2 schreef Martin:

I did not object to closing the SIP even though I originally proposed it. My reasons were:

 - it's relatively minor, we have much bigger fish to fry

 - the timing to put this in now was not right. Once dotty is out and we have a good rewrite tool we can always reconsider.

 - there's currently an effort to move SIPs faster to a conclusion, which is very much the right thing IMO. I did not want to uphold this movement by insisting on stalling the SIP further.

Too bad, but that settles it, thanks for taking the time to join in.

Ruud. 

 

[Rex Kerr]

On Thu, Oct 20, 2016 at 12:54 AM, Hanns Holger Rutz <con...@sciss.de> wrote:

Well, you are making up a very constructed thing, to prove what?

To prove that two common constructs are ambiguous?

This isn't some arcane detail; stuff like this is the source of common and frustrating bugs where what you understand doesn't match what the compiler thinks about some code.  Look at all the grief of == vs = in C (where types don't often save you when you type the wrong one).

if/then/else doesn't have this problem; do/while/do/while does.

Sometimes a complete grammar is too complex to evaluate without a working parser, but that's not true here.

  --Rex