- Glasgow-haskell-users

Re: [Haskell] [ANNOUNCE] GHC 9.0.2 released
by Zubin Duggal 25 Dec '21

25 Dec '21

Oops. Pushed! On 21/12/25 15:37, Shayne Fletcher wrote: >Awesome. Thank-you! There appears not to be a ghc-9.0.2-release tag. Might >this be addressed please? >

1 0

[ANNOUNCE] GHC 9.2.1 now available
by Ben Gamari 17 Nov '21

17 Nov '21

Hi all, The GHC developers are very happy to at long last announce the availability of GHC 9.2.1. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.2.1 GHC 9.2 brings a number of exciting features including: * A native code generation backend for AArch64, significantly speeding compilation time on ARM platforms like the Apple M1. * Many changes in the area of records, including the new `RecordDotSyntax` and `NoFieldSelectors` language extensions, as well as Support for `DuplicateRecordFields` with `PatternSynonyms`. * Introduction of the new `GHC2021` language extension set, giving users convenient access to a larger set of language extensions which have been long considered stable. * Merging of `ghc-exactprint` into the GHC tree, providing infrastructure for source-to-source program rewriting out-of-the-box. * Introduction of a `BoxedRep` `RuntimeRep`, allowing for polymorphism over levity of boxed objects (#17526) * Implementation of the `UnliftedDataTypes` extension, allowing users to define types which do not admit lazy evaluation ([proposal]) * The new [`-hi` profiling] mechanism which provides significantly improved insight into thunk leaks. * Support for the `ghc-debug` out-of-process heap inspection library [ghc-debug] * Significant improvements in the bytecode interpreter, allowing more programs to be efficently run in GHCi and Template Haskell splices. * Support for profiling of pinned objects with the cost-centre profiler (#7275) * Faster compilation and a smaller memory footprint * Introduction of Haddock documentation support in TemplateHaskell (#5467) Finally, thank you to Microsoft Research, GitHub, IOHK, 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. Moreover, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do open a [ticket] if you see anything amiss. Happy testing, - Ben [apple-m1]: https://www.haskell.org/ghc/blog/20210309-apple-m1-story.html [proposal]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0265-u… [-hi profiling]: https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/ [ghc-debug]: http://ghc.gitlab.haskell.org/ghc-debug/ [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new

7 9

osx conundrum
by David Duke 14 Oct '21

14 Oct '21

I have a conundrum on which advice would be appreciate. Does anyone know how to successfully install ghc on OSX I've tried various binary instalation routes: macports, brew, direct binary downloads from haskel.org All have the same result. when I try to compile a basic hello world program I get Undefined symbols for architecture x86_64: "_iconv", referenced from: _hs_iconv in libHSbase-4.14.3.0.a(iconv.o) (maybe you meant: _base_GHCziIOziEncodingziIconv_iconvEncoding1_closure, _base_GHCziIOziEncodingziIconv_iconvEncoding1_info , _base_GHCziIOziEncodingziIconv_iconvEncoding4_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding15_info , _base_GHCziIOziEncodingziIconv_iconvEncoding4_info , _base_GHCziIOziEncodingziIconv_iconvEncoding7_info , _base_GHCziIOziEncodingziIconv_iconvEncoding6_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding6_info , _base_GHCziIOziEncodingziIconv_iconvEncoding8_info , _hs_iconv_open , _base_GHCziIOziEncodingziIconv_iconvEncoding9_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding12_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding11_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding9_info , _base_GHCziIOziEncodingziIconv_iconvEncoding12_info , _base_GHCziIOziEncodingziIconv_iconvEncoding13_info , _base_GHCziIOziEncodingziIconv_iconvEncoding11_info , _base_GHCziIOziEncodingziIconv_iconvEncoding7_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding_info , _base_GHCziIOziEncodingziIconv_iconvEncoding13_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding2_info , _base_GHCziIOziEncodingziIconv_iconvEncoding14_bytes , _base_GHCziIOziEncodingziIconv_iconvEncoding15_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding3_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding8_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding2_closure , _hs_iconv , _base_GHCziIOziEncodingziIconv_iconvEncoding10_bytes , _hs_iconv_close , _base_GHCziIOziEncodingziIconv_iconvEncoding5_closure ) "_iconv_open", referenced from: _hs_iconv_open in libHSbase-4.14.3.0.a(iconv.o) (maybe you meant: _hs_iconv_open) "_iconv_close", referenced from: _hs_iconv_close in libHSbase-4.14.3.0.a(iconv.o) (maybe you meant: _hs_iconv_close) "_locale_charset", referenced from: _localeEncoding in libHSbase-4.14.3.0.a(PrelIOUtils.o) ld: symbol(s) not found for architecture x86_64 I've triedgiong through ghcup 8.8.4 8.6.5. 8.10.2 8.10.7 9.0.1 all have the same problem. I'd be happy to build from source. Small problem: what Haskell compiler do I use? Any advice on installs that works along with any changes to paths to avoid the iconv problems would be appreciated as currently my Haskell-related activities have come to a grinding halt. Switchig to a different OS would be nice but its not a feasible option a at present.Writing a compiler is starting to look attractive.. thanks David -- David Duke Emeritus Professor of Computer Science School of Computing University of Leeds UK E:duke.j.david@gmail.com W:https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke

5 10

Re: Glasgow-haskell-users Digest, Vol 212, Issue 5
by Dominic Steinitz 12 Oct '21

12 Oct '21

Hi David I am a long time user of ghc on OSX. I have seen that problem but never on native OSX only when using nix (and then I added it explicitly). Two things spring to mind: Add it explicitly on the compile command `-liconv` Use nix and then you can control the build environment in a totally controllable and reproducible manner. This is actually easier than it sounds: `curl https://nixos.org/nix/install | sh` and `nix-env -I ghc`. If you get the same error with that then we can try adding `iconv` explicitly. Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.org Twitter: @idontgetoutmuch > > I have a conundrum on which advice would be appreciate. Does > anyone know how to successfully install ghc on OSX > I've tried various binary instalation routes: > macports, brew, direct binary downloads from haskel.org > All have the same result. when I try to compile a basic hello world program > I get > > Undefined symbols for architecture x86_64: > "_iconv", referenced from: > > > I've triedgiong through ghcup > > 8.8.4 > 8.6.5. > 8.10.2 > 8.10.7 > 9.0.1 > > all have the same problem. > I'd be happy to build from source. Small problem: what Haskell compiler do > I use? > > Any advice on installs that works along with any changes to paths to avoid > the iconv problems would be appreciated as currently my Haskell-related > activities have come to a grinding halt. Switchig to a different OS would > be nice but its not a > feasible option a at present.Writing a compiler is starting to look > attractive.. > > thanks > David > > -- > David Duke > Emeritus Professor of Computer Science > School of Computing University of Leeds UK > E:duke.j.david@gmail.com > W:https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke

3 3

Pattern synonym constraints :: Ord a => () => ...
by Anthony Clayden 06 Oct '21

06 Oct '21

Thank you to Richard for the Tweag tutorials on Pattern Synonyms. That third one on Matchers was heavy going. I didn't find an answer (or did I miss it?) to something that's bugging me: > pattern SmartConstr :: Ord a => () => ... Seems to mean: * Required constraint is Ord a -- fine, for building * Provided constraint is Ord a -- why? for matching/consuming I'm using `SmartConstr` with some logic inside it to validate/build a well-behaved data structure. But this is an ordinary H98 datatype, not a GADT. I don't want to expose the datatype's underlying constructor, because client code could break the abstraction/build an ill-formed data structure. If I pattern-match on `SmartConstr`, the consuming function wants `Ord a`. But I can't always provide `Ord a`, because this isn't a GADT. And the client's function could be doing something that doesn't need `Ord a` -- like counting elements, or showing them or streaming to a List, etc. This feels a lot like one of the things that's wrong with 'stupid theta' datatype contexts. My work-round seems to be to define a second `ReadOnlyConstr` without constraints, that's unidirectional/ can't be used for building. For definiteness, the use case is a underlying non-GADT constructor for a BST > Node :: Tree a -> a -> Tree a -> Tree a > > pattern SmartNode :: Ord a => () => Tree a -> a -> Tree a -> Tree a with the usual semantics that the left Tree holds elements less than this node. Note it's the same `a` with the same `Ord a` 'all the way down' the Tree. If some function is consuming the Tree, it can provide constraints for its own purposes: > member :: Ord a => a -> Tree a -> Bool > dumbElem :: Eq a => a -> Tree a -> Bool > max :: Ord a => Tree a -> a (That again is the same thinking behind deprecating datatype contexts.) > countT (SmartNode l x r) = countT l + 1 + countT r -- why infer Ord a => ? > > class FancyShow t where > fancyShow :: Show a => Int -> t a -> String > instance FancyShow Tree where > fancyShow indent (SmartNode l x r) = ... -- rejected: Could not deduce Ord a > (Ref the parallel thread on Foldable: client code can't declare an instance for a Constructor class using SmartConstr.) I can see commonly your Provided would be at least the constraints inside the GADT constructor. But why presume I have a GADT? (And yes I get that a devlishly smart pattern might be building different GADT constrs/various constraints, so this is difficult to infer.) AntC

