- Glasgow-haskell-users

ghc doesn't work after installing 9.4.1 on my Mac
by George Colpitts 09 Aug '22

09 Aug '22

Unfortunately ghc doesn't work after installing 9.4.1 on my Mac. Does it work for others? After the install finishes when I do the following: $ ghc --version bash: /usr/local/bin/ghc: Permission denied $ sudo chmod +x /usr/local/bin/ghc $ghc --version /usr/local/bin/ghc: line 1: exec: : not found $ cat /usr/local/bin/ghc exec "$executablename" -B"$libdir" ${1+"$@"} $ cat /usr/local/bin/ghc-9.4.1 #!/bin/sh exedir="/usr/local/lib/ghc-9.4.1/bin" exeprog="ghc-9.4.1" executablename="/usr/local/lib/ghc-9.4.1/bin/ghc-9.4.1" bindir="/usr/local/bin" libdir="/usr/local/lib/ghc-9.4.1/lib" docdir="/usr/local/share/doc/ghc-9.4.1" includedir="/usr/local/include" exec "$executablename" -B"$libdir" ${1+"$@"} Thanks George On Sun, Aug 7, 2022 at 6:30 PM Ben Gamari <ben(a)well-typed.com> wrote: > The GHC developers are very pleased to announce the availability of GHC > 9.4.1. Binary distributions, source distributions, and documentation are > available at downloads.haskell.org: > > https://downloads.haskell.org/ghc/9.4.1 > > This release includes: > > - A new profiling mode, `-fprof-late`, which adds automatic cost-center > annotations to all top-level functions *after* Core optimisation has > run. This provides informative profiles while interfering > significantly less with GHC's aggressive optimisations, making it > easier to understand the performance of programs which depend upon > simplification.. > > - A variety of plugin improvements including the introduction of a new > plugin type, *defaulting plugins*, and the ability for typechecking > plugins to rewrite type-families. > > - An improved constructed product result analysis, allowing unboxing of > nested structures, and a new boxity analysis, leading to less reboxing. > > - Introduction of a tag-check elision optimisation, bringing > significant performance improvements in strict programs. > > - Generalisation of a variety of primitive types to be levity > polymorphic. Consequently, the `ArrayArray#` type can at long last be > retired, replaced by standard `Array#`. > > - Introduction of the `\cases` syntax from [GHC proposal 0302]. > > - A complete overhaul of GHC's Windows support. This includes a > migration to a fully Clang-based C toolchain, a deep refactoring of > the linker, and many fixes in WinIO. > > - Support for multiple home packages, significantly improving support > in IDEs and other tools for multi-package projects. > > - A refactoring of GHC's error message infrastructure, allowing GHC to > provide diagnostic information to downstream consumers as structured > data, greatly easing IDE support. > > - Significant compile-time improvements to runtime and memory consumption. > > - On overhaul of our packaging infrastructure, allowing full > traceability of release artifacts and more reliable binary > distributions. > > - Reintroduction of deep subsumption (which was previously dropped with > the > *simplified subsumption* change) as a language extension. > > - ... and much more. See the [release notes] for a full accounting. > > Note that, as 9.4.1 is the first release for which the released artifacts > will > all be generated by our Hadrian build system, it is possible that there > will be > packaging issues. If you enounter trouble while using a binary > distribution, > please open a [ticket]. Likewise, if you are a downstream packager, do > consider > migrating to [Hadrian] to run your build; the Hadrian build system can be > built > using `cabal-install`, `stack`, or the in-tree [bootstrap script]. See the > accompanying > [blog post] for details on migrating packaging to Hadrian. > > We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, > Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and > other anonymous contributors whose on-going financial and in-kind support > has > facilitated GHC maintenance and release management over the years. Finally, > this release would not have been possible without the hundreds of > open-source > contributors whose work comprise this release. > > As always, do give this release a try and open a [ticket] if you see > anything amiss. > > Happy testing, > > - Ben > > > [GHC proposal 0302]: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0302-c… > [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new > [bootstrap script]: > https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… > [Hadrian]: > https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… > [release notes]: > https://downloads.haskell.org/~ghc/9.4.1/docs/users_guide/9.4.1-notes.html > [blog post]: > https://www.haskell.org/ghc/blog/20220805-make-to-hadrian.html > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >

1 0

Re: [Haskell-cafe] [ANNOUNCE] GHC 9.4.1 is now available
by Ben Gamari 08 Aug '22

08 Aug '22

Bruno Damour <bruno(a)ruomad.net> writes: > Hello, > Thanks for this new release ! > Do you plan to add FreeBSD binaries ? Yes, I have recently been working on the FreeBSD CI infrastructure [1] and hope to have this finished in time for 9.4.2. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6318

1 0

[ANNOUNCE] GHC 9.4.1-rc1 is now available
by Ben Gamari 27 Jul '22

27 Jul '22

The GHC developers are happy to announce the availability of the first (and likely last) release candidate of GHC 9.4.1. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org] This major release will include: - A new profiling mode, `-fprof-late`, which adds automatic cost-center annotations to all top-level functions *after* Core optimisation has run. This provides informative profiles while interfering significantly less with GHC's aggressive optimisations, making it easier to understand the performance of programs which depend upon simplification.. - A variety of plugin improvements including the introduction of a new plugin type, *defaulting plugins*, and the ability for typechecking plugins to rewrite type-families. - An improved constructed product result analysis, allowing unboxing of nested structures, and a new boxity analysis, leading to less reboxing. - Introduction of a tag-check elision optimisation, bringing significant performance improvements in strict programs. - Generalisation of a variety of primitive types to be levity polymorphic. Consequently, the `ArrayArray#` type can at long last be retired, replaced by standard `Array#`. - Introduction of the `\cases` syntax from [GHC proposal 0302] - A complete overhaul of GHC's Windows support. This includes a migration to a fully Clang-based C toolchain, a deep refactoring of the linker, and many fixes in WinIO. - Support for multiple home packages, significantly improving support in IDEs and other tools for multi-package projects. - A refactoring of GHC's error message infrastructure, allowing GHC to provide diagnostic information to downstream consumers as structured data, greatly easing IDE support. - Significant compile-time improvements to runtime and memory consumption. - On overhaul of our packaging infrastructure, allowing full traceability of release artifacts and more reliable binary distributions. - Reintroduction of deep subsumption (which was previously dropped with the *simplified subsumption* change) as a language extension. - ... and much more. See the [release notes] for a full accounting. Note that, as 9.4.1 is the first release for which the released artifacts will all be generated by our Hadrian build system, it is possible that there will be packaging issues. If you enounter trouble while using a binary distribution, please open a [ticket]. Likewise, if you are a downstream packager, do consider migrating to [Hadrian] to run your build; the Hadrian build system can be built using `cabal-install`, `stack`, or the in-tree [bootstrap script]. We will be publishing a blog post describing the migration process to Hadrian in the coming weeks. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket] if you see anything amiss. Happy testing, - Ben [downloads.haskell.org] https://downloads.haskell.org/ghc/9.4.1-rc1/ [GHC proposal 0302]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0302-c… [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [bootstrap script]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… [Hadrian]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… [release notes]: https://downloads.haskell.org/~ghc/9.4.1-rc1/docs/users_guide/9.4.1-notes.h…

