Tomasz Zielonka wrote:
On Sat, Feb 04, 2006 at 07:15:47PM -0000, Brian Hulley wrote:
I think the mystery surrounding :: and : might have been that
originally people thought type annotations would hardly ever be
needed whereas list cons is often needed, but now that it is
regarded as good practice to put a type annotation before every top
level value binding, and as the type system becomes more and more
complex (eg with GADTs etc), type annotations are now presumably far
more common than list cons so it would be good if Haskell Prime
would swap these operators back to their de facto universal
inter-language standard of list cons and type annotation
respectively.
I am not convinced. Even if you really want to write types for every
top-level binding, it's only one :: per binding, which can have a
definition spanning for many lines and as complicated type as you
want. On the other hand, when you are doing complicated list
processing, it is not uncommon to have four (or more) :'s per _line_.
I wonder if extending the sugared list syntax would help here. The | symbol
is used for list comprehensions but something along the lines of:
[a,b,c ; tail] === a :: b :: c :: tail -- where ::
means list cons
then there would seldom be any need to use the list cons symbol anywhere
except for sections. I would use "," instead of ";" in the block syntax so
that ";" could be freed for the above use and so that there would be a
generic block construct {,,,} that could be used for records also (and could
always be replaced by layout) eg
P {x=5, y=6}
could be written also as
P # -- # allows a layout block to be started
x = 5
y = 6
Personally, I started my FP adventure with OCaml (which has the thing
the other way around), and I felt that the meanings of :: and : should
be reversed - before I even knew Haskell!
I see what you mean ;-). However the swapping of :: and : really is very
confusing when one is used to things being the other way round. Also in
natural language, ":" seems to have a much closer resonance with the
type/kind annotation meaning than with constructing a list. I also wonder if
it is such a good idea to make lists so special? Does this influence our
thinking subconciously to use list-based solutions when some other data
structure may be better?
Regards, Brian.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