7 14

Re: InstanceSigs -- rationale for the "must be more polymorphic than"
by Anthony Clayden 20 Sep '21

20 Sep '21

> If you would like to offer a patch for the user manual to explain this better, that would be great. Thank you Simon for the invitation. On further investigation https://gitlab.haskell.org/ghc/ghc/-/issues/20357, what I'd like the user manual to say is: "InstanceSigs is a mis-feature. Don't use it. It is less confusing to just give no signature at all. If you really, really want to bind tyvars, use PatternSignatures."

2 1

Was: [Haskell-cafe] Haskell reference documentation, laws first or laws last?
by Anthony Clayden 19 Sep '21

19 Sep '21

(Moving this discussion to glasgow-users. It's just not appropriate on the cafe.) > I am no longer a novice, and yet would still have a hard time making any use of the laws as written in constructing instances. Instead, I'd ignore the laws and write a natural intuitive instance, and it would invariably work. Seems my approach is very similar to Viktor's. My (very informal) understanding of the Laws looks nothing like the docos. I regard Foldable structures as merely more efficient ways to hold a List. Then I expect 'moral equivalences': > toList . fromList ~=~ id -- going via the Foldable structure > fromList . toList ~=~ id > toList ~=~ foldr (:) [] But those aren't equalities. 'moral equivalence' means the Lists have the same elements, not necessarily in the same order; the structures have the same elements but possibly in a different arrangement -- that is, in the `Tree` example, there might be `Empty` scattered about, and elements held variously in `Leaf`s vs `Node`s. So more accurately: > fromList . toList . fromList === fromList -- i.e. there's a 'canonical' arrangement > toList . fromList . toList === toList -- i.e. there's a 'canonical' List ordering (That triple-journey business is a similar style to defining Lattice pseudocomplements https://en.wikipedia.org/wiki/Pseudocomplement#Properties -- if I can chuck in some math theory.) I'd expect all other methods to be one of: `reduceStuff === reduceStuff . toList` or `mapStuff === fromList . mapStuff . toList`. But! there's no method `fromList` in Foldable. Why not?/please explain. (Are there Foldable structures which we can't load from a List? At least assuming the List is finite.) `fromList` is the first thing I write after declaring the datatype, so I can easily load up some test data. There is one example `fromList` in the doco. Is that not generalisable? `foldMap Leaf` would be brutal, but should work? `foldMap singleton` ? (But there's no method `singleton`.)

3 2

Re: [Haskell-cafe] Bundle patterns with type aliases
by Carter Schonwald 16 Sep '21

16 Sep '21

These are great ideas! Could you please create a ghc tracker ticket with a tiny examples or two? There may be specific technical reasons we might not be able to do so for type synonyms in ghc, but I don’t see any obvious barriers in the case of David’s excellent idea, I’ve def seen lots of great code out there where you’d really want either associated pattern synonyms or to bundle pattern synonyms with the exported public interface for a type class. I’m sure there’s some devil in the details but these sound lovely. Step -1 is making up 1-2 toy examples and explaining what and why you want it on a ghc ticket! On Wed, Sep 8, 2021 at 1:25 PM David Feuer <david.feuer(a)gmail.com> wrote: > I would like that, along with the ability to bundle patterns with classes. > > On Wed, Sep 8, 2021, 1:13 PM Keith <keith.wygant(a)gmail.com> wrote: > >> Is there currently a way to 'bundle' a pattern with a type alias? And if >> not, could that capability be added to the PatternSynonyms GHC extension? >> (Is this the right place to ask, or should I be asking a GHC list?) >> >> --Keith >> Sent from my phone with K-9 Mail. >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post.

2 2

[ANN] Cabal-3.6.1.0 and cabal-install-3.6.0.0
by Emily Pillmore 09 Sep '21

09 Sep '21

Hello all, The Cabal team is excited to announce the release of both `Cabal-3.6.1.0`, and `cabal-install-3.6.0.0`! ## Changelog for `Cabal-3.6.1.0` This release of `Cabal` is a point release that allowed us to get some important features out into the ecosystem that just couldn't wait: - Include cmm-sources when linking shared objects - Prefer canonicalized path when guessing tools from GHC path - Fix `cabal test --enable-library-coverage` for modules in the `other-modules` field - set the PATH_SEPARATOR value to `;` when calling `./configure` on Windows (this is necessary for autoconf >=2.7) - Significant speedups to the solver ## Changelog for `cabal-install-3.6.0.0` This is the fourth release of the 3.0 release series for `cabal-install`, introducing features and quality of life improvements including: - Better support for `hsc2hs`, allowing users to pass additional options - Added an `--only-download` flag - extra-packages now works properly - `cabal init` UX improvements - GHC 9.2 support - Fixes to the backpack UX - Removing the spurious warnings for extraneous versions on internal packages - Alerts and spelling suggestions for mispelled comands - Massive improvements to code organization and repository health For a full set of release notes, see https://github.com/haskell/cabal/blob/master/release-notes/cabal-install-3.…. If you have issues, we'd love to hear about them here: https://github.com/haskell/cabal/issues. ## Plans for 3.8 The 3.6 release marks the first in a series where we work to modernize the Cabal project by means of doing away with the idiosyncratic and historical cruft built up, improving the contribution experience. Over the next 6 months, we'll be working hard to improve the state of the repository, including onboarding more maintainers and welcoming new contributors with clearer contribution requirements. To start, we've identified issues and new features that we aim to tackle for the 3.8 release spanning the following: - Better build info for tool creators - Support for stable package sets like LTS - Dropping build/test support for GHCs outside of the 5 year window - Finishing the multilib work - a byte-for-byte bidirectional parser - etc. You can find the full list of 3.8 project issues here: https://github.com/haskell/cabal/issues?q=is%3Aopen+is%3Aissue+project%3Aha…. I'd also like to thank the many contributors who offered patches, tickets, and other help in the preparation of this release. We appreciate all of your help! And a special thank you to the Haskell Language Server team for working with us and the Haskell Foundation to help fund work needed to improve the IDE. Happy hacking!

1 0

[Haskell] [ANNOUNCE] GHC 8.10.7 released
by Zubin Duggal 26 Aug '21

26 Aug '21

The GHC team is very pleased to announce the availability of GHC 8.10.7. Source and binary distributions are available at the [usual place](https://downloads.haskell.org/ghc/8.10.7/). Download Page: https://www.haskell.org/ghc/download_ghc_8_10_7.html Blog Post: https://www.haskell.org/ghc/blog/20210827-ghc-8.10.7-released.html This is a small bugfix release, fixing one linking portability issue (#19950) present in GHC 8.10.5 and GHC 8.10.6 on some x86_64 macOS toolchains, which resulted in undefined symbol errors for `___darwin_check_fd_set_overflow`. Issue #19950 is caused by a bug in newer Apple toolchains (specifically XCode 12) where programs compiled with affected versions of XCode are not backwards compatible with configurations running older version of XCode (certain versions of XCode 11). We claimed to have fixed this in GHC 8.10.6, but alas this wasn't the case. The fix was originally tested on the master branch, which uses a different build configuration from the 8.10 branch. We have now tested the fix on the GHC 8.10 branch and finally squashed the bug. We would like to thank Microsoft Research, GitHub, IOHK, 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. We would also like to thank the hundreds of open-source contributors whose work makes GHC possible. A complete list of bug fixes and improvements can be found in the [release notes](https://downloads.haskell.org/ghc/8.10.7/docs/html/users_guide/8. 10.7-notes.html). As always, feel free to report any issues you encounter via [gitlab.haskell.org](https://gitlab.haskell.org/ghc/ghc/-/issues/new).

1 0