From anthony.d.clayden at gmail.com Sun Oct 3 09:38:05 2021 From: anthony.d.clayden at gmail.com (Anthony Clayden) Date: Sun, 3 Oct 2021 22:38:05 +1300 Subject: Pattern synonym constraints :: Ord a => () => ... Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at richarde.dev Tue Oct 5 16:32:02 2021 From: lists at richarde.dev (Richard Eisenberg) Date: Tue, 5 Oct 2021 16:32:02 +0000 Subject: Pattern synonym constraints :: Ord a => () => ... In-Reply-To: References: Message-ID: <010f017c514c396f-5ee9dc9f-3704-46cb-88ee-ff97133b55a9-000000@us-east-2.amazonses.com> > On Oct 3, 2021, at 5:38 AM, Anthony Clayden wrote: > > > pattern SmartConstr :: Ord a => () => ... > > Seems to mean: > > * Required constraint is Ord a -- fine, for building Yes. > * Provided constraint is Ord a -- why? for matching/consuming No. Your signature specified that there are no provided constraints: that's your (). > > 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 believe there is no way to have provided constraints in Haskell98. You would need either GADTs or higher-rank types. > > This feels a lot like one of the things that's wrong with 'stupid theta' datatype contexts. You're onto something here. Required constraints are very much like the stupid theta datatype contexts. But, unlike the stupid thetas, required constraints are sometimes useful: they might be needed in order to, say, call a function in a view pattern. For example: > checkLT5AndReturn :: (Ord a, Num a) => a -> (Bool, a) > checkLT5AndReturn x = (x < 5, x) > > pattern LessThan5 :: (Ord a, Num a) => a -> a > pattern LessThan5 x <- ( checkLT5AndReturn -> (True, x) ) My view pattern requires (Ord a, Num a), and so I must declare these as required constraints in the pattern synonym type. Because vanilla data constructors never do computation, any required constraints for data constructors are always useless. > > 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. Does SmartNode need Ord a to match? Or just to produce a node? It seems that Ord a is used only for production, not for matching. This suggests that you want a separate smartNode function (not a pattern synonym) and to have no constraints on the pattern synonym, which can be unidirectional (that is, work only as a pattern, not as an expression). It has been mooted to allow pattern synonyms to have two types: one when used as a pattern and a different one when used as an expression. That might work for you here: you want SmartNode to have no constraints as a pattern, but an Ord a constraint as an expression. At the time, the design with two types was considered too complicated and abandoned. Does this help? Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Tue Oct 5 16:38:54 2021 From: david.feuer at gmail.com (David Feuer) Date: Tue, 5 Oct 2021 12:38:54 -0400 Subject: Pattern synonym constraints :: Ord a => () => ... In-Reply-To: <010f017c514c396f-5ee9dc9f-3704-46cb-88ee-ff97133b55a9-000000@us-east-2.amazonses.com> References: <010f017c514c396f-5ee9dc9f-3704-46cb-88ee-ff97133b55a9-000000@us-east-2.amazonses.com> Message-ID: To be clear, the proposal to allow different constraints was accepted, but integrating it into the current, incredibly complex, code was well beyond the limited abilities of the one person who made an attempt. Totally severing pattern synonyms from constructor synonyms (giving them separate namespaces) would be a much simpler design. On Tue, Oct 5, 2021, 12:33 PM Richard Eisenberg wrote: > > > On Oct 3, 2021, at 5:38 AM, Anthony Clayden > wrote: > > > pattern SmartConstr :: Ord a => () => ... > > Seems to mean: > > * Required constraint is Ord a -- fine, for building > > > Yes. > > * Provided constraint is Ord a -- why? for matching/consuming > > > No. Your signature specified that there are no provided constraints: > that's your (). > > > 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 believe there is no way to have provided constraints in Haskell98. You > would need either GADTs or higher-rank types. > > > This feels a lot like one of the things that's wrong with 'stupid theta' > datatype contexts. > > > You're onto something here. Required constraints are very much like the > stupid theta datatype contexts. But, unlike the stupid thetas, required > constraints are sometimes useful: they might be needed in order to, say, > call a function in a view pattern. > > For example: > > checkLT5AndReturn :: (Ord a, Num a) => a -> (Bool, a) > checkLT5AndReturn x = (x < 5, x) > > pattern LessThan5 :: (Ord a, Num a) => a -> a > pattern LessThan5 x <- ( checkLT5AndReturn -> (True, x) ) > > > My view pattern requires (Ord a, Num a), and so I must declare these as > required constraints in the pattern synonym type. Because vanilla data > constructors never do computation, any required constraints for data > constructors are always useless. > > > 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. > > > Does SmartNode need Ord a to match? Or just to produce a node? It seems > that Ord a is used only for production, not for matching. This suggests > that you want a separate smartNode function (not a pattern synonym) and to > have no constraints on the pattern synonym, which can be unidirectional > (that is, work only as a pattern, not as an expression). > > It has been mooted to allow pattern synonyms to have two types: one when > used as a pattern and a different one when used as an expression. That > might work for you here: you want SmartNode to have no constraints as a > pattern, but an Ord a constraint as an expression. At the time, the design > with two types was considered too complicated and abandoned. > > Does this help? > > Richard > _______________________________________________ > 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 ekmett at gmail.com Tue Oct 5 17:11:09 2021 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 5 Oct 2021 13:11:09 -0400 Subject: Pattern synonym constraints :: Ord a => () => ... In-Reply-To: References: <010f017c514c396f-5ee9dc9f-3704-46cb-88ee-ff97133b55a9-000000@us-east-2.amazonses.com> Message-ID: On Tue, Oct 5, 2021 at 12:39 PM David Feuer wrote: > To be clear, the proposal to allow different constraints was accepted, but > integrating it into the current, incredibly complex, code was well beyond > the limited abilities of the one person who made an attempt. Totally > severing pattern synonyms from constructor synonyms (giving them separate > namespaces) would be a much simpler design. > It might be simpler in some ways, despite needing yet another syntactic marker, etc. but also would make them a lot less useful for a lot of places where they are used today, e.g. to provide backwards compatibility for old constructors as an API changes, and the like. Before I left MIRI, Cale had started work on these for us. Is that the work you are thinking of, or are you thinking of an earlier effort? -Edward > On Tue, Oct 5, 2021, 12:33 PM Richard Eisenberg > wrote: > >> >> >> On Oct 3, 2021, at 5:38 AM, Anthony Clayden >> wrote: >> >> > pattern SmartConstr :: Ord a => () => ... >> >> Seems to mean: >> >> * Required constraint is Ord a -- fine, for building >> >> >> Yes. >> >> * Provided constraint is Ord a -- why? for matching/consuming >> >> >> No. Your signature specified that there are no provided constraints: >> that's your (). >> >> >> 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 believe there is no way to have provided constraints in Haskell98. You >> would need either GADTs or higher-rank types. >> >> >> This feels a lot like one of the things that's wrong with 'stupid theta' >> datatype contexts. >> >> >> You're onto something here. Required constraints are very much like the >> stupid theta datatype contexts. But, unlike the stupid thetas, required >> constraints are sometimes useful: they might be needed in order to, say, >> call a function in a view pattern. >> >> For example: >> >> checkLT5AndReturn :: (Ord a, Num a) => a -> (Bool, a) >> checkLT5AndReturn x = (x < 5, x) >> >> pattern LessThan5 :: (Ord a, Num a) => a -> a >> pattern LessThan5 x <- ( checkLT5AndReturn -> (True, x) ) >> >> >> My view pattern requires (Ord a, Num a), and so I must declare these as >> required constraints in the pattern synonym type. Because vanilla data >> constructors never do computation, any required constraints for data >> constructors are always useless. >> >> >> 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. >> >> >> Does SmartNode need Ord a to match? Or just to produce a node? It seems >> that Ord a is used only for production, not for matching. This suggests >> that you want a separate smartNode function (not a pattern synonym) and to >> have no constraints on the pattern synonym, which can be unidirectional >> (that is, work only as a pattern, not as an expression). >> >> It has been mooted to allow pattern synonyms to have two types: one when >> used as a pattern and a different one when used as an expression. That >> might work for you here: you want SmartNode to have no constraints as a >> pattern, but an Ord a constraint as an expression. At the time, the design >> with two types was considered too complicated and abandoned. >> >> Does this help? >> >> Richard >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> > _______________________________________________ > 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 david.feuer at gmail.com Tue Oct 5 17:14:12 2021 From: david.feuer at gmail.com (David Feuer) Date: Tue, 5 Oct 2021 13:14:12 -0400 Subject: Pattern synonym constraints :: Ord a => () => ... In-Reply-To: References: <010f017c514c396f-5ee9dc9f-3704-46cb-88ee-ff97133b55a9-000000@us-east-2.amazonses.com> Message-ID: I meant my own brief attempt. Severing them absolutely wouldn't make them less useful. pattern Foo :: ... pattern Foo x <- .... constructor Foo :: ... constructor Foo x = ... Separate namespaces, so you can have both, and both can be bundled with a type. On Tue, Oct 5, 2021, 1:11 PM Edward Kmett wrote: > > > On Tue, Oct 5, 2021 at 12:39 PM David Feuer wrote: > >> To be clear, the proposal to allow different constraints was accepted, >> but integrating it into the current, incredibly complex, code was well >> beyond the limited abilities of the one person who made an attempt. Totally >> severing pattern synonyms from constructor synonyms (giving them separate >> namespaces) would be a much simpler design. >> > > It might be simpler in some ways, despite needing yet another syntactic > marker, etc. but also would make them a lot less useful for a lot of places > where they are used today, e.g. to provide backwards compatibility for old > constructors as an API changes, and the like. > > Before I left MIRI, Cale had started work on these for us. Is that the > work you are thinking of, or are you thinking of an earlier effort? > > -Edward > > > > >> On Tue, Oct 5, 2021, 12:33 PM Richard Eisenberg >> wrote: >> >>> >>> >>> On Oct 3, 2021, at 5:38 AM, Anthony Clayden >>> wrote: >>> >>> > pattern SmartConstr :: Ord a => () => ... >>> >>> Seems to mean: >>> >>> * Required constraint is Ord a -- fine, for building >>> >>> >>> Yes. >>> >>> * Provided constraint is Ord a -- why? for matching/consuming >>> >>> >>> No. Your signature specified that there are no provided constraints: >>> that's your (). >>> >>> >>> 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 believe there is no way to have provided constraints in Haskell98. You >>> would need either GADTs or higher-rank types. >>> >>> >>> This feels a lot like one of the things that's wrong with 'stupid theta' >>> datatype contexts. >>> >>> >>> You're onto something here. Required constraints are very much like the >>> stupid theta datatype contexts. But, unlike the stupid thetas, required >>> constraints are sometimes useful: they might be needed in order to, say, >>> call a function in a view pattern. >>> >>> For example: >>> >>> checkLT5AndReturn :: (Ord a, Num a) => a -> (Bool, a) >>> checkLT5AndReturn x = (x < 5, x) >>> >>> pattern LessThan5 :: (Ord a, Num a) => a -> a >>> pattern LessThan5 x <- ( checkLT5AndReturn -> (True, x) ) >>> >>> >>> My view pattern requires (Ord a, Num a), and so I must declare these as >>> required constraints in the pattern synonym type. Because vanilla data >>> constructors never do computation, any required constraints for data >>> constructors are always useless. >>> >>> >>> 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. >>> >>> >>> Does SmartNode need Ord a to match? Or just to produce a node? It seems >>> that Ord a is used only for production, not for matching. This suggests >>> that you want a separate smartNode function (not a pattern synonym) and to >>> have no constraints on the pattern synonym, which can be unidirectional >>> (that is, work only as a pattern, not as an expression). >>> >>> It has been mooted to allow pattern synonyms to have two types: one when >>> used as a pattern and a different one when used as an expression. That >>> might work for you here: you want SmartNode to have no constraints as a >>> pattern, but an Ord a constraint as an expression. At the time, the design >>> with two types was considered too complicated and abandoned. >>> >>> Does this help? >>> >>> Richard >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >>> >> _______________________________________________ >> 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 lists at richarde.dev Tue Oct 5 21:53:35 2021 From: lists at richarde.dev (Richard Eisenberg) Date: Tue, 5 Oct 2021 21:53:35 +0000 Subject: Pattern synonym constraints :: Ord a => () => ... In-Reply-To: References: <010f017c514c396f-5ee9dc9f-3704-46cb-88ee-ff97133b55a9-000000@us-east-2.amazonses.com> Message-ID: <010f017c52729c84-8355d577-4e69-4c1c-9996-571f1760c89c-000000@us-east-2.amazonses.com> You're right -- my apologies. Here is the accepted proposal: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0042-bidir-constr-sigs.rst Richard > On Oct 5, 2021, at 12:38 PM, David Feuer wrote: > > To be clear, the proposal to allow different constraints was accepted, but integrating it into the current, incredibly complex, code was well beyond the limited abilities of the one person who made an attempt. Totally severing pattern synonyms from constructor synonyms (giving them separate namespaces) would be a much simpler design. > > On Tue, Oct 5, 2021, 12:33 PM Richard Eisenberg > wrote: > > >> On Oct 3, 2021, at 5:38 AM, Anthony Clayden > wrote: >> >> > pattern SmartConstr :: Ord a => () => ... >> >> Seems to mean: >> >> * Required constraint is Ord a -- fine, for building > > Yes. > >> * Provided constraint is Ord a -- why? for matching/consuming > > No. Your signature specified that there are no provided constraints: that's your (). > >> >> 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 believe there is no way to have provided constraints in Haskell98. You would need either GADTs or higher-rank types. > >> >> This feels a lot like one of the things that's wrong with 'stupid theta' datatype contexts. > > You're onto something here. Required constraints are very much like the stupid theta datatype contexts. But, unlike the stupid thetas, required constraints are sometimes useful: they might be needed in order to, say, call a function in a view pattern. > > For example: > >> checkLT5AndReturn :: (Ord a, Num a) => a -> (Bool, a) >> checkLT5AndReturn x = (x < 5, x) >> >> pattern LessThan5 :: (Ord a, Num a) => a -> a >> pattern LessThan5 x <- ( checkLT5AndReturn -> (True, x) ) > > My view pattern requires (Ord a, Num a), and so I must declare these as required constraints in the pattern synonym type. Because vanilla data constructors never do computation, any required constraints for data constructors are always useless. > >> >> 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. > > Does SmartNode need Ord a to match? Or just to produce a node? It seems that Ord a is used only for production, not for matching. This suggests that you want a separate smartNode function (not a pattern synonym) and to have no constraints on the pattern synonym, which can be unidirectional (that is, work only as a pattern, not as an expression). > > It has been mooted to allow pattern synonyms to have two types: one when used as a pattern and a different one when used as an expression. That might work for you here: you want SmartNode to have no constraints as a pattern, but an Ord a constraint as an expression. At the time, the design with two types was considered too complicated and abandoned. > > Does this help? > > Richard > _______________________________________________ > 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 anthony.d.clayden at gmail.com Wed Oct 6 00:55:48 2021 From: anthony.d.clayden at gmail.com (Anthony Clayden) Date: Wed, 6 Oct 2021 13:55:48 +1300 Subject: Pattern synonym constraints :: Ord a => () => ... In-Reply-To: <010f017c514c396f-5ee9dc9f-3704-46cb-88ee-ff97133b55a9-000000@us-east-2.amazonses.com> References: <010f017c514c396f-5ee9dc9f-3704-46cb-88ee-ff97133b55a9-000000@us-east-2.amazonses.com> Message-ID: Thank you Richard (and for the reply to a similar topic on the cafe). What I meant by the comparison to 'stupid theta' is that GHC's implementation of datatype contexts used to be mildly useful and moderately sensible. Then it went stupid, following this 'Contexts on datatype declarations' thread: http://web.archive.org/web/20151208175102/http://code.haskell.org/~dons/haskell-1990-2000/threads.html#04062 With the benefit of a great deal of hindsight, and noting that PatternSynonyms makes explicit there's a builder vs a matcher, I'd say SPJ was right and Wadler was wrong. In particular consider trying to implement a Foldable instance (or for any constructor class): the instance head doesn't reveal the 'content type' `a`, so there's no way to provide `Ord a`. _But we don't need_ `Ord a`, because the fold is consuming the content, not building a Foldable structure. As SPJ says: > *pattern-matching* on MkT as *eliminating* a constraint. But since the dictionary isn't stored in the constructor we can't eliminate it. So at first sight, I was hoping that a PatternSyn > pattern SmartConstr :: Ord a => () => blah would give the pre-May 1999 GHC behaviour for matching -- that is, Provide nothing, and therefore ask for nothing if the constructor/PatSyn appears only in a matcher position. I'm afraid that I don't get your answer wrt PatternSyns that wrap H98 datatypes: how do I demonstrate a difference between the above sig vs: > pattern SmartConstr :: Ord a => Ord a => blah It seems to me the shorthand form (with a single `=>`) should be equiv to the latter, allowing the former nothing-Provided `Ord a => () => blah` to mean something different. You say "the design was too complicated". And yet SPJ on that thread says "This is the simpler choice". > you want a separate smartNode function (not a pattern synonym) I might as well have a SmartNode PatSyn and (unidirectional) MatcherOnlyNode PatSyn -- which was my work-round in the O.P. Can't you see that's dysergonomic? AntC On Wed, 6 Oct 2021 at 05:32, Richard Eisenberg wrote: > > > On Oct 3, 2021, at 5:38 AM, Anthony Clayden > wrote: > > > pattern SmartConstr :: Ord a => () => ... > > Seems to mean: > > * Required constraint is Ord a -- fine, for building > > > Yes. > > * Provided constraint is Ord a -- why? for matching/consuming > > > No. Your signature specified that there are no provided constraints: > that's your (). > > > 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 believe there is no way to have provided constraints in Haskell98. You > would need either GADTs or higher-rank types. > > > This feels a lot like one of the things that's wrong with 'stupid theta' > datatype contexts. > > > You're onto something here. Required constraints are very much like the > stupid theta datatype contexts. But, unlike the stupid thetas, required > constraints are sometimes useful: they might be needed in order to, say, > call a function in a view pattern. > > For example: > > checkLT5AndReturn :: (Ord a, Num a) => a -> (Bool, a) > checkLT5AndReturn x = (x < 5, x) > > pattern LessThan5 :: (Ord a, Num a) => a -> a > pattern LessThan5 x <- ( checkLT5AndReturn -> (True, x) ) > > > My view pattern requires (Ord a, Num a), and so I must declare these as > required constraints in the pattern synonym type. Because vanilla data > constructors never do computation, any required constraints for data > constructors are always useless. > > > 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. > > > Does SmartNode need Ord a to match? Or just to produce a node? It seems > that Ord a is used only for production, not for matching. This suggests > that you want a separate smartNode function (not a pattern synonym) and to > have no constraints on the pattern synonym, which can be unidirectional > (that is, work only as a pattern, not as an expression). > > It has been mooted to allow pattern synonyms to have two types: one when > used as a pattern and a different one when used as an expression. That > might work for you here: you want SmartNode to have no constraints as a > pattern, but an Ord a constraint as an expression. At the time, the design > with two types was considered too complicated and abandoned. > > Does this help? > > Richard > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.d.clayden at gmail.com Wed Oct 6 02:07:45 2021 From: anthony.d.clayden at gmail.com (Anthony Clayden) Date: Wed, 6 Oct 2021 15:07:45 +1300 Subject: Pattern synonym constraints :: Ord a => () => ... In-Reply-To: <010f017c52729c84-8355d577-4e69-4c1c-9996-571f1760c89c-000000@us-east-2.amazonses.com> References: <010f017c514c396f-5ee9dc9f-3704-46cb-88ee-ff97133b55a9-000000@us-east-2.amazonses.com> <010f017c52729c84-8355d577-4e69-4c1c-9996-571f1760c89c-000000@us-east-2.amazonses.com> Message-ID: Thank you. Yes that proposal seems in 'the same ball park'. As Richard's already noted, a H98 data constructor can't _Provide_ any constraints, because it has no dictionaries wrapped up inside. But I'm not asking it to! The current PatSyn signatures don't distinguish between Required-for-building vs Required-for-matching (i.e. deconstructing/reformatting to the PatSyn). This seems no better than 'stupid theta': I'm not asking for any reformatting to pattern-match, just give me the darn components, they are what they are where they are. I'm afraid none of this is apparent from the User Guide -- and I even contributed some material to the Guide, without ever understanding that. Before this thread, I took it that 'Required' means for building -- as in for smart constructors. So PatSyns aren't really aimed to be for smart constructors? I should take that material out of the User Guide? AntC On Wed, 6 Oct 2021 at 10:53, Richard Eisenberg wrote: > You're right -- my apologies. Here is the accepted proposal: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0042-bidir-constr-sigs.rst > > Richard > > On Oct 5, 2021, at 12:38 PM, David Feuer wrote: > > To be clear, the proposal to allow different constraints was accepted, but > integrating it into the current, incredibly complex, code was well beyond > the limited abilities of the one person who made an attempt. Totally > severing pattern synonyms from constructor synonyms (giving them separate > namespaces) would be a much simpler design. > > On Tue, Oct 5, 2021, 12:33 PM Richard Eisenberg > wrote: > >> >> >> On Oct 3, 2021, at 5:38 AM, Anthony Clayden >> wrote: >> >> > pattern SmartConstr :: Ord a => () => ... >> >> Seems to mean: >> >> * Required constraint is Ord a -- fine, for building >> >> >> Yes. >> >> * Provided constraint is Ord a -- why? for matching/consuming >> >> >> No. Your signature specified that there are no provided constraints: >> that's your (). >> >> >> 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 believe there is no way to have provided constraints in Haskell98. You >> would need either GADTs or higher-rank types. >> >> >> This feels a lot like one of the things that's wrong with 'stupid theta' >> datatype contexts. >> >> >> You're onto something here. Required constraints are very much like the >> stupid theta datatype contexts. But, unlike the stupid thetas, required >> constraints are sometimes useful: they might be needed in order to, say, >> call a function in a view pattern. >> >> For example: >> >> checkLT5AndReturn :: (Ord a, Num a) => a -> (Bool, a) >> checkLT5AndReturn x = (x < 5, x) >> >> pattern LessThan5 :: (Ord a, Num a) => a -> a >> pattern LessThan5 x <- ( checkLT5AndReturn -> (True, x) ) >> >> >> My view pattern requires (Ord a, Num a), and so I must declare these as >> required constraints in the pattern synonym type. Because vanilla data >> constructors never do computation, any required constraints for data >> constructors are always useless. >> >> >> 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. >> >> >> Does SmartNode need Ord a to match? Or just to produce a node? It seems >> that Ord a is used only for production, not for matching. This suggests >> that you want a separate smartNode function (not a pattern synonym) and to >> have no constraints on the pattern synonym, which can be unidirectional >> (that is, work only as a pattern, not as an expression). >> >> It has been mooted to allow pattern synonyms to have two types: one when >> used as a pattern and a different one when used as an expression. That >> might work for you here: you want SmartNode to have no constraints as a >> pattern, but an Ord a constraint as an expression. At the time, the design >> with two types was considered too complicated and abandoned. >> >> Does this help? >> >> Richard >> _______________________________________________ >> 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 gergo at erdi.hu Wed Oct 6 02:25:46 2021 From: gergo at erdi.hu (=?UTF-8?B?R2VyZ8WRIMOJcmRp?=) Date: Wed, 6 Oct 2021 10:25:46 +0800 Subject: Pattern synonym constraints :: Ord a => () => ... In-Reply-To: References: <010f017c514c396f-5ee9dc9f-3704-46cb-88ee-ff97133b55a9-000000@us-east-2.amazonses.com> <010f017c52729c84-8355d577-4e69-4c1c-9996-571f1760c89c-000000@us-east-2.amazonses.com> Message-ID: If you haven't yet, it is probably a good idea to read section 6 of https://gergo.erdi.hu/papers/patsyns/2016-hs-patsyns-ext.pdf On Wed, Oct 6, 2021 at 10:23 AM Gergő Érdi wrote: > > > I'm afraid none of this is apparent from the User Guide -- and I even contributed some material to the Guide, without ever understanding that. Before this thread, I took it that 'Required' means for building -- as in for smart constructors. > > No, that's not what the required/provided distinction means at all! > > You should think of both Provided and Required in the context of > matching, not in the context of building. To be able to use a pattern > synonym to match on a scrutinee of type T, not only does T have to > match the scrutinee type of the pattern synonym, but you also must > satisfy the constraints of the Required constraints -- they are > "required" to be able to use the pattern synonym. On the flipside, > once you do use the pattern synonym, on the right-hand side of your > matched clause you now get to assume the Provided constraints -- in > other words, those constraints are "provided" to you by the pattern > synonym. > > It is true that the builder could have entirely unrelated constraints > to either (as in the proposal). The current implementation basically > assumes that the Provided constraints can be provided because the > builder put them in. > > Does this make it clearer? > > On Wed, Oct 6, 2021 at 10:13 AM Anthony Clayden > wrote: > > > > > > Thank you. Yes that proposal seems in 'the same ball park'. As Richard's already noted, a H98 data constructor can't _Provide_ any constraints, because it has no dictionaries wrapped up inside. But I'm not asking it to! > > > > The current PatSyn signatures don't distinguish between Required-for-building vs Required-for-matching (i.e. deconstructing/reformatting to the PatSyn). This seems no better than 'stupid theta': I'm not asking for any reformatting to pattern-match, just give me the darn components, they are what they are where they are. > > > > I'm afraid none of this is apparent from the User Guide -- and I even contributed some material to the Guide, without ever understanding that. Before this thread, I took it that 'Required' means for building -- as in for smart constructors. So PatSyns aren't really aimed to be for smart constructors? I should take that material out of the User Guide? > > > > > > AntC > > > > > > On Wed, 6 Oct 2021 at 10:53, Richard Eisenberg wrote: > >> > >> You're right -- my apologies. Here is the accepted proposal: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0042-bidir-constr-sigs.rst > >> > >> Richard > >> > >> On Oct 5, 2021, at 12:38 PM, David Feuer wrote: > >> > >> To be clear, the proposal to allow different constraints was accepted, but integrating it into the current, incredibly complex, code was well beyond the limited abilities of the one person who made an attempt. Totally severing pattern synonyms from constructor synonyms (giving them separate namespaces) would be a much simpler design. > >> > >> On Tue, Oct 5, 2021, 12:33 PM Richard Eisenberg wrote: > >>> > >>> > >>> > >>> On Oct 3, 2021, at 5:38 AM, Anthony Clayden wrote: > >>> > >>> > pattern SmartConstr :: Ord a => () => ... > >>> > >>> Seems to mean: > >>> > >>> * Required constraint is Ord a -- fine, for building > >>> > >>> > >>> Yes. > >>> > >>> * Provided constraint is Ord a -- why? for matching/consuming > >>> > >>> > >>> No. Your signature specified that there are no provided constraints: that's your (). > >>> > >>> > >>> 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 believe there is no way to have provided constraints in Haskell98. You would need either GADTs or higher-rank types. > >>> > >>> > >>> This feels a lot like one of the things that's wrong with 'stupid theta' datatype contexts. > >>> > >>> > >>> You're onto something here. Required constraints are very much like the stupid theta datatype contexts. But, unlike the stupid thetas, required constraints are sometimes useful: they might be needed in order to, say, call a function in a view pattern. > >>> > >>> For example: > >>> > >>> checkLT5AndReturn :: (Ord a, Num a) => a -> (Bool, a) > >>> checkLT5AndReturn x = (x < 5, x) > >>> > >>> pattern LessThan5 :: (Ord a, Num a) => a -> a > >>> pattern LessThan5 x <- ( checkLT5AndReturn -> (True, x) ) > >>> > >>> > >>> My view pattern requires (Ord a, Num a), and so I must declare these as required constraints in the pattern synonym type. Because vanilla data constructors never do computation, any required constraints for data constructors are always useless. > >>> > >>> > >>> 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. > >>> > >>> > >>> Does SmartNode need Ord a to match? Or just to produce a node? It seems that Ord a is used only for production, not for matching. This suggests that you want a separate smartNode function (not a pattern synonym) and to have no constraints on the pattern synonym, which can be unidirectional (that is, work only as a pattern, not as an expression). > >>> > >>> It has been mooted to allow pattern synonyms to have two types: one when used as a pattern and a different one when used as an expression. That might work for you here: you want SmartNode to have no constraints as a pattern, but an Ord a constraint as an expression. At the time, the design with two types was considered too complicated and abandoned. > >>> > >>> Does this help? > >>> > >>> Richard > >>> _______________________________________________ > >>> Glasgow-haskell-users mailing list > >>> Glasgow-haskell-users at haskell.org > >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > >> > >> > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users From gergo at erdi.hu Wed Oct 6 02:23:11 2021 From: gergo at erdi.hu (=?UTF-8?B?R2VyZ8WRIMOJcmRp?=) Date: Wed, 6 Oct 2021 10:23:11 +0800 Subject: Pattern synonym constraints :: Ord a => () => ... In-Reply-To: References: <010f017c514c396f-5ee9dc9f-3704-46cb-88ee-ff97133b55a9-000000@us-east-2.amazonses.com> <010f017c52729c84-8355d577-4e69-4c1c-9996-571f1760c89c-000000@us-east-2.amazonses.com> Message-ID: > I'm afraid none of this is apparent from the User Guide -- and I even contributed some material to the Guide, without ever understanding that. Before this thread, I took it that 'Required' means for building -- as in for smart constructors. No, that's not what the required/provided distinction means at all! You should think of both Provided and Required in the context of matching, not in the context of building. To be able to use a pattern synonym to match on a scrutinee of type T, not only does T have to match the scrutinee type of the pattern synonym, but you also must satisfy the constraints of the Required constraints -- they are "required" to be able to use the pattern synonym. On the flipside, once you do use the pattern synonym, on the right-hand side of your matched clause you now get to assume the Provided constraints -- in other words, those constraints are "provided" to you by the pattern synonym. It is true that the builder could have entirely unrelated constraints to either (as in the proposal). The current implementation basically assumes that the Provided constraints can be provided because the builder put them in. Does this make it clearer? On Wed, Oct 6, 2021 at 10:13 AM Anthony Clayden wrote: > > > Thank you. Yes that proposal seems in 'the same ball park'. As Richard's already noted, a H98 data constructor can't _Provide_ any constraints, because it has no dictionaries wrapped up inside. But I'm not asking it to! > > The current PatSyn signatures don't distinguish between Required-for-building vs Required-for-matching (i.e. deconstructing/reformatting to the PatSyn). This seems no better than 'stupid theta': I'm not asking for any reformatting to pattern-match, just give me the darn components, they are what they are where they are. > > I'm afraid none of this is apparent from the User Guide -- and I even contributed some material to the Guide, without ever understanding that. Before this thread, I took it that 'Required' means for building -- as in for smart constructors. So PatSyns aren't really aimed to be for smart constructors? I should take that material out of the User Guide? > > > AntC > > > On Wed, 6 Oct 2021 at 10:53, Richard Eisenberg wrote: >> >> You're right -- my apologies. Here is the accepted proposal: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0042-bidir-constr-sigs.rst >> >> Richard >> >> On Oct 5, 2021, at 12:38 PM, David Feuer wrote: >> >> To be clear, the proposal to allow different constraints was accepted, but integrating it into the current, incredibly complex, code was well beyond the limited abilities of the one person who made an attempt. Totally severing pattern synonyms from constructor synonyms (giving them separate namespaces) would be a much simpler design. >> >> On Tue, Oct 5, 2021, 12:33 PM Richard Eisenberg wrote: >>> >>> >>> >>> On Oct 3, 2021, at 5:38 AM, Anthony Clayden wrote: >>> >>> > pattern SmartConstr :: Ord a => () => ... >>> >>> Seems to mean: >>> >>> * Required constraint is Ord a -- fine, for building >>> >>> >>> Yes. >>> >>> * Provided constraint is Ord a -- why? for matching/consuming >>> >>> >>> No. Your signature specified that there are no provided constraints: that's your (). >>> >>> >>> 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 believe there is no way to have provided constraints in Haskell98. You would need either GADTs or higher-rank types. >>> >>> >>> This feels a lot like one of the things that's wrong with 'stupid theta' datatype contexts. >>> >>> >>> You're onto something here. Required constraints are very much like the stupid theta datatype contexts. But, unlike the stupid thetas, required constraints are sometimes useful: they might be needed in order to, say, call a function in a view pattern. >>> >>> For example: >>> >>> checkLT5AndReturn :: (Ord a, Num a) => a -> (Bool, a) >>> checkLT5AndReturn x = (x < 5, x) >>> >>> pattern LessThan5 :: (Ord a, Num a) => a -> a >>> pattern LessThan5 x <- ( checkLT5AndReturn -> (True, x) ) >>> >>> >>> My view pattern requires (Ord a, Num a), and so I must declare these as required constraints in the pattern synonym type. Because vanilla data constructors never do computation, any required constraints for data constructors are always useless. >>> >>> >>> 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. >>> >>> >>> Does SmartNode need Ord a to match? Or just to produce a node? It seems that Ord a is used only for production, not for matching. This suggests that you want a separate smartNode function (not a pattern synonym) and to have no constraints on the pattern synonym, which can be unidirectional (that is, work only as a pattern, not as an expression). >>> >>> It has been mooted to allow pattern synonyms to have two types: one when used as a pattern and a different one when used as an expression. That might work for you here: you want SmartNode to have no constraints as a pattern, but an Ord a constraint as an expression. At the time, the design with two types was considered too complicated and abandoned. >>> >>> Does this help? >>> >>> Richard >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> >> > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users From anthony.d.clayden at gmail.com Wed Oct 6 05:25:24 2021 From: anthony.d.clayden at gmail.com (Anthony Clayden) Date: Wed, 6 Oct 2021 18:25:24 +1300 Subject: Pattern synonym constraints :: Ord a => () => ... In-Reply-To: References: <010f017c514c396f-5ee9dc9f-3704-46cb-88ee-ff97133b55a9-000000@us-east-2.amazonses.com> <010f017c52729c84-8355d577-4e69-4c1c-9996-571f1760c89c-000000@us-east-2.amazonses.com> Message-ID: Thanks Gergö, I've read that paper many times (and the User Guide). Nowhere does it make the distinction between required-for-building vs required-for-matching. And since most of the syntax for PatSyns (the `where` equations) is taken up with building, I'd taken it that "required" means required-for-building. There is one paragraph towards the end of section 6 that kinda hints at the issue here. It's so cryptic it's no help. "An alternative would be to carry two types for each pattern synonym: ...". But already PatSyns carry two sets of _constraints_. The matrix type after the constraints is determined by the mapping to/from the data constructor. Why would there be two of those? What this paragraph might mean (?) is 'carry three sets of constraints', but put one set in a completely different signature. As per the proposal. > they [Required constraints] are "required" to be able to use the pattern synonym. Is highly misleading. Only as a result of this thread (not from the User Guide nor from the paper) do I discover "use" means match-on. The paper really does not address typing for "use" for building. I agree with SPJ's comment (quoted in the proposal) "This turns out to be wrong in both directions." I suggest the User Guide needs an example where a constraint needed for matching (presumably via a View pattern) is not amongst the constraints carried inside the data constructor, nor amongst those needed for building. Then the limitations in the current design would be more apparent for users. Perhaps I'm just stupid, and should be disqualified from using such features. (I keep away from GADTs for those reasons.) So I'm not going to volunteer to revise the User Guide further. On Wed, 6 Oct 2021 at 15:26, Gergő Érdi wrote: > If you haven't yet, it is probably a good idea to read section 6 of > https://gergo.erdi.hu/papers/patsyns/2016-hs-patsyns-ext.pdf > > On Wed, Oct 6, 2021 at 10:23 AM Gergő Érdi wrote: > > > > > I'm afraid none of this is apparent from the User Guide -- and I even > contributed some material to the Guide, without ever understanding that. > Before this thread, I took it that 'Required' means for building -- as in > for smart constructors. > > > > No, that's not what the required/provided distinction means at all! > > > > You should think of both Provided and Required in the context of > > matching, not in the context of building. To be able to use a pattern > > synonym to match on a scrutinee of type T, not only does T have to > > match the scrutinee type of the pattern synonym, but you also must > > satisfy the constraints of the Required constraints -- they are > > "required" to be able to use the pattern synonym. On the flipside, > > once you do use the pattern synonym, on the right-hand side of your > > matched clause you now get to assume the Provided constraints -- in > > other words, those constraints are "provided" to you by the pattern > > synonym. > > > > It is true that the builder could have entirely unrelated constraints > > to either (as in the proposal). The current implementation basically > > assumes that the Provided constraints can be provided because the > > builder put them in. > > > > Does this make it clearer? > > > > On Wed, Oct 6, 2021 at 10:13 AM Anthony Clayden > > wrote: > > > > > > > > > Thank you. Yes that proposal seems in 'the same ball park'. As > Richard's already noted, a H98 data constructor can't _Provide_ any > constraints, because it has no dictionaries wrapped up inside. But I'm not > asking it to! > > > > > > The current PatSyn signatures don't distinguish between > Required-for-building vs Required-for-matching (i.e. > deconstructing/reformatting to the PatSyn). This seems no better than > 'stupid theta': I'm not asking for any reformatting to pattern-match, just > give me the darn components, they are what they are where they are. > > > > > > I'm afraid none of this is apparent from the User Guide -- and I even > contributed some material to the Guide, without ever understanding that. > Before this thread, I took it that 'Required' means for building -- as in > for smart constructors. So PatSyns aren't really aimed to be for smart > constructors? I should take that material out of the User Guide? > > > > > > > > > AntC > > > > > > > > > On Wed, 6 Oct 2021 at 10:53, Richard Eisenberg > wrote: > > >> > > >> You're right -- my apologies. Here is the accepted proposal: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0042-bidir-constr-sigs.rst > > >> > > >> Richard > > >> > > >> On Oct 5, 2021, at 12:38 PM, David Feuer > wrote: > > >> > > >> To be clear, the proposal to allow different constraints was > accepted, but integrating it into the current, incredibly complex, code was > well beyond the limited abilities of the one person who made an attempt. > Totally severing pattern synonyms from constructor synonyms (giving them > separate namespaces) would be a much simpler design. > > >> > > >> On Tue, Oct 5, 2021, 12:33 PM Richard Eisenberg > wrote: > > >>> > > >>> > > >>> > > >>> On Oct 3, 2021, at 5:38 AM, Anthony Clayden < > anthony.d.clayden at gmail.com> wrote: > > >>> > > >>> > pattern SmartConstr :: Ord a => () => ... > > >>> > > >>> Seems to mean: > > >>> > > >>> * Required constraint is Ord a -- fine, for building > > >>> > > >>> > > >>> Yes. > > >>> > > >>> * Provided constraint is Ord a -- why? for matching/consuming > > >>> > > >>> > > >>> No. Your signature specified that there are no provided constraints: > that's your (). > > >>> > > >>> > > >>> 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 believe there is no way to have provided constraints in Haskell98. > You would need either GADTs or higher-rank types. > > >>> > > >>> > > >>> This feels a lot like one of the things that's wrong with 'stupid > theta' datatype contexts. > > >>> > > >>> > > >>> You're onto something here. Required constraints are very much like > the stupid theta datatype contexts. But, unlike the stupid thetas, required > constraints are sometimes useful: they might be needed in order to, say, > call a function in a view pattern. > > >>> > > >>> For example: > > >>> > > >>> checkLT5AndReturn :: (Ord a, Num a) => a -> (Bool, a) > > >>> checkLT5AndReturn x = (x < 5, x) > > >>> > > >>> pattern LessThan5 :: (Ord a, Num a) => a -> a > > >>> pattern LessThan5 x <- ( checkLT5AndReturn -> (True, x) ) > > >>> > > >>> > > >>> My view pattern requires (Ord a, Num a), and so I must declare these > as required constraints in the pattern synonym type. Because vanilla data > constructors never do computation, any required constraints for data > constructors are always useless. > > >>> > > >>> > > >>> 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. > > >>> > > >>> > > >>> Does SmartNode need Ord a to match? Or just to produce a node? It > seems that Ord a is used only for production, not for matching. This > suggests that you want a separate smartNode function (not a pattern > synonym) and to have no constraints on the pattern synonym, which can be > unidirectional (that is, work only as a pattern, not as an expression). > > >>> > > >>> It has been mooted to allow pattern synonyms to have two types: one > when used as a pattern and a different one when used as an expression. That > might work for you here: you want SmartNode to have no constraints as a > pattern, but an Ord a constraint as an expression. At the time, the design > with two types was considered too complicated and abandoned. > > >>> > > >>> Does this help? > > >>> > > >>> Richard > > >>> _______________________________________________ > > >>> Glasgow-haskell-users mailing list > > >>> Glasgow-haskell-users at haskell.org > > >>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > >> > > >> > > > _______________________________________________ > > > 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 simonpj at microsoft.com Wed Oct 6 08:24:36 2021 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 6 Oct 2021 08:24:36 +0000 Subject: Pattern synonym constraints :: Ord a => () => ... In-Reply-To: References: <010f017c514c396f-5ee9dc9f-3704-46cb-88ee-ff97133b55a9-000000@us-east-2.amazonses.com> <010f017c52729c84-8355d577-4e69-4c1c-9996-571f1760c89c-000000@us-east-2.amazonses.com> Message-ID: Perhaps I'm just stupid, and should be disqualified from using such features. Only as a result of this thread (not from the User Guide nor from the paper) do I discover "use" means match-on. You are not stupid. And since you misunderstood despite effort, the presentation is - by definition - not as good as it should be. The paper focuses pretty much entirely on matching, and takes building for granted. But I can now see that it is not explicit on this point, and that leaves it open to misinterpretation. I think the paper is reasonably careful to say "match on" rather than "use", but I wouldn't bet on it. I suggest the User Guide needs an example where a constraint needed for matching (presumably via a View pattern) is not amongst the constraints carried inside the data constructor, nor amongst those needed for building. Then the limitations in the current design would be more apparent for users. The user manual does already speak about the type of a builder, here: * For a bidirectional pattern synonym, a use of the pattern synonym as an expression has the type (CReq, CProv) => t1 -> t2 -> ... -> tN -> t So in the previous example, when used in an expression, ExNumPat has type ExNumPat :: (Num a, Eq a, Show b) => b -> T t Notice that this is a tiny bit more restrictive than the expression MkT 42 x which would not require (Eq a). That does seem to directly address the use of a pattern synonym in an expression, and means that both CReq and Cprov are required at use sites in expressions. It even includes an example of the sort you wanted. How could we make that clearer? Thanks Simon PS: I am leaving Microsoft at the end of November 2021, at which point simonpj at microsoft.com will cease to work. Use simon.peytonjones at gmail.com instead. (For now, it just forwards to simonpj at microsoft.com.) From: Glasgow-haskell-users On Behalf Of Anthony Clayden Sent: 06 October 2021 06:25 To: Gergő Érdi Cc: GHC users Subject: Re: Pattern synonym constraints :: Ord a => () => ... Thanks Gergö, I've read that paper many times (and the User Guide). Nowhere does it make the distinction between required-for-building vs required-for-matching. And since most of the syntax for PatSyns (the `where` equations) is taken up with building, I'd taken it that "required" means required-for-building. There is one paragraph towards the end of section 6 that kinda hints at the issue here. It's so cryptic it's no help. "An alternative would be to carry two types for each pattern synonym: ...". But already PatSyns carry two sets of _constraints_. The matrix type after the constraints is determined by the mapping to/from the data constructor. Why would there be two of those? What this paragraph might mean (?) is 'carry three sets of constraints', but put one set in a completely different signature. As per the proposal. > they [Required constraints] are "required" to be able to use the pattern synonym. Is highly misleading. Only as a result of this thread (not from the User Guide nor from the paper) do I discover "use" means match-on. The paper really does not address typing for "use" for building. I agree with SPJ's comment (quoted in the proposal) "This turns out to be wrong in both directions." I suggest the User Guide needs an example where a constraint needed for matching (presumably via a View pattern) is not amongst the constraints carried inside the data constructor, nor amongst those needed for building. Then the limitations in the current design would be more apparent for users. Perhaps I'm just stupid, and should be disqualified from using such features. (I keep away from GADTs for those reasons.) So I'm not going to volunteer to revise the User Guide further. On Wed, 6 Oct 2021 at 15:26, Gergő Érdi > wrote: If you haven't yet, it is probably a good idea to read section 6 of https://gergo.erdi.hu/papers/patsyns/2016-hs-patsyns-ext.pdf On Wed, Oct 6, 2021 at 10:23 AM Gergő Érdi > wrote: > > > I'm afraid none of this is apparent from the User Guide -- and I even contributed some material to the Guide, without ever understanding that. Before this thread, I took it that 'Required' means for building -- as in for smart constructors. > > No, that's not what the required/provided distinction means at all! > > You should think of both Provided and Required in the context of > matching, not in the context of building. To be able to use a pattern > synonym to match on a scrutinee of type T, not only does T have to > match the scrutinee type of the pattern synonym, but you also must > satisfy the constraints of the Required constraints -- they are > "required" to be able to use the pattern synonym. On the flipside, > once you do use the pattern synonym, on the right-hand side of your > matched clause you now get to assume the Provided constraints -- in > other words, those constraints are "provided" to you by the pattern > synonym. > > It is true that the builder could have entirely unrelated constraints > to either (as in the proposal). The current implementation basically > assumes that the Provided constraints can be provided because the > builder put them in. > > Does this make it clearer? > > On Wed, Oct 6, 2021 at 10:13 AM Anthony Clayden > > wrote: > > > > > > Thank you. Yes that proposal seems in 'the same ball park'. As Richard's already noted, a H98 data constructor can't _Provide_ any constraints, because it has no dictionaries wrapped up inside. But I'm not asking it to! > > > > The current PatSyn signatures don't distinguish between Required-for-building vs Required-for-matching (i.e. deconstructing/reformatting to the PatSyn). This seems no better than 'stupid theta': I'm not asking for any reformatting to pattern-match, just give me the darn components, they are what they are where they are. > > > > I'm afraid none of this is apparent from the User Guide -- and I even contributed some material to the Guide, without ever understanding that. Before this thread, I took it that 'Required' means for building -- as in for smart constructors. So PatSyns aren't really aimed to be for smart constructors? I should take that material out of the User Guide? > > > > > > AntC > > > > > > On Wed, 6 Oct 2021 at 10:53, Richard Eisenberg > wrote: > >> > >> You're right -- my apologies. Here is the accepted proposal: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0042-bidir-constr-sigs.rst > >> > >> Richard > >> > >> On Oct 5, 2021, at 12:38 PM, David Feuer > wrote: > >> > >> To be clear, the proposal to allow different constraints was accepted, but integrating it into the current, incredibly complex, code was well beyond the limited abilities of the one person who made an attempt. Totally severing pattern synonyms from constructor synonyms (giving them separate namespaces) would be a much simpler design. > >> > >> On Tue, Oct 5, 2021, 12:33 PM Richard Eisenberg > wrote: > >>> > >>> > >>> > >>> On Oct 3, 2021, at 5:38 AM, Anthony Clayden > wrote: > >>> > >>> > pattern SmartConstr :: Ord a => () => ... > >>> > >>> Seems to mean: > >>> > >>> * Required constraint is Ord a -- fine, for building > >>> > >>> > >>> Yes. > >>> > >>> * Provided constraint is Ord a -- why? for matching/consuming > >>> > >>> > >>> No. Your signature specified that there are no provided constraints: that's your (). > >>> > >>> > >>> 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 believe there is no way to have provided constraints in Haskell98. You would need either GADTs or higher-rank types. > >>> > >>> > >>> This feels a lot like one of the things that's wrong with 'stupid theta' datatype contexts. > >>> > >>> > >>> You're onto something here. Required constraints are very much like the stupid theta datatype contexts. But, unlike the stupid thetas, required constraints are sometimes useful: they might be needed in order to, say, call a function in a view pattern. > >>> > >>> For example: > >>> > >>> checkLT5AndReturn :: (Ord a, Num a) => a -> (Bool, a) > >>> checkLT5AndReturn x = (x < 5, x) > >>> > >>> pattern LessThan5 :: (Ord a, Num a) => a -> a > >>> pattern LessThan5 x <- ( checkLT5AndReturn -> (True, x) ) > >>> > >>> > >>> My view pattern requires (Ord a, Num a), and so I must declare these as required constraints in the pattern synonym type. Because vanilla data constructors never do computation, any required constraints for data constructors are always useless. > >>> > >>> > >>> 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. > >>> > >>> > >>> Does SmartNode need Ord a to match? Or just to produce a node? It seems that Ord a is used only for production, not for matching. This suggests that you want a separate smartNode function (not a pattern synonym) and to have no constraints on the pattern synonym, which can be unidirectional (that is, work only as a pattern, not as an expression). > >>> > >>> It has been mooted to allow pattern synonyms to have two types: one when used as a pattern and a different one when used as an expression. That might work for you here: you want SmartNode to have no constraints as a pattern, but an Ord a constraint as an expression. At the time, the design with two types was considered too complicated and abandoned. > >>> > >>> Does this help? > >>> > >>> Richard > >>> _______________________________________________ > >>> Glasgow-haskell-users mailing list > >>> Glasgow-haskell-users at haskell.org > >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > >> > >> > > _______________________________________________ > > 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 anthony.d.clayden at gmail.com Wed Oct 6 10:41:38 2021 From: anthony.d.clayden at gmail.com (Anthony Clayden) Date: Wed, 6 Oct 2021 23:41:38 +1300 Subject: Pattern synonym constraints :: Ord a => () => ... In-Reply-To: References: <010f017c514c396f-5ee9dc9f-3704-46cb-88ee-ff97133b55a9-000000@us-east-2.amazonses.com> <010f017c52729c84-8355d577-4e69-4c1c-9996-571f1760c89c-000000@us-east-2.amazonses.com> Message-ID: On Wed, 6 Oct 2021 at 21:24, Simon Peyton Jones wrote: > > > I suggest the User Guide needs an example where a constraint needed for > matching (presumably via a View pattern) is not amongst the > constraints carried inside the data constructor, nor amongst those needed > for building. Then the limitations in the current design would be more > apparent for users. > > > > The user manual > > does already speak about the type of a builder, here: > ... How could we make that clearer? This point in that section of the Guide is wrong/misleading: - ⟨CReq⟩ are the constraints *required* to match the pattern. must be the union of the constraints required to match the pattern, _plus_ required to build with the pattern -- if it is bidirectional. Then thank you Simon, but it's the type of the _matcher_ that's problematic. The only mechanism for getting the constraints needed for building is by polluting the constraints needed for matching. Here's a (crude, daft) example, using guards to 'raise' a required-for-failing-to-build that isn't required-for-successful-building nor for-matching > pattern TwoNode :: (Show a, Ord a) => () => a -> a -> Tree a -- GHC insists on both constraints as Req'd > > pattern TwoNode x y <- Node Empty x (Leaf y) where > TwoNode x y | x > y = Node Empty x (Leaf y) > | otherwise = error (show x ++ " not greater " ++ show y) To quote you from May 1999 > But when you take a constructor *apart*, the invariant must hold > by construction: you couldn't have built the thing you are taking > apart unless invariant held. So enforcing the invariant again is > redundant; and in addition it pollutes the type of selectors. `Show a` must have "held by construction" of the `Node`. But the PatSyn's constraints are requiring more than that was true in some distant line of code: it wants *evidence* in the form of a dictionary at the point of deconstructing; since the build was successful, I ipso facto don't want to `show` anything in consuming it. An `instance Foldable Tree` has no mechanism to pass in any such dictionaries (which'll anyway be redundant, as you say). -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Oct 6 11:11:29 2021 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 6 Oct 2021 11:11:29 +0000 Subject: Pattern synonym constraints :: Ord a => () => ... In-Reply-To: References: <010f017c514c396f-5ee9dc9f-3704-46cb-88ee-ff97133b55a9-000000@us-east-2.amazonses.com> <010f017c52729c84-8355d577-4e69-4c1c-9996-571f1760c89c-000000@us-east-2.amazonses.com> Message-ID: must be the union of the constraints required to match the pattern, _plus_ required to build with the pattern -- if it is bidirectional. I think that is confusing too! How about this: * ⟨CReq⟩ are the constraints required to match the pattern, in a pattern match. * ⟨CProv⟩ are the constraints made available (provided) by a successful pattern match. * and are both required when P is used as a constructor in an expression. That makes the constructor form explicit. The only mechanism for getting the constraints needed for building is by polluting the constraints needed for matching. Yes I agree that’s bad. It is acknowledge as such in the paper, and is the subject of accepted proposal #42. Simon PS: I am leaving Microsoft at the end of November 2021, at which point simonpj at microsoft.com will cease to work. Use simon.peytonjones at gmail.com instead. (For now, it just forwards to simonpj at microsoft.com.) From: Anthony Clayden Sent: 06 October 2021 11:42 To: Simon Peyton Jones Cc: Gergő Érdi ; GHC users Subject: Re: Pattern synonym constraints :: Ord a => () => ... On Wed, 6 Oct 2021 at 21:24, Simon Peyton Jones > wrote: I suggest the User Guide needs an example where a constraint needed for matching (presumably via a View pattern) is not amongst the constraints carried inside the data constructor, nor amongst those needed for building. Then the limitations in the current design would be more apparent for users. The user manual does already speak about the type of a builder, here: ... How could we make that clearer? This point in that section of the Guide is wrong/misleading: · ⟨CReq⟩ are the constraints required to match the pattern. must be the union of the constraints required to match the pattern, _plus_ required to build with the pattern -- if it is bidirectional. Then thank you Simon, but it's the type of the _matcher_ that's problematic. The only mechanism for getting the constraints needed for building is by polluting the constraints needed for matching. Here's a (crude, daft) example, using guards to 'raise' a required-for-failing-to-build that isn't required-for-successful-building nor for-matching > pattern TwoNode :: (Show a, Ord a) => () => a -> a -> Tree a -- GHC insists on both constraints as Req'd > > pattern TwoNode x y <- Node Empty x (Leaf y) where > TwoNode x y | x > y = Node Empty x (Leaf y) > | otherwise = error (show x ++ " not greater " ++ show y) To quote you from May 1999 > But when you take a constructor *apart*, the invariant must hold > by construction: you couldn't have built the thing you are taking > apart unless invariant held. So enforcing the invariant again is > redundant; and in addition it pollutes the type of selectors. `Show a` must have "held by construction" of the `Node`. But the PatSyn's constraints are requiring more than that was true in some distant line of code: it wants evidence in the form of a dictionary at the point of deconstructing; since the build was successful, I ipso facto don't want to `show` anything in consuming it. An `instance Foldable Tree` has no mechanism to pass in any such dictionaries (which'll anyway be redundant, as you say). -------------- next part -------------- An HTML attachment was scrubbed... URL: From gergo at erdi.hu Wed Oct 6 11:14:32 2021 From: gergo at erdi.hu (=?ISO-8859-2?Q?=C9RDI_Gerg=F5?=) Date: Wed, 6 Oct 2021 19:14:32 +0800 (+08) Subject: Pattern synonym constraints :: Ord a => () => ... In-Reply-To: References: <010f017c514c396f-5ee9dc9f-3704-46cb-88ee-ff97133b55a9-000000@us-east-2.amazonses.com> Message-ID: On Tue, 5 Oct 2021, David Feuer wrote: > To be clear, the proposal to allow different constraints was accepted, but integrating > it into the current, incredibly complex, code was well beyond the limited abilities of > the one person who made an attempt. Totally severing pattern synonyms from constructor > synonyms (giving them separate namespaces) would be a much simpler design. The backend side of it shouldn't be too difficult -- after all, we are already storing a full `Id` (with type and all) for the builder in `PatSyn`, it might as well have a completely different type from the matcher `Id`. So in GHC/Tc/TyCl/PatSyn.hs, we can just fiddle with `mkPatSynBuilder`. And so we get to the UX side of this, which is the hairy part and the reason I'm not too keen on working on this. As you can see in this very thread, pattern types are already quite complex for users. From duke.j.david at gmail.com Mon Oct 11 09:00:09 2021 From: duke.j.david at gmail.com (David Duke) Date: Mon, 11 Oct 2021 10:00:09 +0100 Subject: osx conundrum Message-ID: 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 at gmail.com W:https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke -------------- next part -------------- An HTML attachment was scrubbed... URL: From karel.gardas at centrum.cz Mon Oct 11 09:05:44 2021 From: karel.gardas at centrum.cz (Karel Gardas) Date: Mon, 11 Oct 2021 11:05:44 +0200 Subject: osx conundrum In-Reply-To: References: Message-ID: <2a8c91fe-452b-6b1b-dc46-20cdb08b7f12@centrum.cz> I'd recommend to search for iconv library in your packaging system. Find that and install that. Probably it looks like dependency on this is missing in provided ghc package(s). Anyway, not osx user here, just general unix user... Good luck! Karel On 10/11/21 11:00 AM, David Duke wrote: > 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 at gmail.com > W:https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > From compl.yue at icloud.com Mon Oct 11 09:12:39 2021 From: compl.yue at icloud.com (YueCompl) Date: Mon, 11 Oct 2021 17:12:39 +0800 Subject: osx conundrum In-Reply-To: References: Message-ID: <8E450DFA-0811-4DF9-BE24-94265B0CB299@icloud.com> Never met this issue myself (with currently osx 10.14.6 Mojave, and a few previous versions), I guess macports/homebrew or some other pieces aren't playing nicely with some others in your machine. Checkout https://newbedev.com/libiconv-or-iconv-undefined-symbol-on-mac-osx maybe helpful. > On 2021-10-11, at 17:00, David Duke wrote: > > 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 at gmail.com > W:https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke _______________________________________________ > 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 duke.j.david at gmail.com Mon Oct 11 10:29:53 2021 From: duke.j.david at gmail.com (David Duke) Date: Mon, 11 Oct 2021 11:29:53 +0100 Subject: osx conundrum In-Reply-To: <8E450DFA-0811-4DF9-BE24-94265B0CB299@icloud.com> References: <8E450DFA-0811-4DF9-BE24-94265B0CB299@icloud.com> Message-ID: Thanks! I've not had the problem with other software. To check I reinstalled iconv with macports brew, and building and installing it direct from GNU sources. however the problem does not seem to be libiconv per se, but libHSbase, and its unclear how to fix that _hs_iconv in libHSbase-4.14.3.0.a(iconv.o) There have been longstanding issues with this library [iconv] int the Haskell ecosystem, cf https://stackoverflow.com/questions/43359289/architecture-x86-64-while-running-haskell-code-haskell-osx-iconv I was hoping there had been progress with binary releases On Mon, Oct 11, 2021 at 10:12 AM YueCompl wrote: > Never met this issue myself (with currently osx 10.14.6 Mojave, and a few > previous versions), I guess macports/homebrew or some other pieces aren't > playing nicely with some others in your machine. > > Checkout > https://newbedev.com/libiconv-or-iconv-undefined-symbol-on-mac-osx maybe > helpful. > > On 2021-10-11, at 17:00, David Duke wrote: > > 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 at gmail.com > W:https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > > -- David Duke Emeritus Professor of Computer Science School of Computing University of Leeds UK E:duke.j.david at gmail.com W:https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominic at steinitz.org Mon Oct 11 12:37:13 2021 From: dominic at steinitz.org (Dominic Steinitz) Date: Mon, 11 Oct 2021 13:37:13 +0100 Subject: Glasgow-haskell-users Digest, Vol 212, Issue 5 In-Reply-To: References: Message-ID: <55420748-7D54-4232-ABB5-2B300DCAA074@steinitz.org> 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 at 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 at gmail.com > W:https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Mon Oct 11 14:50:46 2021 From: george.colpitts at gmail.com (George Colpitts) Date: Mon, 11 Oct 2021 11:50:46 -0300 Subject: Glasgow-haskell-users Digest, Vol 212, Issue 5 In-Reply-To: <55420748-7D54-4232-ABB5-2B300DCAA074@steinitz.org> References: <55420748-7D54-4232-ABB5-2B300DCAA074@steinitz.org> Message-ID: Hi David I've also used ghc for years on Mac OS and have also never seen this problem. I don't use nix. Currently I am on ghc 9.0.1. and Mac OS 11.6. I installed from https://downloads.haskell.org/ghc/9.0.1/ More specifically ghc-9.0.1-x86_64-apple-darwin.tar.xz Are any of the following env variables defined on your system? LD_LIBRARY_PATH, DYLD_LIBRARY_PATH, and DYLD_FALLBACK_LIBRARY_PATH None are defined on my system which I think is normal. When you type iconv --version What output do you get? I get iconv --version iconv (GNU libiconv 1.11) Copyright (C) 2000-2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Bruno Haible. Not sure if my questions will help but I think there is something unusual about your system configuration. Cheers George On Mon, Oct 11, 2021 at 9:38 AM Dominic Steinitz wrote: > 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: > > 1. Add it explicitly on the compile command `-liconv` > 2. 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 at 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 at gmail.com > W:https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke > > > _______________________________________________ > 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 duke.j.david at gmail.com Mon Oct 11 20:12:26 2021 From: duke.j.david at gmail.com (David Duke) Date: Mon, 11 Oct 2021 21:12:26 +0100 Subject: Glasgow-haskell-users Digest, Vol 212, Issue 5 In-Reply-To: References: <55420748-7D54-4232-ABB5-2B300DCAA074@steinitz.org> Message-ID: Thanks Dominic George for that. I had env var set. iconv --version gives GNU libiconv 1.16 I created a clean shell so env vars set other than PATH and installed using the tarball on the link George provided. It appeared to install okay . However trying to compile throws up: cannot satisfy -package-id ghc-9.0.1 compiling with -v: Loaded package environment from /Users/scsdjd/.ghc/x86_64-darwin-9.0.1/environments/default Glasgow Haskell Compiler, Version 9.0.1, stage 2 booted by GHC version 8.8.4 *** initializing unit database: There is no package.cache in /usr/local/lib/ghc-9.0.1/package.conf.d, checking if the database is empty There are no .conf files in /usr/local/lib/ghc-9.0.1/package.conf.d, treating package database as empty Using binary package database: /Users/scsdjd/.cabal/store/ghc-9.0.1/package.db/package.cache package flags [-package-id ghc-9.0.1{unit ghc-9.0.1 True ([])}, regards, David On Mon, Oct 11, 2021 at 3:52 PM George Colpitts wrote: > Hi David > > I've also used ghc for years on Mac OS and have also never seen this > problem. I don't use nix. Currently I am on ghc 9.0.1. and Mac OS 11.6. I > installed from > > https://downloads.haskell.org/ghc/9.0.1/ > > More specifically ghc-9.0.1-x86_64-apple-darwin.tar.xz > > > > Are any of the following env variables defined on your system? > > LD_LIBRARY_PATH, DYLD_LIBRARY_PATH, and DYLD_FALLBACK_LIBRARY_PATH > > None are defined on my system which I think is normal. > > When you type > > iconv --version > > What output do you get? I get > > iconv --version > iconv (GNU libiconv 1.11) > Copyright (C) 2000-2006 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > Written by Bruno Haible. > > > Not sure if my questions will help but I think there is something unusual > about your system configuration. > > Cheers > George > > > > On Mon, Oct 11, 2021 at 9:38 AM Dominic Steinitz > wrote: > >> 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: >> >> 1. Add it explicitly on the compile command `-liconv` >> 2. 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 at 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 at gmail.com >> W:https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -- David Duke Emeritus Professor of Computer Science School of Computing University of Leeds UK E:duke.j.david at gmail.com W:https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve.t.smith at gmail.com Tue Oct 12 01:54:50 2021 From: steve.t.smith at gmail.com (Steven Smith) Date: Mon, 11 Oct 2021 21:54:50 -0400 Subject: osx conundrum In-Reply-To: References: Message-ID: <590168D2-54F7-4B8B-986A-4D60075BC586@gmail.com> I’m a maintainer of the MacPorts ghc port. The MacPorts installations do not have this issue, whether installed from the buildbot binaries or compiled from source, that all work on multiple macOS versions 10.9–11. Here’s the build recipe: https://github.com/macports/macports-ports/blob/master/lang/ghc/Portfile The iconv symbol issue is known, https://gitlab.haskell.org/ghc/ghc/-/issues/18752 , and packages like MacPorts must build around it. This looks like something specific to your configuration. If you believe that there is an issue outside your system, please initiate a trac ticket at https://trac.macports.org . > On Oct 11, 2021, at 5:00 AM, David Duke wrote: > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3898 bytes Desc: not available URL: From george.colpitts at gmail.com Tue Oct 12 12:35:21 2021 From: george.colpitts at gmail.com (George Colpitts) Date: Tue, 12 Oct 2021 09:35:21 -0300 Subject: Glasgow-haskell-users Digest, Vol 212, Issue 5 In-Reply-To: References: <55420748-7D54-4232-ABB5-2B300DCAA074@steinitz.org> Message-ID: Try doing cabal update and then compiling On Mon, Oct 11, 2021 at 5:12 PM David Duke wrote: > Thanks Dominic George for that. I had env var set. iconv --version gives > GNU libiconv 1.16 > I created a clean shell so env vars set other than PATH and installed > using the tarball on the link George provided. > It appeared to install okay . However trying to compile throws up: > > cannot satisfy -package-id ghc-9.0.1 > compiling with -v: > > > Loaded package environment from > /Users/scsdjd/.ghc/x86_64-darwin-9.0.1/environments/default > > Glasgow Haskell Compiler, Version 9.0.1, stage 2 booted by GHC version > 8.8.4 > > *** initializing unit database: > > There is no package.cache in /usr/local/lib/ghc-9.0.1/package.conf.d, > checking if the database is empty > > There are no .conf files in /usr/local/lib/ghc-9.0.1/package.conf.d, > treating package database as empty > > Using binary package database: > /Users/scsdjd/.cabal/store/ghc-9.0.1/package.db/package.cache > > package flags [-package-id ghc-9.0.1{unit ghc-9.0.1 True ([])}, > > regards, > David > > On Mon, Oct 11, 2021 at 3:52 PM George Colpitts > wrote: > >> Hi David >> >> I've also used ghc for years on Mac OS and have also never seen this >> problem. I don't use nix. Currently I am on ghc 9.0.1. and Mac OS 11.6. I >> installed from >> >> https://downloads.haskell.org/ghc/9.0.1/ >> >> More specifically ghc-9.0.1-x86_64-apple-darwin.tar.xz >> >> >> >> Are any of the following env variables defined on your system? >> >> LD_LIBRARY_PATH, DYLD_LIBRARY_PATH, and DYLD_FALLBACK_LIBRARY_PATH >> >> None are defined on my system which I think is normal. >> >> When you type >> >> iconv --version >> >> What output do you get? I get >> >> iconv --version >> iconv (GNU libiconv 1.11) >> Copyright (C) 2000-2006 Free Software Foundation, Inc. >> This is free software; see the source for copying conditions. There is NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >> PURPOSE. >> Written by Bruno Haible. >> >> >> Not sure if my questions will help but I think there is something unusual >> about your system configuration. >> >> Cheers >> George >> >> >> >> On Mon, Oct 11, 2021 at 9:38 AM Dominic Steinitz >> wrote: >> >>> 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: >>> >>> 1. Add it explicitly on the compile command `-liconv` >>> 2. 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 at 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 at gmail.com >>> W:https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke >>> >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >>> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> > > > -- > David Duke > Emeritus Professor of Computer Science > School of Computing University of Leeds UK > E:duke.j.david at gmail.com > W:https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Oct 12 19:30:15 2021 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 12 Oct 2021 15:30:15 -0400 Subject: osx conundrum In-Reply-To: <590168D2-54F7-4B8B-986A-4D60075BC586@gmail.com> References: <590168D2-54F7-4B8B-986A-4D60075BC586@gmail.com> Message-ID: i would make sure you're using the ghc version you *think* you're using i've never had that problem with a self managed style install (which should be equiv to using ghcup's setup). i'm at 8.10.7 at the moment. whats the output of `which -a ghc` and `which ghc`? mixing several ghc installs of the same version can be a problem. ghcup should just match the official builds generally On Mon, Oct 11, 2021 at 9:55 PM Steven Smith wrote: > I’m a maintainer of the MacPorts ghc port. The MacPorts installations do > not have this issue, whether installed from the buildbot binaries or > compiled from source, that all work on multiple macOS versions 10.9–11. > Here’s the build recipe: > https://github.com/macports/macports-ports/blob/master/lang/ghc/Portfile > > The iconv symbol issue is known, > https://gitlab.haskell.org/ghc/ghc/-/issues/18752, and packages like > MacPorts must build around it. > > This looks like something specific to your configuration. > > If you believe that there is an issue outside your system, please initiate > a trac ticket at https://trac.macports.org. > > > On Oct 11, 2021, at 5:00 AM, David Duke wrote: > > 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 > > > _______________________________________________ > 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 duke.j.david at gmail.com Wed Oct 13 11:56:57 2021 From: duke.j.david at gmail.com (David Duke) Date: Wed, 13 Oct 2021 12:56:57 +0100 Subject: osx conundrum In-Reply-To: <590168D2-54F7-4B8B-986A-4D60075BC586@gmail.com> References: <590168D2-54F7-4B8B-986A-4D60075BC586@gmail.com> Message-ID: Thanks Steven. Looks like it might be something with my system. I reinstalled from macports 8.10.7 @ Carter yes I've been carefully check the compiler version on each trial. However trying to compile a Haskell source gives the same libHSbase error ndefined symbols for architecture x86_64: "_iconv", referenced from: _hs_iconv in libHSbase-4.14.3.0.a(iconv.o On Tue, Oct 12, 2021 at 2:54 AM Steven Smith wrote: > I’m a maintainer of the MacPorts ghc port. The MacPorts installations do > not have this issue, whether installed from the buildbot binaries or > compiled from source, that all work on multiple macOS versions 10.9–11. > Here’s the build recipe: > https://github.com/macports/macports-ports/blob/master/lang/ghc/Portfile > > The iconv symbol issue is known, > https://gitlab.haskell.org/ghc/ghc/-/issues/18752, and packages like > MacPorts must build around it. > > This looks like something specific to your configuration. > > If you believe that there is an issue outside your system, please initiate > a trac ticket at https://trac.macports.org. > > > On Oct 11, 2021, at 5:00 AM, David Duke wrote: > > 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 > > > -- David Duke Emeritus Professor of Computer Science School of Computing University of Leeds UK E:duke.j.david at gmail.com W:https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke -------------- next part -------------- An HTML attachment was scrubbed... URL: From compl.yue at icloud.com Wed Oct 13 12:13:52 2021 From: compl.yue at icloud.com (YueCompl) Date: Wed, 13 Oct 2021 20:13:52 +0800 Subject: osx conundrum In-Reply-To: References: <590168D2-54F7-4B8B-986A-4D60075BC586@gmail.com> Message-ID: <65E4AAEB-4E07-4102-91B5-C288BF3F584C@icloud.com> Maybe you'd like to install a virtual instance of OSX and test things from clean scratch, I'd expect any routine installation of GHC should work, then add macports/homebrew etc. to bisect the culprit. Free VirtualBox should do, VMWare Fusion or Parallel Desktop can offer even smoother experience at some fees/cost. > On 2021-10-13, at 19:56, David Duke wrote: > > Thanks Steven. Looks like it might be something with my system. > I reinstalled from macports 8.10.7 > @ Carter yes I've been carefully check the compiler version on each trial. > However trying to compile a Haskell source gives the same libHSbase error > > > > ndefined symbols for architecture x86_64: > "_iconv", referenced from: > _hs_iconv in libHSbase-4.14.3.0.a(iconv.o > > > > > On Tue, Oct 12, 2021 at 2:54 AM Steven Smith > wrote: > I’m a maintainer of the MacPorts ghc port. The MacPorts installations do not have this issue, whether installed from the buildbot binaries or compiled from source, that all work on multiple macOS versions 10.9–11. Here’s the build recipe: https://github.com/macports/macports-ports/blob/master/lang/ghc/Portfile > > The iconv symbol issue is known, https://gitlab.haskell.org/ghc/ghc/-/issues/18752 , and packages like MacPorts must build around it. > > This looks like something specific to your configuration. > > If you believe that there is an issue outside your system, please initiate a trac ticket at https://trac.macports.org . > > >> On Oct 11, 2021, at 5:00 AM, David Duke > wrote: >> >> 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 > > > -- > David Duke > Emeritus Professor of Computer Science > School of Computing University of Leeds UK > E:duke.j.david at gmail.com > W:https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke _______________________________________________ > 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 steve.t.smith at gmail.com Wed Oct 13 15:40:57 2021 From: steve.t.smith at gmail.com (Steven Smith) Date: Wed, 13 Oct 2021 11:40:57 -0400 Subject: osx conundrum In-Reply-To: References: Message-ID: <1D15B76C-7FEE-4620-BC4E-74A68490BDAB@gmail.com> FWIW, MacPorts does compile from source. If you want, just do sudo port -s install ghc and watch a multistage compiler build. That’s where the MacPorts binary installs come from, so it’s just easier to use those. > On Oct 13, 2021, at 07:57, David Duke wrote: > >  > Thanks Steven. Looks like it might be something with my system. > I reinstalled from macports 8.10.7 > @ Carter yes I've been carefully check the compiler version on each trial. > However trying to compile a Haskell source gives the same libHSbase error > > > > ndefined symbols for architecture x86_64: > "_iconv", referenced from: > _hs_iconv in libHSbase-4.14.3.0.a(iconv.o > > > > >> On Tue, Oct 12, 2021 at 2:54 AM Steven Smith wrote: >> I’m a maintainer of the MacPorts ghc port. The MacPorts installations do not have this issue, whether installed from the buildbot binaries or compiled from source, that all work on multiple macOS versions 10.9–11. Here’s the build recipe: https://github.com/macports/macports-ports/blob/master/lang/ghc/Portfile >> >> The iconv symbol issue is known, https://gitlab.haskell.org/ghc/ghc/-/issues/18752, and packages like MacPorts must build around it. >> >> This looks like something specific to your configuration. >> >> If you believe that there is an issue outside your system, please initiate a trac ticket at https://trac.macports.org. >> >> >>> On Oct 11, 2021, at 5:00 AM, David Duke wrote: >>> >>> 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 >> > > > -- > David Duke > Emeritus Professor of Computer Science > School of Computing University of Leeds UK > E:duke.j.david at gmail.com > W:https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Oct 14 01:49:17 2021 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 13 Oct 2021 21:49:17 -0400 Subject: osx conundrum In-Reply-To: References: <590168D2-54F7-4B8B-986A-4D60075BC586@gmail.com> Message-ID: The issue would be macports. It uses its own version of the iconv lib and that always gets headaches if the ghc touches anything else. if you’re using macports you have to make sure everything is Mac ports only for ghc linking. Else you have to make sure you don’t touch any macports c Libs via ghc. On Wed, Oct 13, 2021 at 7:57 AM David Duke wrote: > Thanks Steven. Looks like it might be something with my system. > I reinstalled from macports 8.10.7 > @ Carter yes I've been carefully check the compiler version on each > trial. > However trying to compile a Haskell source gives the same libHSbase error > > > > ndefined symbols for architecture x86_64: > > "_iconv", referenced from: > > _hs_iconv in libHSbase-4.14.3.0.a(iconv.o > > > > > > On Tue, Oct 12, 2021 at 2:54 AM Steven Smith > wrote: > >> I’m a maintainer of the MacPorts ghc port. The MacPorts installations do >> not have this issue, whether installed from the buildbot binaries or >> compiled from source, that all work on multiple macOS versions 10.9–11. >> Here’s the build recipe: >> https://github.com/macports/macports-ports/blob/master/lang/ghc/Portfile >> >> The iconv symbol issue is known, >> https://gitlab.haskell.org/ghc/ghc/-/issues/18752, and packages like >> MacPorts must build around it. >> >> This looks like something specific to your configuration. >> >> If you believe that there is an issue outside your system, please >> initiate a trac ticket at https://trac.macports.org. >> >> >> On Oct 11, 2021, at 5:00 AM, David Duke wrote: >> >> 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 >> >> >> > > -- > David Duke > Emeritus Professor of Computer Science > School of Computing University of Leeds UK > E:duke.j.david at gmail.com > W:https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke > _______________________________________________ > 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 steve.t.smith at gmail.com Fri Oct 15 00:50:58 2021 From: steve.t.smith at gmail.com (Steven Smith) Date: Thu, 14 Oct 2021 20:50:58 -0400 Subject: osx conundrum In-Reply-To: References: <590168D2-54F7-4B8B-986A-4D60075BC586@gmail.com> Message-ID: <43A88C5A-4E51-4DED-A664-D0F3C3582C28@gmail.com> > The issue would be macports. It uses its own version of the iconv lib and that always gets headaches if the ghc touches anything else. No, Macports ghc links against the symbol iconv from /usr/lib/libSystem. See: https://github.com/macports/macports-ports/blob/c7c7f3f90e1140a0d4826bb94502fd7a4ae40459/lang/ghc/Portfile#L213-L218 https://gitlab.haskell.org/ghc/ghc/-/issues/18752 https://trac.macports.org/ticket/57821 The MacPorts ghc binary is rock solid to the best of my knowledge. If you want to compile ghc against libiconv (not libSystem), then must contend with the name mangling issue inherent in the libiconv library, discussed in the last link above. Recommendation on macOS: just install the MacPorts binaries. They work, they’re compiled from source, and they’re managed. > On Oct 13, 2021, at 9:49 PM, Carter Schonwald wrote: > > The issue would be macports. It uses its own version of the iconv lib and that always gets headaches if the ghc touches anything else. > > if you’re using macports you have to make sure everything is Mac ports only for ghc linking. > > Else you have to make sure you don’t touch any macports c Libs via ghc. > > On Wed, Oct 13, 2021 at 7:57 AM David Duke > wrote: > Thanks Steven. Looks like it might be something with my system. > I reinstalled from macports 8.10.7 > @ Carter yes I've been carefully check the compiler version on each trial. > However trying to compile a Haskell source gives the same libHSbase error > > > > ndefined symbols for architecture x86_64: > "_iconv", referenced from: > _hs_iconv in libHSbase-4.14.3.0.a(iconv.o > > > > > On Tue, Oct 12, 2021 at 2:54 AM Steven Smith > wrote: > I’m a maintainer of the MacPorts ghc port. The MacPorts installations do not have this issue, whether installed from the buildbot binaries or compiled from source, that all work on multiple macOS versions 10.9–11. Here’s the build recipe: https://github.com/macports/macports-ports/blob/master/lang/ghc/Portfile > > The iconv symbol issue is known, https://gitlab.haskell.org/ghc/ghc/-/issues/18752 , and packages like MacPorts must build around it. > > This looks like something specific to your configuration. > > If you believe that there is an issue outside your system, please initiate a trac ticket at https://trac.macports.org . > > >> On Oct 11, 2021, at 5:00 AM, David Duke > wrote: >> >> 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 > > > -- > David Duke > Emeritus Professor of Computer Science > School of Computing University of Leeds UK > E:duke.j.david at gmail.com > W:https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke _______________________________________________ > 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: smime.p7s Type: application/pkcs7-signature Size: 3898 bytes Desc: not available URL: From ben at well-typed.com Fri Oct 29 15:44:42 2021 From: ben at well-typed.com (Ben Gamari) Date: Fri, 29 Oct 2021 11:44:42 -0400 Subject: [ANNOUNCE] GHC 9.2.1 now available Message-ID: <87lf2bu98a.fsf@smart-cactus.org> 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-unlifted-datatypes.rst [-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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 905 bytes Desc: not available URL: From george.colpitts at gmail.com Fri Oct 29 17:33:33 2021 From: george.colpitts at gmail.com (George Colpitts) Date: Fri, 29 Oct 2021 14:33:33 -0300 Subject: [ANNOUNCE] GHC 9.2.1 now available In-Reply-To: <87lf2bu98a.fsf@smart-cactus.org> References: <87lf2bu98a.fsf@smart-cactus.org> Message-ID: Great news! Install works on mac os if you do xattr -rc . before doing make install The mail didn't mention that nor is it mentioned in the INSTALL file. I thought this had been fixed. I guess I'm mistaken or this is only an issue for me. Thanks again for getting this out! There's a lot of great stuff in the release. Cheers George On Fri, Oct 29, 2021 at 12:54 PM Ben Gamari wrote: > 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-unlifted-datatypes.rst > [-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 > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Sat Oct 30 15:38:54 2021 From: george.colpitts at gmail.com (George Colpitts) Date: Sat, 30 Oct 2021 12:38:54 -0300 Subject: regression in ghc / cabal integration in 9.2.1 In-Reply-To: <87lf2bu98a.fsf@smart-cactus.org> References: <87lf2bu98a.fsf@smart-cactus.org> Message-ID: Thanks Ben! There seems to be a regression in ghc / cabal integration in 9.2.1. In 9.2.1 if I do cabal install vector Compilation of a file containing import Data.Vector main = undefined fails with Could not find module ‘Data.Vector’ Perhaps you meant Data.Functor (from base-4.16.0.0) Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 2 | import Data.Vector | ^^^^^^^^^^^^^^^^^^ The preceding works on ghc 9.0.1 Should I file a bug against Cabal? Thanks George On Fri, Oct 29, 2021 at 12:54 PM Ben Gamari wrote: > 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-unlifted-datatypes.rst > [-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 > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikolaj at well-typed.com Sat Oct 30 18:38:02 2021 From: mikolaj at well-typed.com (Mikolaj Konarski) Date: Sat, 30 Oct 2021 20:38:02 +0200 Subject: regression in ghc / cabal integration in 9.2.1 In-Reply-To: References: <87lf2bu98a.fsf@smart-cactus.org> Message-ID: Hi George, Since many versions of cabal, `install` only installs executables, not libraries, so if that worked for you, you must have had an old version of cabal. Please see https://github.com/haskell/cabal/issues/6481 for some context and to help you find a new workflow that works for you (ideally, a standard one). Kind regards, Mikolaj On Sat, Oct 30, 2021 at 5:40 PM George Colpitts wrote: > > Thanks Ben! > > There seems to be a regression in ghc / cabal integration in 9.2.1. > > In 9.2.1 if I do > > cabal install vector > > Compilation of a file containing > > > import Data.Vector > > > main = undefined > > > fails with > > Could not find module ‘Data.Vector’ > Perhaps you meant Data.Functor (from base-4.16.0.0) > Use -v (or `:set -v` in ghci) to see a list of the files searched for. > | > 2 | import Data.Vector > | ^^^^^^^^^^^^^^^^^^ > > The preceding works on ghc 9.0.1 > > Should I file a bug against Cabal? > > Thanks > George > > On Fri, Oct 29, 2021 at 12:54 PM Ben Gamari wrote: >> >> 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-unlifted-datatypes.rst >> [-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 >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From george.colpitts at gmail.com Sat Oct 30 19:23:26 2021 From: george.colpitts at gmail.com (George Colpitts) Date: Sat, 30 Oct 2021 16:23:26 -0300 Subject: regression in ghc / cabal integration in 9.2.1 In-Reply-To: References: <87lf2bu98a.fsf@smart-cactus.org> Message-ID: Thanks for the quick response Mikolaj. Sorry for the confusion, with cabal install I did use --lib but accidentally omitted that in my original email. In 9.0.1 this results in a successful compilation but in 9.2.1 it does not thus I believe this is a regression. Here's the output I got in 9.2.1: bash-3.2$ cabal install vector --lib Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.4.0.0 supports 'ghc' version < 9.1): /usr/local/bin/ghc is version 9.2.1 Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.4.0.0 supports 'ghc' version < 9.1): /usr/local/bin/ghc is version 9.2.1 Resolving dependencies... Up to date bash-3.2$ ghc buggc.hs [1 of 1] Compiling Main ( buggc.hs, buggc.o ) buggc.hs:2:1: error: Could not find module ‘Data.Vector’ Perhaps you meant Data.Functor (from base-4.16.0.0) Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 2 | import Data.Vector However I did figure out a workaround: cabal v1-install. As far as I can tell cabal (v2-) install breaks ghc-pkg and compilation. With cabal (v2-) install the workaround for ghc-pkg is to add the option "-f $HOME/.cabal/store/ghc-9.2.1/package.db" to the end of the command "ghc-pkg list". For compilation the workaround is to add "-package-db $HOME/.cabal/store/ghc-9.2.1/package.db" to the ghc-pkg. I don't understand why it was necessary for cabal v2-install to be incompatible with cabal v1-install. Is there a link to any documentation and justification for these incompatible changes? Thanks again, George On Sat, Oct 30, 2021 at 3:38 PM Mikolaj Konarski wrote: > Hi George, > > Since many versions of cabal, `install` only installs executables, not > libraries, so if that worked for you, you must have had an old version > of cabal. > > Please see https://github.com/haskell/cabal/issues/6481 for some > context and to help you find a new workflow that works for you > (ideally, a standard one). > > Kind regards, > Mikolaj > > On Sat, Oct 30, 2021 at 5:40 PM George Colpitts > wrote: > > > > Thanks Ben! > > > > There seems to be a regression in ghc / cabal integration in 9.2.1. > > > > In 9.2.1 if I do > > > > cabal install vector > > > > Compilation of a file containing > > > > > > import Data.Vector > > > > > > main = undefined > > > > > > fails with > > > > Could not find module ‘Data.Vector’ > > Perhaps you meant Data.Functor (from base-4.16.0.0) > > Use -v (or `:set -v` in ghci) to see a list of the files searched > for. > > | > > 2 | import Data.Vector > > | ^^^^^^^^^^^^^^^^^^ > > > > The preceding works on ghc 9.0.1 > > > > Should I file a bug against Cabal? > > > > Thanks > > George > > > > On Fri, Oct 29, 2021 at 12:54 PM Ben Gamari wrote: > >> > >> 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-unlifted-datatypes.rst > >> [-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 > >> _______________________________________________ > >> ghc-devs mailing list > >> ghc-devs at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sat Oct 30 19:43:45 2021 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 30 Oct 2021 15:43:45 -0400 Subject: regression in ghc / cabal integration in 9.2.1 In-Reply-To: References: <87lf2bu98a.fsf@smart-cactus.org> Message-ID: Wasn't there specifically a new cabal version released to deal with 9.2.1? 3.4.1.0 / 3.6.2.0? On Sat, Oct 30, 2021 at 3:24 PM George Colpitts wrote: > > Thanks for the quick response Mikolaj. Sorry for the confusion, with cabal install I did use --lib but accidentally omitted that in my original email. In 9.0.1 this results in a successful compilation but in 9.2.1 it does not thus I believe this is a regression. > > Here's the output I got in 9.2.1: > > bash-3.2$ cabal install vector --lib > Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.4.0.0 supports > 'ghc' version < 9.1): /usr/local/bin/ghc is version 9.2.1 > Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.4.0.0 supports > 'ghc' version < 9.1): /usr/local/bin/ghc is version 9.2.1 > Resolving dependencies... > Up to date > bash-3.2$ ghc buggc.hs > [1 of 1] Compiling Main ( buggc.hs, buggc.o ) > > > buggc.hs:2:1: error: > Could not find module ‘Data.Vector’ > Perhaps you meant Data.Functor (from base-4.16.0.0) > Use -v (or `:set -v` in ghci) to see a list of the files searched for. > | > 2 | import Data.Vector > > > However I did figure out a workaround: cabal v1-install. > > As far as I can tell cabal (v2-) install breaks ghc-pkg and compilation. With cabal (v2-) install the workaround for ghc-pkg is to add the option "-f $HOME/.cabal/store/ghc-9.2.1/package.db" to the end of the command "ghc-pkg list". For compilation the workaround is to add "-package-db $HOME/.cabal/store/ghc-9.2.1/package.db" to the ghc-pkg. I don't understand why it was necessary for cabal v2-install to be incompatible with cabal v1-install. Is there a link to any documentation and justification for these incompatible changes? > > Thanks again, > George > > > > On Sat, Oct 30, 2021 at 3:38 PM Mikolaj Konarski wrote: >> >> Hi George, >> >> Since many versions of cabal, `install` only installs executables, not >> libraries, so if that worked for you, you must have had an old version >> of cabal. >> >> Please see https://github.com/haskell/cabal/issues/6481 for some >> context and to help you find a new workflow that works for you >> (ideally, a standard one). >> >> Kind regards, >> Mikolaj >> >> On Sat, Oct 30, 2021 at 5:40 PM George Colpitts >> wrote: >> > >> > Thanks Ben! >> > >> > There seems to be a regression in ghc / cabal integration in 9.2.1. >> > >> > In 9.2.1 if I do >> > >> > cabal install vector >> > >> > Compilation of a file containing >> > >> > >> > import Data.Vector >> > >> > >> > main = undefined >> > >> > >> > fails with >> > >> > Could not find module ‘Data.Vector’ >> > Perhaps you meant Data.Functor (from base-4.16.0.0) >> > Use -v (or `:set -v` in ghci) to see a list of the files searched for. >> > | >> > 2 | import Data.Vector >> > | ^^^^^^^^^^^^^^^^^^ >> > >> > The preceding works on ghc 9.0.1 >> > >> > Should I file a bug against Cabal? >> > >> > Thanks >> > George >> > >> > On Fri, Oct 29, 2021 at 12:54 PM Ben Gamari wrote: >> >> >> >> 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-unlifted-datatypes.rst >> >> [-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 >> >> _______________________________________________ >> >> ghc-devs mailing list >> >> ghc-devs at haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- brandon s allbery kf8nh allbery.b at gmail.com From mikolaj at well-typed.com Sat Oct 30 19:48:11 2021 From: mikolaj at well-typed.com (Mikolaj Konarski) Date: Sat, 30 Oct 2021 21:48:11 +0200 Subject: regression in ghc / cabal integration in 9.2.1 In-Reply-To: References: <87lf2bu98a.fsf@smart-cactus.org> Message-ID: Hi George, Have you looked at the ticket I gave you? Here's one linked from it mentioning the topic of ghc-pkg compatibility with v2-install: https://github.com/haskell/cabal/issues/6508 I'm afraid we don't have any systematic exposition of cabal history with rationale for its major changes, but there's a changelog and the commit log. If you'd like to contribute something better, please do. Why the difference between GHC versions, I don't know, or whether upgrading your cabal would help (I doubt it). Regarding your workflow, perhaps ask around or look up in cabal tickets how other people do this now? I never run ghc directly, so I don't know. Best, Mikolaj On Sat, Oct 30, 2021 at 9:44 PM Brandon Allbery wrote: > > Wasn't there specifically a new cabal version released to deal with > 9.2.1? 3.4.1.0 / 3.6.2.0? > > On Sat, Oct 30, 2021 at 3:24 PM George Colpitts > wrote: > > > > Thanks for the quick response Mikolaj. Sorry for the confusion, with cabal install I did use --lib but accidentally omitted that in my original email. In 9.0.1 this results in a successful compilation but in 9.2.1 it does not thus I believe this is a regression. > > > > Here's the output I got in 9.2.1: > > > > bash-3.2$ cabal install vector --lib > > Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.4.0.0 supports > > 'ghc' version < 9.1): /usr/local/bin/ghc is version 9.2.1 > > Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.4.0.0 supports > > 'ghc' version < 9.1): /usr/local/bin/ghc is version 9.2.1 > > Resolving dependencies... > > Up to date > > bash-3.2$ ghc buggc.hs > > [1 of 1] Compiling Main ( buggc.hs, buggc.o ) > > > > > > buggc.hs:2:1: error: > > Could not find module ‘Data.Vector’ > > Perhaps you meant Data.Functor (from base-4.16.0.0) > > Use -v (or `:set -v` in ghci) to see a list of the files searched for. > > | > > 2 | import Data.Vector > > > > > > However I did figure out a workaround: cabal v1-install. > > > > As far as I can tell cabal (v2-) install breaks ghc-pkg and compilation. With cabal (v2-) install the workaround for ghc-pkg is to add the option "-f $HOME/.cabal/store/ghc-9.2.1/package.db" to the end of the command "ghc-pkg list". For compilation the workaround is to add "-package-db $HOME/.cabal/store/ghc-9.2.1/package.db" to the ghc-pkg. I don't understand why it was necessary for cabal v2-install to be incompatible with cabal v1-install. Is there a link to any documentation and justification for these incompatible changes? > > > > Thanks again, > > George > > > > > > > > On Sat, Oct 30, 2021 at 3:38 PM Mikolaj Konarski wrote: > >> > >> Hi George, > >> > >> Since many versions of cabal, `install` only installs executables, not > >> libraries, so if that worked for you, you must have had an old version > >> of cabal. > >> > >> Please see https://github.com/haskell/cabal/issues/6481 for some > >> context and to help you find a new workflow that works for you > >> (ideally, a standard one). > >> > >> Kind regards, > >> Mikolaj > >> > >> On Sat, Oct 30, 2021 at 5:40 PM George Colpitts > >> wrote: > >> > > >> > Thanks Ben! > >> > > >> > There seems to be a regression in ghc / cabal integration in 9.2.1. > >> > > >> > In 9.2.1 if I do > >> > > >> > cabal install vector > >> > > >> > Compilation of a file containing > >> > > >> > > >> > import Data.Vector > >> > > >> > > >> > main = undefined > >> > > >> > > >> > fails with > >> > > >> > Could not find module ‘Data.Vector’ > >> > Perhaps you meant Data.Functor (from base-4.16.0.0) > >> > Use -v (or `:set -v` in ghci) to see a list of the files searched for. > >> > | > >> > 2 | import Data.Vector > >> > | ^^^^^^^^^^^^^^^^^^ > >> > > >> > The preceding works on ghc 9.0.1 > >> > > >> > Should I file a bug against Cabal? > >> > > >> > Thanks > >> > George > >> > > >> > On Fri, Oct 29, 2021 at 12:54 PM Ben Gamari wrote: > >> >> > >> >> 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-unlifted-datatypes.rst > >> >> [-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 > >> >> _______________________________________________ > >> >> ghc-devs mailing list > >> >> ghc-devs at haskell.org > >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >> > > >> > _______________________________________________ > >> > ghc-devs mailing list > >> > ghc-devs at haskell.org > >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > -- > brandon s allbery kf8nh > allbery.b at gmail.com From trebla at vex.net Sat Oct 30 20:08:01 2021 From: trebla at vex.net (Albert Y. C. Lai) Date: Sat, 30 Oct 2021 16:08:01 -0400 Subject: regression in ghc / cabal integration in 9.2.1 In-Reply-To: References: <87lf2bu98a.fsf@smart-cactus.org> Message-ID: <53bbd50b-eaa9-2541-4a06-ce48cf709658@vex.net> On 2021-10-30 3:43 p.m., Brandon Allbery wrote: > Wasn't there specifically a new cabal version released to deal with > 9.2.1? 3.4.1.0 / 3.6.2.0? There is a double fault here. Firstly yes, one should use a newer version of cabal-install that is known to support GHC 9.2. So, 3.6.2.0 it is! But GHC 9.2.1 will also play a role... $ cabal --version cabal-install version 3.6.2.0 compiled using version 3.6.2.0 of the Cabal library $ ghc --version The Glorious Glasgow Haskell Compilation System, version 9.2.1 $ cabal install --lib vector Resolving dependencies... Build profile: -w ghc-9.2.1 -O1 In order, the following will be built (use -v for more details): - primitive-0.7.3.0 (lib) (requires download & build) - vector-0.12.3.1 (lib) (requires download & build) [... success ...] $ cat .ghc/x86_64-linux-9.2.1/environments/default clear-package-db global-package-db package-db /home/trebla/.cabal/store/ghc-9.2.1/package.db package-id ghc-9.2.1 package-id bytestring-0.11.1.0 package-id unix-2.7.2.2 package-id base-4.16.0.0 package-id time-1.11.1.1 package-id hpc-0.6.1.0 package-id filepath-1.4.2.1 package-id process-1.6.13.2 package-id array-0.5.4.0 package-id integer-gmp-1.1 package-id containers-0.6.5.1 package-id ghc-boot-9.2.1 package-id binary-0.8.9.0 package-id ghc-prim-0.8.0 package-id ghci-9.2.1 package-id rts package-id terminfo-0.4.1.5 package-id transformers-0.5.6.2 package-id deepseq-1.4.6.0 package-id ghc-boot-th-9.2.1 package-id pretty-1.1.3.6 package-id template-haskell-2.18.0.0 package-id directory-1.3.6.2 package-id text-1.2.5.0 package-id vector-0.12.3.1-0ee0edddd7c1da5d41be6dd7eaa35c896ea170a10f2152c1d1b9be10fa606f06 $ ghci GHCi, version 9.2.1: https://www.haskell.org/ghc/ :? for help ghci> (Foreshadowing: Wait a second! Where is the obligatory message "Loaded package environment etc etc"?) ghci> import Data.Vector : error: Could not find module ‘Data.Vector’ Perhaps you meant Data.Functor (from base-4.16.0.0)