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.

Of course, part of the reason for that is that there really isn't a 
clear separation between functions and "values". You can't really say 
something like Erlang says, where function names start with lower case 
and variable start with upper case. Maybe if there was a heirarchy of 
alphabets/fonts like in math, you could see that (for example) "binary" 
needs to take an operator because it's in bold, or some such.

>   For example let's take these lines:
> 
>      "+" -> binary (+) stack
>      "-" -> binary (-) stack
> 
>   There's no ending delimiter for those commands. 

I think Haskell is line oriented. Commands end at the end of lines. 
Since I use a lot (relatively speaking) of languages like this, that's 
not what's confusing. (Python, Tcl, most macro languages, etc.)

>   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. :-)

 > 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. :-)

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message