4 10

Compilation of Overloaded strings and saving constant results
by Clinton Mead 25 Jul '22

25 Jul '22

Hi All I'm presuming (correct me if I'm wrong) that when I have an overloaded string literal in my program, let's say it's overloaded to Text, the conversion from [Char] -> Text happens at runtime, instead of what would be ideal being that the compiler somehow does that conversion at compile time and puts the raw bytes that represent the Text object in the executable? If it does work like that, that's not a big deal. But let's say I have: f :: Text -> Text -> Text f x y = Text.concat ["Hello", x, "World", y] This is desugared like so: f :: Text -> Text -> Text f x y = Text.concat [fromString "Hello", x, fromString "World", y] Would there be a [Char] -> Text conversion from ['H', 'e', 'l', 'l', 'o'] -> Text "Hello" everytime 'f' is called, or is 'f' rewritten something like this: f :: Text -> Text -> Text f x y = Text.concat [hello, x, world, y] hello :: Text hello = fromString "Hello" world :: Text world = fromString "World" So the [Char] -> Text conversion is only done once and memomised? I guess this brings up the more general question, if I have this: f x = h x (g (42 :: Int)) Can I rely on GHC rewriting it like this? f x = h x y y = g (42 :: Int) Or is this a transformation I should do explicitly if I want to rely on it? (I've added ":: Int" because I guess it can't do this when there's polymorphism sneaking in) Thanks, Clinton

2 1

Heads up on mailing list stability
by Gershom B 29 Jun '22

29 Jun '22

Hi all! We're incrementally transitioning some of our mail sending to a new server. This list is one of the first being migrated to be relayed through the new server (we're also moving the ghc steering-committee list). If sending or receiving is dodgier than usual, please let me know! --Gershom

