> Isn't that the entire basis of abstraction though? That the same-looking
> command/statement/expression can do different things depending on context?

Yes, but you are adding context in an unusual way. In particular,
whether an expression is being assigned to a variable or not. Nothing
else in scala depends whether or not it's being used in an assignment.

for-loops and for-comprehensions are similar, but I think about them
very differently. I tend to write them very differently too because
the typechecking rules are so different.

Peace. Michael


On Tue, Feb 21, 2012 at 1:00 PM, Haoyi Li <haoyi.sg@xxxxxxxxx> wrote:
> Roland,
>
> Thanks for the detailed reply =) It was very useful. Some followups:
>
>> No, because there is a fundamental difference between context-free and
>> context-sensitive grammars; count that one as an infinite factor when
>> comparing simplicity ;-) Also, you would not remove one language feature,
>> you would only hide it some more and make it more difficult to specify its
>> semantics.
>
> Is the Scala grammar context free? Apart from that, are most commonly used
> languages context-free? I really don't know.
>
>> Also, you would not remove one language feature, you would only hide it
>> some more and make it more difficult to specify its semantics
>
> Isn't removing the whole for(...)yield{...} thing removing a language
> feature? Sure you could still use map() and foreach() to do the same thing,
> but those are just functions and have no special syntax the way
> for(...)yield{...} does.
>
>> The Scala compiler does not have any means to prove your assumption
>> (that’s the halting problem again). map() and foreach() are completely
>> different methods, they bear no relation whatsoever as mandated by the
>> interface. That there is usually a connection in concrete implementations is
>> pure coincidence.
>
> I accept that if the two for-constructs are syntactic sugar for method
> calls, then they should stick to their respective methods.
>
> I suppose what I am really arguing is that maybe they shouldn't just be
> syntactic sugar for method calls, but rather have their own semantics as a
> for-loop and a list-comprehension, which follows the way methods work for
> consistency, and happens to use the method-calls under the hood for DRY. I
> think defining them in terms of "this is how they should behave" -> "figure
> out implementation" is better than "this is what implementation they wrap"
> and leaving it at that.
>
>>  if the syntax allows different transformations based on context, that is
>> the worst thing you can do to a programmer (or any tool which tries to work
>> with your code, like IDEs).
>
> Isn't that the entire basis of abstraction though? That the same-looking
> command/statement/expression can do different things depending on context?
> That's basically the argument given for why Java does not have operator
> overloading, and I don't think it's really valid; I really enjoy being able
> to effectively overload operators in Scala/C#/Python, leaving aside the
> nitpicking about operator vs. funnily-named-method.
>
>> Also, the type-inferencer would not “optimize” anything (that is not its
>> job anyway), because calling a completely different method is not a valid
>> optimization.
>
> Isn't "calling a different method" the whole basis function inlining and
> dead code removal? That rather than calling a method you call his contents
> directly, or you don't call it at all? Isn't quite a lot of what
> optimization in general is about doing stuff like that, inlining, shifting
> variables to local scope, looking at the types (inferred or explicit) of
> variables and doing clever semantic-preserving refactorings?
>
>
> Again I know nothing about the internals of the Scala compiler (and not a
> huge amount about compilers in general!), so I'm only speaking in very
> general terms, but it seems that none of these problems are insurmountable.
> To the end-user having two different language constructs that look almost
> the same and do two very similar things (as well as two things you almost
> never want to do!) but are not interchangeable seems incredibly awkward.
>
> Thanks!
> -Haoyi
>
> On Tue, Feb 21, 2012 at 2:56 PM, Daniel Sobral <dcsobral@xxxxxxxxx> wrote:
>>
>> On Tue, Feb 21, 2012 at 14:16, Nils Kilden-Pedersen <nilskp@xxxxxxxxx>
>> wrote:
>> > On Tue, Feb 21, 2012 at 9:17 AM, Haoyi Li <haoyi.sg@xxxxxxxxx> wrote:
>> >>
>> >> Isn't that something the compiler could optimize away though?
>> >> Identifying
>> >> for-comprehensions not assigning to anything seems to me pretty
>> >> straightforward compared to some of the other optimizations people do.
>>
>> No, it could not.
>>
>> The code for "map" has to  be compiled with the return value, and that
>> is what causes the performance impact.
>>
>> The code that *calls* map can discard the result, but it cannot change
>> code that has been already compiled, nor can it provide to "map" a
>> function that does not return the result that "map" is expecting.
>>
>>
>> --
>> Daniel C. Sobral
>>
>> I travel to the future all the time.
>
>