
GHC 8.0.1 is available - patrickmn
https://ghc.haskell.org/trac/ghc/blog/ghc-8.0.1-released
======
TazeTSchnitzel

      * 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 Object = Object { name :: String, id :: UUID } -- error! `name` taken
    

\--

Edit: Info on the extension at:
[https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedReco...](https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/DuplicateRecordFields).
Looks like it creates ambiguity in some cases.

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

~~~
MichaelBurge
The record issue is a widespread inconvenience, but ultimately nothing more
than an inconvenience. Most people just prepended the type in their fields:
'person_name' and 'object_name'.

Some other issues might be:

* The Prelude is hard to update for compatibility reasons, so it clashes with modern Haskell somewhat. A lot of projects will roll their own prelude and add 'NoImplicitPrelude' to the project options.

* There's also this presentation: [https://secure.plaimi.net/~alexander/tmp/pres/2016-05-11-why...](https://secure.plaimi.net/~alexander/tmp/pres/2016-05-11-why-haskell-sucks.html#1)

* Deploying Haskell programs to older corporate servers is doable, but not at all obvious. Stick with C, Bash, and older Perls(5.8.8 is on my router) for maximum portability, if you expect to deploy to servers with a 10 year old image.

~~~
iso-8859-1
Regarding deployment, why not just link statically?
[http://stackoverflow.com/a/5953787/309483](http://stackoverflow.com/a/5953787/309483)

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

~~~
carterschonwald
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 ;)

~~~
mitchty
Already built for alpine linux, and I have it setup to use a stage 2
bootstrap. So you build off debian, then build locally to build an alpine apk.

[https://github.com/mitchty/alpine-linux-ghc-
bootstrap](https://github.com/mitchty/alpine-linux-ghc-bootstrap)

Recently updated last week to 8.0.1, and its submitted upstream but not yet
accepted because alpine linux 3.4 is about to come out.

If you want to try it now you can docker pull mitchty/alpine-ghc:8.0

------
imh

        * Significant improvements in error message readability and 
          content, including facilities for libraries to provide custom
          error messages, more aggressive warnings for fragile rewrite
          rules, and more helpful errors for missing imports.
    

I'm really excited about this. Any push towards more decipherable error
messages should be huge in increasing adoption (which leads to more awesome
libraries and opportunities to use it for our day jobs).

I still see plenty of errors that remind me of this post.
[https://izbicki.me/blog/error-messages-in-ghc-
vs-g%2B%2B.htm...](https://izbicki.me/blog/error-messages-in-ghc-
vs-g%2B%2B.html)

------
MichaelBurge
The FPComplete guys will probably have it up on Stackage in a few days. You
can still use it by adding the tarball to your stack.yml, and maybe adding the
'allow-newer: true' flag:

[https://www.reddit.com/r/haskell/comments/4kdb74/is_a_stacka...](https://www.reddit.com/r/haskell/comments/4kdb74/is_a_stackage_snapshot_for_ghc_80_on_the_way/)

I'm looking forward to trying out the new debugging support: gdb was unusable
with older GHCs.

Implicit callstacks are cool: Remember that you can hide the parameter inside
of your application's main monad:

    
    
        type MyApplicationM a = (?l :: CallStack) => StateT ConnectionPool IO a
    

I've certainly run into a lot of the other stuff too. Good release all-around!

~~~
bgamari
> I'm looking forward to trying out the new debugging support: gdb was
> unusable with older GHCs.

Indeed; it should be slightly better now but as the documentation says, there
are still plenty of rough edges. I certainly wouldn't recommend it for day-to-
day use. I have a patch set in the works which ought to fix the remaining
issues so hopefully 8.2 will finally be usable.

However, in my experience the implicit callstack functionality along with the
ability to provide callstacks from profiling information greatly reduces the
need for DWARF unwinding for debugging (low-cost profiling, on the other hand,
it may still be quite useful for).

------
cm3
The new Sphinx based documentation has many code sample boxes where the
content overflows and the rectange is smaller than the text which doesn't fit
into the rendered HTML/PDF. Is this a common issue with Sphinx?

~~~
bgamari
Hmmm, I've noticed this in the PDF output but haven't yet seen anything
similar in the HTML output. Could you point me at a specific example?

~~~
cm3
Rebuilding the latest release now, was referring to previous RCs. It may very
well be just the PDF output. I'll check Sunday and report here.

~~~
cm3
One example: 3.2.8, the second code box about hsc2hs.

HTML of the same section is fine.

There must be a way to fix this in the pipeline. I mean, you cannot find each
and all and try to manually adjust the text.

~~~
DasIch
I don't see the problem on this page[1]. In any case this would be an issue
with the builder that turns the doctree into HTML, PDF or whatever.

[1]:
[https://ghc.readthedocs.io/en/latest/8.0.1-notes.html#hsc2hs](https://ghc.readthedocs.io/en/latest/8.0.1-notes.html#hsc2hs)

~~~
cm3
As I wrote, HTML is fine, PDF is not.

