On 05/02/06, Lennart Augustsson <lennart at augustsson.net> wrote:
> John Hughes wrote:
> > What, no list comprehensions??
>> No. I think the do notation is good enough.
>>> >
> > I'd disagree--sequencing is special, and lists represent it directly.
> > Don't forget, also, that lists are also much more prevalent in beginners'
> > code--and nice notation for beginners helps get people started on
> > Haskell.
>> I don't really see what's so much better about writing
> [x1,x2,x3,x4,x5] than x1:x2:x3:x4:x5:[].
> When I've explained lists to beginners I've just found it
> annoying and hard to explain why there are two ways of
> writing lists. And why only lists have this special syntax.
>> -- Lennart
Lists have special syntax because they're the lazy-functional
counterpart to loops. They're quite a fundamental structure,
regardless of what other data types we may have at our disposal, and I
think that lots of special support is reasonable. Loops in imperative
languages often get all kinds of special syntax support, and I don't
think it's too far off-base to give lists special syntax accordingly.
That said, I'd *really* like to see monad comprehensions come back,
since they align better with the view that monads are container types,
dual to the view that monads are computations, which is supported by
the do-syntax. This view is actually much easier to teach (in my
experience). Giving lists a little extra syntax is nice, but giving
things unnecessarily restrictive types seems to be the point at which
I'd consider it going too far.
I haven't thought this out too carefully, but perhaps in order to give
the brackets and commas syntax some more weight, the syntax
x1:x2:x3:[] (or x1:x2:x3:Nil ?) could be used solely as a list, but
[x1,x2,x3] would be the corresponding element in any MonadPlus -- this
would be quite handy in a lot of the cases which I care about
(nondeterministic computation). It would also mesh perfectly with
monad comprehensions.
I'd also like to mention that although my background is in pure
mathematics, I had no trouble whatsoever adjusting to :: meaning "has
type". A colon is commonly inserted in mathematics between the name of
a function and a depiction of the domain and codomain with an arrow
between them, but I wouldn't think of that as formal syntax per-se.
Also, it's not centuries-old as mentioned, but only about 50 years old
-- I believe it started with the use of arrows in category theory.
Before then, people mostly stated the types of functions in words, or
it was left completely implicit, and they still often do both of
those. Also, it is only used for functions and doesn't apply to values
in any set or concrete categorical object. The notation x : S to mean
x is an element of S is not in widespread common use.
The use and context in mathematics is sufficiently different that I
don't see it as a concern that Haskell be the same in this regard.
The aesthetic reason that I like :: for "has type" and : for cons is
that it's far more common that type signatures occur on a line by
themselves, whereas conses when needed are often needed in bunches on
the same line.
Not that I'm suggesting that we change things, but as an example, I
actually wouldn't mind typing out "has type" for type declarations
(though the symbolic form is awfully nice when things must be
annotated in-line, because it looks more like a separator rather than
some random words -- syntax colouring could make up for that though),
whereas I would likely mind a larger symbol for list cons. The amount
of typing isn't the concern, it's how it actually looks on the page,
and where it occurs in use.
The wishy-washy informal reasoning is that cons is like a small bit of
punctuation between the elements of a list -- semantically a comma,
whereas a type annotation is actually saying something. When reading
code aloud, you might not even say 'cons', and if you do say
something, it'll probably be something fairly short and
punctuation-like whereas for a type annotation, you're almost
certainly going to say 'has type' or 'is of type', which seems
structurally 'larger' to me, and perhaps deserves a bigger, more
noticeable representation on the page.
- Cale