Darren New wrote:
> Warp wrote:
>> Often everything you see in a line of haskell code looks like this:
>>     a b c . d e f . g h
>> and there's no way of visually telling what they are.
> 
> Yeah. I find this is where I have big stumbling blocks reading both 
> Haskell and ML.

I have a similar issue with stuff like

   while (*x++ = *y++) {}

Apparently that means "deference y, fetch the result, incriment y, 
deference x, store the result there, incriment x". For no particular 
reason other than the specific operator precidences of C.

Similarly, to parse a Haskell expression, note that brackets rule first, 
then the (.) or ($) operator. (You'd have to be mad to mix the two 
together without some brackets first.) No reason, that's just the 
operator precidence rules.

> Of course, part of the reason for that is that there really isn't a 
> clear separation between functions and "values".

Meaning you can write a function that takes a function and returns a 
function which accepts another function which will return a function 
that takes an integer and returns a Boolean. Or similar. Which, even 
I'll admit, is pretty crazy.

> I think Haskell is line oriented. Commands end at the end of lines.

Indeed. (Though strictly Haskell doesn't have "commands", it has 
expressions.) More exactly, blocks of stuff indented by the same amount 
parse as if they were enclosed in {} (which you can manually do, if it 
makes you feel better). Otherwise, expressions end at the end of the line.

>>   Moreover, in Haskell, from a layman's point of view, you are not even
>> guaranteed that you can read from left-to-right and get a concept of how
>> the code is being executed. 
> 
> Or even if it executes at all. :-)

Well, notionally you can ignore lazy execution while figuring out the 
meaning of the statement, and *then* consider how (if at all) laziness 
affects it afterwards.

>> Sometimes code is executed left-to-right,
>> sometimes right-to-left, sometimes in a wilder order, and seemingly very
>> arbitrarily. It becomes very hard to follow what is going on there.
> 
> Yet, oddly enough, the most naive complaint about LISP is all the parens 
> that completely disambiguate evaluation, and about APL that the 
> evaluation order is strictly right to left without parens. :-)

One of the most common things beginner Haskell programmers do is add 
vast numbers of brackets. ;-) Trust me, beyong a certain point it 
hinders rather than helps.

I think the fact that tuples use regular brackets is rather unhelpful 
here. There's a very subtle visual difference between (sin(x) + sin(y)) 
and (sin(x), sin(y)), but their meanings are quite different. It might 
have been better if we had <sin(x), sin(y)> or something, like POV-Ray 
does...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message