John Hughes wrote:
> Quoting Paul Hudak <[EMAIL PROTECTED]>:
>
>> Actually, one of the main reasons that we chose (:) is that that's what
>> Miranda used. So, at the time at least, it was not entirely clear what
>> the "de facto universal inter-language standard" was.
>
Phil Wadler argued for the ML convention at the time, and wrote a document
containing a fair amount of sample code to illustrate what it would look
like. We noticed something surprising: instead of (x:xs) and the like, Phil
had consistently written (x :: xs) -- note the extra spaces. Somehow, using
the longer operator name led him to feel spaces were needed around it. That
in turn made his lines longer, encouraged him to split definitions across
lines, and so on. When I read the thing, I realised after a while that I
was
skipping all the code fragments -- because they just looked too big and
complicated to take in during a quick reading. It was at least partly that
experience that convinced us that using :: for cons would impose a small
cost, but a real one, on readability. It may seem trivial, but the sum of
many such decisions is significant. The story does illustrate the
importance
of actually trying out syntactic ideas and seeing how they play--one can be
surprised by the result.
And at the time I agreed with you. But now I'm older and wiser(?).
I now think :: for type signatures was a bad mistake.
I don't use lists very much. They are not the right data structure
for many things. So : is not as common as :: in my code.
I checked a small sample of code, about 20000 lines of Haskell.
It has about 1000 uses of ':' and 2000 of '::'.
In my opinion all the special syntactic sugar for lists should go
away. I don't think lists are special enough to motivate it.
But this is not what Haskell' is about. It's supposed to be some
modest extensions to Haskell. Not designing a new perfect language.
-- Lennart
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
