5 ms·

Announce: Haskell 2010

52 points by dons 17y ago

eelco 17y ago
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.
gjm11 17y ago
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 17y ago
Maybe in 2010 GHC will start working on Snow Leopard. Fingers crossed.
- mbrubeck 17y ago
  Here's a workaround to get the latest Haskell Platform working on 10.6: http://www.haskell.org/haskellwiki/Mac_OS_X http://www.haskell.org/haskellwiki/Mac_OS_X
- earl 17y ago
  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.
  - ionfish 17y ago
    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.
    - earl 17y ago
      And who needs more than 4GB? I do, but I'm apparently the only one.
      - jerf 17y ago
        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".
        earl 17y ago
        jerf: try reading. I was replying to ionfish.
- ionfish 17y ago
  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 http://hackage.haskell.org/trac/ghc/ticket/2965
ramanujan 17y ago
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 17y ago
  > 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 17y ago
    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.

52 points by dons 17y ago

eelco 17y ago

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.

gjm11 17y ago

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 17y ago

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

mbrubeck 17y ago
Here's a workaround to get the latest Haskell Platform working on 10.6: http://www.haskell.org/haskellwiki/Mac_OS_X http://www.haskell.org/haskellwiki/Mac_OS_X
earl 17y ago
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.
- ionfish 17y ago
  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.
  - earl 17y ago
    And who needs more than 4GB? I do, but I'm apparently the only one.
    - jerf 17y ago
      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".
      - earl 17y ago
        jerf: try reading. I was replying to ionfish.
ionfish 17y ago
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 http://hackage.haskell.org/trac/ghc/ticket/2965

ramanujan 17y ago

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 17y ago
> 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 17y ago
  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.