11 ms·

"I've been burned a couple times by portability issues (and the way that "whatever GHC does right now" has become a de-facto standard means that portability iss

"I've been burned a couple times by portability issues (and the way that "whatever GHC does right now" has become a de-facto standard means that portability issues are probably not a priority)" I am interested in this issue and would love to hear more details. Portability between different Haskell implementations or portability of GHC to different operating systems?

blasdel 17y ago
In the early years of Haskell there were a number of implementations experimenting with different things, and eventually the surviving ones converged on a standard -- Haskell 98. Since then (especially in the last 5 years), the GHC community has been regularly releasing all sorts of shiny new toys -- obviously introducing features unsupported by other implementations, but also frequently breaking compatibility with their own previous implementations. OS portability has not been much of an issue. Haskell Prime is an effort underway by the GHC guys to not only define a new set of standard libraries, but to make Python3000-style purposefully incompatible changes to the core language. This is hoped to become a new standard, Haskell 2010.
silentbicycle 17y ago
I should preface this by noting that I haven't looked into the situation recently, and the problem may have been fixed, but it really soured me on Haskell. (At a glance, it looks the same, and discussions with a presenter at a local barcamp implied no real change.) I stopped worrying about it because I'm quite content with Lua for small personal projects, and OCaml and Erlang seem to be more my style than Haskell for larger ones. So, that said: I primarily use OpenBSD and FreeBSD, and bootstrapping recent versions of GHC from source has been broken for a long time. OpenBSD's current GHC is 6.6.1, and FreeBSD's is 6.8.x, but (last time I checked) was marked as broken. While porting language runtimes to OpenBSD can be tricky due to e.g. its randomized malloc, an open-source language that doesn't even build from source on FreeBSD probably doesn't place much of a priority on portability. GHC 6.6.1's ghci segfaults on my openbsd/amd64 system, too. Just after I got settled with XMonad, GHC updated without a clear plan for source bootstrapping. I get the impression that a lot of people just use Debian/Arch/etc., like dons did[1]. (I'm a (somewhat minor) OpenBSD porter, so I probably care about this more than many people.) [1]: http://www.cse.unsw.edu.au/~dons/haskell_openbsd.html http://www.cse.unsw.edu.au/~dons/haskell_openbsd.html - He switched to using Arch in ~2005. Here's a Hackage bug ticket, closed after a year and a half with the note that they're probably just not going to support building that way anymore:(http://hackage.haskell.org/trac/ghc/ticket/1346 http://hackage.haskell.org/trac/ghc/ticket/1346). It's not hard to find griping about the situation on the openbsd-ports list. While GHC is just one compiler (and I've put some time into helping with updating Common Lisp and Scheme ports in the past, due to similar issues), Haskell programmers seem to assume a recent version of GHC and its extensions, making "whatever GHC does" a de-facto standard. That rules it out for me entirely, and I wonder if anybody else feels the same.
- dons 17y ago
  I switched to Arch in 2007 because I needed multicore SMP runtime support. OpenBSD was only running userland apps on 1 core at the time.

blasdel 17y ago

In the early years of Haskell there were a number of implementations experimenting with different things, and eventually the surviving ones converged on a standard -- Haskell 98. Since then (especially in the last 5 years), the GHC community has been regularly releasing all sorts of shiny new toys -- obviously introducing features unsupported by other implementations, but also frequently breaking compatibility with their own previous implementations. OS portability has not been much of an issue. Haskell Prime is an effort underway by the GHC guys to not only define a new set of standard libraries, but to make Python3000-style purposefully incompatible changes to the core language. This is hoped to become a new standard, Haskell 2010.

silentbicycle 17y ago

I should preface this by noting that I haven't looked into the situation recently, and the problem may have been fixed, but it really soured me on Haskell. (At a glance, it looks the same, and discussions with a presenter at a local barcamp implied no real change.) I stopped worrying about it because I'm quite content with Lua for small personal projects, and OCaml and Erlang seem to be more my style than Haskell for larger ones. So, that said: I primarily use OpenBSD and FreeBSD, and bootstrapping recent versions of GHC from source has been broken for a long time. OpenBSD's current GHC is 6.6.1, and FreeBSD's is 6.8.x, but (last time I checked) was marked as broken. While porting language runtimes to OpenBSD can be tricky due to e.g. its randomized malloc, an open-source language that doesn't even build from source on FreeBSD probably doesn't place much of a priority on portability. GHC 6.6.1's ghci segfaults on my openbsd/amd64 system, too. Just after I got settled with XMonad, GHC updated without a clear plan for source bootstrapping. I get the impression that a lot of people just use Debian/Arch/etc., like dons did[1]. (I'm a (somewhat minor) OpenBSD porter, so I probably care about this more than many people.) [1]: http://www.cse.unsw.edu.au/~dons/haskell_openbsd.html http://www.cse.unsw.edu.au/~dons/haskell_openbsd.html - He switched to using Arch in ~2005. Here's a Hackage bug ticket, closed after a year and a half with the note that they're probably just not going to support building that way anymore:(http://hackage.haskell.org/trac/ghc/ticket/1346 http://hackage.haskell.org/trac/ghc/ticket/1346). It's not hard to find griping about the situation on the openbsd-ports list. While GHC is just one compiler (and I've put some time into helping with updating Common Lisp and Scheme ports in the past, due to similar issues), Haskell programmers seem to assume a recent version of GHC and its extensions, making "whatever GHC does" a de-facto standard. That rules it out for me entirely, and I wonder if anybody else feels the same.

dons 17y ago
I switched to Arch in 2007 because I needed multicore SMP runtime support. OpenBSD was only running userland apps on 1 core at the time.