1 0

Can I create a representation polymorphic datatype?
by Clinton Mead 29 Jun '22

29 Jun '22

Hi All I can make a list of unboxed ints like below: {-# LANGUAGE MagicHash #-} import GHC.Exts (Int#, Float#) data IntList = IntTail | IntNode Int# IntList intListLength :: IntList -> Int intListLength IntTail = 0 intListLength (IntNode _ rest) = 1 + intListLength rest I can then make a list of unboxed floats similarly: data FloatList = FloatTail | FloatNode Int# FloatList floatListLength :: FloatList -> Int floatListLength FloatTail = 0 floatListLength (FloatNode _ rest) = 1 + floatListLength rest But as you can see, this is getting a bit copy-pasta, which is not good. So instead, lets try this: newtype GeneralList (a :: l) = Tail | Node a (GeneralList a) This is not allowed here, I believe because `GeneralList` is expected to have one representation for all `a`, instead of a representation which depends on `a`. This is so that if one writes a function: generalListLength :: GeneralList a -> Int generalListLength Tail = 0 generalListLength (Node _ rest) = 1 + generalListLength rest You can't actually compile this into one function, because the relative location of the "next" pointer can change based on the size of `a` (assuming `a` is stored first). However, I can achieve what I want with copy pasting or Template Haskell hackery. Is there a way to get GHC to do the copy pasting for me? Or do I have to make a choice between extra runtime indirection and avoiding ugly code or having ugly code but avoiding the runtime indirection? A representation polymorphic list here is something that languages like C++, Rust, and even C# will handle happily, so Haskell seems behind here unless I'm missing something,

2 1

GHC 9.4.1-alpha3 now available
by Ben Gamari 24 Jun '22

24 Jun '22

The GHC developers are happy to announce the availability of the third alpha release of the GHC 9.4 series. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org](https://downloads.haskell.org/ghc/9.4.1-alpha3). This major release will include: - A new profiling mode, `-fprof-late`, which adds automatic cost-center annotations to all top-level functions *after* Core optimisation has run. This incurs significantly less performance cost while still providing informative profiles. - A variety of plugin improvements including the introduction of a new plugin type, *defaulting plugins*, and the ability for typechecking plugins to rewrite type-families. - An improved constructed product result analysis, allowing unboxing of nested structures, and a new boxity analysis, leading to less reboxing. - Introduction of a tag-check elision optimisation, bringing significant performance improvements in strict programs. - Generalisation of a variety of primitive types to be levity polymorphic. Consequently, the `ArrayArray#` type can at long last be retired, replaced by standard `Array#`. - Introduction of the `\cases` syntax from [GHC proposal 0302] - A complete overhaul of GHC's Windows support. This includes a migration to a fully Clang-based C toolchain, a deep refactoring of the linker, and many fixes in WinIO. - Support for multiple home packages, significantly improving support in IDEs and other tools for multi-package projects. - A refactoring of GHC's error message infrastructure, allowing GHC to provide diagnostic information to downstream consumers as structured data, greatly easing IDE support. - Significant compile-time improvements to runtime and memory consumption. - On overhaul of our packaging infrastructure, allowing full traceability of release artifacts and more reliable binary distributions. - ... and much more. See the [release notes] for a full accounting. Note that, as 9.4.1 is the first release for which the released artifacts will all be generated by our Hadrian build system, it's possible that there will be packaging issues. If you enounter trouble while using a binary distribution, please open a [ticket]. Likewise, if you are a downstream packager, do consider migrating to [Hadrian] to run your build; the Hadrian build system can be built using `cabal-install`, `stack`, or the in-tree [bootstrap script]. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket] if you see anything amiss. Happy testing, - Ben [GHC proposal 0302]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0302-c… [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [bootstrap script]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… [Hadrian]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… [release notes]: https://downloads.haskell.org/~ghc/9.4.1-alpha3/docs/users_guide/9.4.1-note…

1 0

Two-factor authentication enforced on gitlab.haskell.org
by Ben Gamari 08 Jun '22

08 Jun '22

Hi all, Due to a recent up-tick in spam activity, we have started enforcing two-factor authentication on gitlab.haskell.org. We hope that this isn't too much of a burden, but do let us know if so and we can evaluate other options. Cheers, - Ben

1 1

[Haskell] [ANNOUNCE] GHC 9.2.3 released
by Zubin Duggal 27 May '22

27 May '22

The GHC developers are very happy to at announce the availability of GHC 9.2.3. Binary distributions, source distributions, and documentation are available at [`downloads.haskell.org`](https://downloads.haskell.org/ghc/9.2.3). Download Page: https://www.haskell.org/ghc/download_ghc_9_2_3.html Blog Post: https://www.haskell.org/ghc/blog/20220527-ghc-9.2.3-released.html This release includes many bug-fixes and other improvements to 9.2.2 including: * A fix to a critical linking bug on Windows causing the 9.2.2 release to be unusable (#21196). * Numerous bug fixes for regressions and other issues in the typechecker (#2147, #21515, #20582, #20820, #21130, #21479). * Correctness bugs in the code generator and compiler backends (#21396, #20959, #21465). * Packaging fixes on many platforms (#20760, #21487, #21402). * Many others. See the [release notes][] for a full list. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket] if you see anything amiss. Happy compiling, - Zubin [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/ghc/9.2.3/docs/html/users_guide/9.2.3-notes.h…

3 2

GHC.X.Hackage and GHC's release cycle
by Ben Gamari 27 May '22

27 May '22

Hello all, Recently in the Haskell Foundation's stability working group we have been discussing various practical issues that Haskell users and prospective adopters encounter around the ecosystem. During these discussions the topic of GHC's release schedule and the ecosystem's process migration to new GHC releases has come up repeatedly. To address some of these issues, I have opened a pair of somewhat-related HF Tech Proposals: * the GHC.X.Hackage proposal ([ghc.x.hackage]) seeks to extend the [head.hackage] infrastructure used to test GHC to enable use by library maintainers in porting and testing their libraries on new GHC releases. * the [tick-tock] release proposal seeks to provide better guidance to users needing long release lifecycles by designating every other release as a "long-term support" release, with 18-month backport window. Given the wide applicability of these proposals we hope to gather feedback from a broad swath of the community. If you have questions, opinions, or concerns on either, please leave your feedback on the respective proposal. We look forward to hearing from you. Thanks! - Ben [ghc.x.hackage]: https://github.com/haskellfoundation/tech-proposals/pull/27 [head.hackage]: https://ghc.gitlab.haskell.org/head.hackage/ [tick-tock]: https://github.com/haskellfoundation/tech-proposals/pull/34

1 0