I can think of cases like yours for every language. Let's do Java (though
not as well as Java Puzzlers does):
List<T> can't deal with List<int>.
for (String name: names) doesn't compile if names is a Iterator, not an
Iterable. (What's an irritable anyway?!)
final members assigned to a non-null value can be observed to be null.
To explain your examples.. note that you don't need a val/var in a lambda
either, i.e., (x => x + 2) rather than (val x => x + 2). The extra 'val'
would be pointless and confusing. Perhaps at first glance it would seem
like within a for-comprehension the val would not be pointless. But it
would be val every time, as vars are meaningless in that context, so it
would only help those unfamiliar with the syntax.
C#'s LINQ has a contextual keyword, let, for that case.
I think the tension is caused by mutable variables. If Scala didn't have
them, we wouldn't need val/var ever, we'd just do x = 5; like in Haskell and
Erlang.
The yield case could be altered but you'd just be introducing more
apparently arbitrary rules. E.g., if for (x <- 1 to 5) { yield x * 2 } were
allowed, what would happen with:
for (x <- 1 to 5) { if (x < 2) yield x * 2 else println(x * 3) }
The method calls that yield translates to are very different to the ones
that code without yield (my else case) translates to, so there would be
another rule; you can't use yield in some branches and not in others. I
think this would be worse than the present situation, allowing for (..)
yield expression, but not for (..) { yield expression }.
I should note that you can't introduce {}s into random parts of LINQ
expressions either, so this is certainly not Scala-specific. You also can't
write, in Java: if (foo) bar(); { else baz(); }.
Swings and roundabouts. Again, there's tension caused by something
underlying, the difference between pure and side-effecting code. If as in
Haskell Scala had no side effects there would be no need for the yield
keyword.
As for being disingenuous, I don't think so. Commodo parco ad hominem.
2010/9/17 Cédric Beust ♔ <[email protected]>
>
>
> On Tue, Sep 14, 2010 at 4:28 AM, Ricky Clarkson
> <[email protected]>wrote:
>
>> Fabrizio,
>>
>> I'm not following this thread properly, but I'll just note that Scala
>> is intentionally simple. It has more features than Java, but less
>> pointless complexity.
>
>
> Saying this without mentioning that Scala adds complexity of its own as
> well is a bit disingenuous, and it's also the reason why strong Scala
> advocacy tends to turn people off rather than getting them interested in the
> language.
>
> A couple of examples (about comprehensions, since I just encountered these
> recently so they're fresh in my mind):
>
> - In a for expression, if you declare a variable, you must omit "val".
> - The following syntax is invalid:
> for (a <- accounts if account.id % 2 == 0) { yield a }
> (yield can't appear there)
>
> I find oddities like these ones in the Scala grammar *all the time*, and to
> me, they are the sign of a language that's growing too big. I can deal with
> them, and obviously, so can you, but this is very much reminiscent of C++ to
> me: a language that's so complex that organizations that adopt it must
> agree on which features *not* to use in order to keep the code base sane.
>
> --
> Cédric
>
> --
> You received this message because you are subscribed to the Google Groups
> "The Java Posse" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]<javaposse%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.
>
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
