Announce: Haskell 2010 | Hacker News Reader

Announce: Haskell 2010

haskell.org

52 pointsdons15 comments

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.

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

Here's a workaround to get the latest Haskell Platform working on 10.6: http://www.haskell.org/haskellwiki/Mac_OS_X

Yeah. Seriously weak. I was trying to sell someone at work on Haskell and was put in the (very embarrassing) position of having to say that Haskell is broken on snow leopard right now and ports won't even let you install it.

As I stated up-thread, calling it 'broken' is misleading. I compile stuff on 10.6 all the time, just not as 64-bit binaries.

And who needs more than 4GB? I do, but I'm apparently the only one.

You speak as if people are either unaware of the problem, or acting as if "you don't need 64-bit for (some dumb reason)". It has been clearly explained that that is not the problem. Stupid cracks about 4GB are not called for at this point. If you're upset about it, that's fine, if you're upset but not upset enough to fix it, that is also fine, but don't act as if the problem is "not enough sarcasm from earl".

jerf: try reading. I was replying to 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

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."

The situation for 64-bit Windows is similar (http://hackage.haskell.org/trac/ghc/ticket/1884). I imagine it will be even more difficult to find someone with extensive low-level Windows and Unix skills to create the Windows port.

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.

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.

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

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.

Reply on news.ycombinator.com