

Announce: Haskell 2010 - dons
http://www.haskell.org/pipermail/haskell/2009-November/021750.html

======
gjm11
This is mostly codifying things that are already widely implemented. (Of
course, in Haskell-land "implemented in GHC" counts as "widely
implemented"...)

Here's a brief list of what's changed (note: this includes the already-widely-
implemented stuff) ...

Fix an annoyance in the language syntax that meant that (e.g.) an if/then/else
construct inside a "do" needed to be indented in a weird way.

Allow module names to contain ".", providing an obvious way to make a
hierarchy of modules.

Allow _data_ declarations with no constructors. Apparently this is useful when
engaging in various sorts of compile-time type system magic, where you have
types that are used only for that magic and not because you ever expect to use
a value of that type.

A grammar cleanup related to infix operators.

Add a standardized foreign function interface.

Another grammar cleanup: Haskell to-end-of-line comments begin with "--"
unless that's part of a legal lexeme; it happens that colons are treated
specially in the grammar, which mean that you couldn't make a symbol "--:--"
because the "--" would always be parsed as beginning a comment. Not any more.

Guards in a pattern-match can now include their own pattern-matches; the guard
fails if the pattern-match fails, otherwise it succeeds and the appropriate
binding takes place.

Type inference is a bit more flexible (note: in practice most implementations
behaved the more-flexible way already).

Document expected behaviour of the LANGUAGE pragma so it can be used portably
to specify what language extensions your code needs.

Remove n+k patterns, which were always controversial.

------
hyperbovine
Maybe in 2010 GHC will start working on Snow Leopard. Fingers crossed.

~~~
ionfish
It does work, it just doesn't compile to 64-bit.

GHC doesn't have an awful lot of people working on it, certainly compared to
something like GCC. There is no maintainer for x86_64 on OS X; essentially,
those of us without the skill to resolve the issues are just hoping that
someone steps up.

This Trac ticket has more details; you can see from the length of the CC list
how much interest there is in resolving this. Unfortunately, interest doesn't
directly translate into a fix.

<http://hackage.haskell.org/trac/ghc/ticket/2965>

~~~
smanek
If it can't install off macports, it's broken to most people.

SBCL is in the same position. I can (and did) compile/install it manually -
but that doesn't change the fact that it's "broken."

------
eelco
Amazing how small the set of accepted changes is given the amount of
extensions GHC has. But, I'm happy that a decision has been reached and
Haskell as a language is 'officially' moving forward again.

------
ramanujan
IMO, the biggest thing missing from Haskell is a fast Mutable Map (like
Python's).

The current workaround is to use a tree structure with O(log N) lookup time,
which is obviously not good.

Yes, I know such a data structure isn't pure, but there are other Mutable
objects which are implemented and available.

Perhaps someone should just write a wrapper to a good standalone C/C++
implementation and make it available on Hackage. Would be a huge help.

~~~
jamii
> the biggest thing missing from Haskell is a fast Mutable Map (like Python's)

Data.HashTable is part of the core library and has improved a lot over the
last few years.

~~~
jamii
Hmm, I tried with GHC 6.10 and the python dicts are still faster. I'm told
that the judy array on hackage is the way to go for mutable maps but I haven't
tried it personally.

