Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GHC 8.0.1 is available

ghc.haskell.org

Post reply on HN
Print view View original

31–38 of 38 posts

Re: GHC 8.0.1 is available

#31

Post by DasIch »

cm3 wrote: post #24
cm3 wrote: post #16

Earlier quoted context omitted.

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.

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.

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

Re: GHC 8.0.1 is available

#32

Post by p4wnc6 »

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

I've never encountered a situation in which the One File - One Module imposed convention was problematic. I also find it greatly helps when reading new Haskell code bases. I think it's generally a sign of good project design when there are lots and lots of small files, each with one data structure and a few associated functions.

Re: GHC 8.0.1 is available

#33

Post by cm3 »

DasIch wrote: post #31
cm3 wrote: post #24

Earlier quoted context omitted.

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.

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

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

Re: GHC 8.0.1 is available

#34

Post by mitchty »

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

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

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

Re: GHC 8.0.1 is available

#35

Post by chadaustin »

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…

Your argument generalizes to "The lack of any feature that can be worked around is an inconvenience", which, okay, but it's not a very useful statement. By that definition, lots of really important things are inconveniences.

Re: GHC 8.0.1 is available

#36

Post by eru »

p4wnc6 wrote: post #32
eru wrote: post #26

Earlier quoted context omitted.

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

I've never encountered a situation in which the One File - One Module imposed convention was problematic. I also find it greatly helps when reading new Haskell code bases. I think it's generally a sign of good project design when there are lots and lots of small files, each with one data structure and a few associated functions.

For most of what I want, being able to introduce additional namespaces would be good enough. Making them modules as well could open the doors to some need techniques.

(I don't need multiple namespaces per file so much for the finished program, but it's handy when developing.)

Re: GHC 8.0.1 is available

#37

Post by eru »

johncolanduoni wrote: post #28
eru wrote: post #25

Earlier quoted context omitted.

> What would be nice is if Haskell would allow any name collision so long as it could use the type system to disambiguate the function. That would need very careful design to work well with type inference, I suppose?

Idris[1] already has a working system for this, and it's type system is more complicated (it has much more support for dependent typing). It allows this principle for regular function names as well. [1]: http://www.idris-lang.org/

Thanks! I'm glad we have a working model we can probably copy from.

Re: GHC 8.0.1 is available

#38

Post by ElvishJerricco »

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…

It's ok... But I think we really want a more comprehensive solution. Anonymous record types are really what we want.
Post reply on HN