GHC 8.0.1 is available

Post by rjayatilleka » Sun, May 22, 2016, 3:57 AM UTC

dopu wrote: post #4

TazeTSchnitzel wrote: post #3

* The introduction of the DuplicateRecordFields language extension, allowing multiple record types to declare fields of the same name Holy hell. Is this the end of the Haskell record field names problem? One of Haskell's great miseries has been that, because record field accessors are declared globally, you couldn't define records with fields of the same names: data Person = Person { name :: String, age :: Int } data…

As a recent beginner to Haskell, are there other big outstanding issues with the GHC to watch out for?

Post by Johnny_Brahms » Sun, May 22, 2016, 5:56 AM UTC

rjayatilleka wrote: post #21

dopu wrote: post #4

Earlier quoted context omitted.

As a recent beginner to Haskell, are there other big outstanding issues with the GHC to watch out for?

There was a large (but informal) survey done on /r/haskell (one of the largest Haskell communities) last month about "Why Haskell sucks". The results were collated into a presentation linked below. It's a very detailed review that covers just about everything "bad" about Haskell (though I think it views each issue rather optimistically). Presentation: https://secure.plaimi.net/~alexander/tmp/pres/2016-05-11-why... ED…

Post by eru » Sun, May 22, 2016, 11:05 AM UTC

gizmo686 wrote: post #19

GreaterFool wrote: post #18

Earlier quoted context omitted.

Record issue is more than just an inconvenience. I consider it a genuine issue. Having to add 2 lines of import (unqualified name of the type and qualified record module to get the accessors) for every record type you use is a pain. When you work with data-heavy code this ends up hundred of lines of import (see amazonka packages for instance where each request has a record type).

Even if it doubles the number of import statements, I still don't see how that is more than an inconvenience. Having said that, the record issue alone is not the only reason to need qualified imports (as they are also used to resolve collisions of functions that are not auto generated from records). What would be nice is if Haskell would allow any name collision so long as it could use the type system to disambiguate…

Post by lelf » Sun, May 22, 2016, 12:37 PM UTC

eru wrote: post #26

p4wnc6 wrote: post #22

Earlier quoted context omitted.

I actually quite like this limitation. It encourages you to separate data structures into their own modules and use qualified names to access their member data, which I think is often the right idea.

If only Haskell would be more like OCaml in this regard, and would allow you to eg nest module, instead of saying "One File = One Module".

Post by cm3 » Sun, May 22, 2016, 2:04 PM UTC

carterschonwald wrote: post #17

MichaelBurge wrote: post #15

Earlier quoted context omitted.

You can't link glibc statically for technical reasons. In some sense, this is the only problem I had. If there was a way to use an alternate libc, it would probably eliminate this issue entirely.

I know there was some work to do a musl and or alpine Linux build. Or both, probably easy to google. Also I'm moderately certain that ghc on FreeBSD and Mac don't need glibc ;)