From emilypi at cohomolo.gy Fri Sep 10 01:23:45 2021 From: emilypi at cohomolo.gy (Emily Pillmore) Date: Fri, 10 Sep 2021 01:23:45 +0000 Subject: [ANN] Cabal-3.6.1.0 and cabal-install-3.6.0.0 Message-ID: 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.6.0.0.md. 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%3Ahaskell%2Fcabal%2F14. 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! -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Sep 16 18:21:58 2021 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 16 Sep 2021 14:21:58 -0400 Subject: [Haskell-cafe] Bundle patterns with type aliases In-Reply-To: References: <0EC9C321-12FF-405B-B9BC-10E8DE9D165E@gmail.com> Message-ID: 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 wrote: > I would like that, along with the ability to bundle patterns with classes. > > On Wed, Sep 8, 2021, 1:13 PM Keith 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Thu Sep 16 19:08:45 2021 From: david.feuer at gmail.com (David Feuer) Date: Thu, 16 Sep 2021 15:08:45 -0400 Subject: [Haskell-cafe] Bundle patterns with type aliases In-Reply-To: References: <0EC9C321-12FF-405B-B9BC-10E8DE9D165E@gmail.com> Message-ID: Here's an example: pattern State :: (s -> (a, s)) -> State s a pattern State f <- (coerce . runStateT -> f) where State = state This would be very nice to bundle with the State type synonym. On Thu, Sep 16, 2021, 2:22 PM Carter Schonwald wrote: > 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 wrote: > >> I would like that, along with the ability to bundle patterns with classes. >> >> On Wed, Sep 8, 2021, 1:13 PM Keith 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. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Thu Sep 16 19:12:57 2021 From: david.feuer at gmail.com (David Feuer) Date: Thu, 16 Sep 2021 15:12:57 -0400 Subject: [Haskell-cafe] Bundle patterns with type aliases In-Reply-To: References: <0EC9C321-12FF-405B-B9BC-10E8DE9D165E@gmail.com> Message-ID: Here's a class example: class (MFoldable t, Monoid t) => Sequence t where singleton :: Elem t -> t .... One might wish to write pattern synonyms for viewing the ends of a sequence, like the ones in Data.Sequence, and bundle them with this class. On Thu, Sep 16, 2021, 2:22 PM Carter Schonwald wrote: > 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 wrote: > >> I would like that, along with the ability to bundle patterns with classes. >> >> On Wed, Sep 8, 2021, 1:13 PM Keith 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. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.d.clayden at gmail.com Sat Sep 18 02:29:53 2021 From: anthony.d.clayden at gmail.com (Anthony Clayden) Date: Sat, 18 Sep 2021 14:29:53 +1200 Subject: InstanceSigs -- rationale for the "must be more polymorphic than" Message-ID: > 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." -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.d.clayden at gmail.com Sun Sep 19 06:43:29 2021 From: anthony.d.clayden at gmail.com (Anthony Clayden) Date: Sun, 19 Sep 2021 18:43:29 +1200 Subject: Was: [Haskell-cafe] Haskell reference documentation, laws first or laws last? Message-ID: (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`.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Sun Sep 19 06:49:11 2021 From: david.feuer at gmail.com (David Feuer) Date: Sun, 19 Sep 2021 02:49:11 -0400 Subject: Was: [Haskell-cafe] Haskell reference documentation, laws first or laws last? In-Reply-To: References: Message-ID: No, fromList is too much. Consider data Foo a = Foo (IORef String) [a] deriving Foldable What IORef should fromList use? On Sun, Sep 19, 2021, 2:44 AM Anthony Clayden wrote: > (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`.) > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coot at coot.me Sun Sep 19 11:39:55 2021 From: coot at coot.me (coot at coot.me) Date: Sun, 19 Sep 2021 11:39:55 +0000 Subject: Was: [Haskell-cafe] Haskell reference documentation, laws first or laws last? In-Reply-To: References: Message-ID: Another example are non-empty containers, e.g. for `NonEmpty`  one cannot have a total `fromList :: [a] -> NonEmpty a`. Regards, Marcin Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, September 19th, 2021 at 08:49, David Feuer wrote: > No, fromList is too much. Consider > > data Foo a = Foo (IORef String) [a]  deriving Foldable > > What IORef should fromList use? > > On Sun, Sep 19, 2021, 2:44 AM Anthony Clayden wrote: > > > (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`.) > > > > _______________________________________________ > > > > Glasgow-haskell-users mailing list > > > > Glasgow-haskell-users at haskell.org > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 509 bytes Desc: OpenPGP digital signature URL: From merijn at inconsistent.nl Mon Sep 20 08:26:24 2021 From: merijn at inconsistent.nl (Merijn Verstraaten) Date: Mon, 20 Sep 2021 10:26:24 +0200 Subject: InstanceSigs -- rationale for the "must be more polymorphic than" In-Reply-To: References: Message-ID: > On 18 Sep 2021, at 04:29, Anthony Clayden wrote: > "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." I would strongly disagree with this statement. I think instance signatures are a perfectly fine feature for the very simple case of "I want type signatures on my bindings, because I've got better stuff to do than memorising signatures or doing type inference in my head." Does that mean they are superfluous, as your initial email suggests? Well, kinda, in the same way that "adding type signatures to top level bindings" is *technically* superfluous, but I still have those on all my top level bindings. Characterising the extension as a miss-feature in the user guide seems weird for a perfectly usable and useful extension. Cheers, Merijn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: