From R.Paterson at city.ac.uk Sat Mar 1 11:31:43 2014 From: R.Paterson at city.ac.uk (Ross Paterson) Date: Sat, 1 Mar 2014 11:31:43 +0000 Subject: Proposal: improve the Data.Tree API In-Reply-To: References: <530B2A49.8030605@ibotty.net> Message-ID: <20140301113143.GA4558@city.ac.uk> On Thu, Feb 27, 2014 at 11:34:23AM +0000, Jo?o Crist?v?o wrote: > So, proposal 2.0, with the received feedback: > > -- | get the sub-tree rooted at the first (left-most, depth-first) occurrence > -- of the specified node value > lookupTree :: Eq a => a -> Tree a -> Maybe (Tree a) > > -- | get the sub-tree rooted at the first (left-most, depth-first) value that > -- matches the provided condition > findTree :: (a -> Bool) -> Tree a -> Maybe (Tree a) > > -- | get the sub-tree for the specified node value in the first tree in > -- forest in which it occurs. > lookupTreeInForest :: Eq a => a -> [Tree a] -> Maybe (Tree a) These functions are similar, and one can imagine many more along similar lines: get all the subtrees whose roots satisfy a condition, conditions involving the number of children, etc. There's a concern that the interface becomes large and unwieldy, but without covering all uses. Instead of all these, perhaps it would be better to provide a more general function from which all these could be easily constructed: -- | List of subtrees (including the tree itself), in pre-order. subTrees :: Tree a -> [Tree a] Maybe one would want post-order too. It might also be useful to have a breadth-first variant: -- | List of subtrees at each level of the tree. subTreesByLevel :: Tree a -> [[Tree a]] Then again subTrees and subTreesByLevel are compositions of flatten and levels with the cojoin -- | Label each node of the tree with its full subtree. cojoin :: :: Tree a -> Tree (Tree a) cojoin t@(Node _ ts) = Node t (map cojoin ts) but maybe that's too abstract. > -- | keep only the elements that match the provided condition > filter :: (a -> Bool) -> Tree a -> Tree a Is the idea here to drop roots (promoting the child trees) or whole subtrees? Again one might want conditions that involve the subtrees as well as the root labels. From gale at sefer.org Sun Mar 2 13:08:13 2014 From: gale at sefer.org (Yitzchak Gale) Date: Sun, 2 Mar 2014 15:08:13 +0200 Subject: Proposal: improve the Data.Tree API In-Reply-To: <20140301113143.GA4558@city.ac.uk> References: <530B2A49.8030605@ibotty.net> <20140301113143.GA4558@city.ac.uk> Message-ID: Jo?o Crist?v?o wrote: >> So, proposal 2.0, with the received feedback: >> >> -- | get the sub-tree rooted at the first (left-most, depth-first) occurrence >> -- of the specified node value >> lookupTree :: Eq a => a -> Tree a -> Maybe (Tree a) >> >> -- | get the sub-tree rooted at the first (left-most, depth-first) value that >> -- matches the provided condition >> findTree :: (a -> Bool) -> Tree a -> Maybe (Tree a) >> >> -- | get the sub-tree for the specified node value in the first tree in >> -- forest in which it occurs. >> lookupTreeInForest :: Eq a => a -> [Tree a] -> Maybe (Tree a) Why is filter now missing? That's the one I've needed the most. Note however, that there are two possible implementations of filtering for Trees and Forests. The type signature you provided doesn't match any of them, so I'm not sure exactly what you had in mind. I support adding all four of these: -- | Prune every subtree whose root label does not match. filterPruneTree :: (a -> Bool) -> Tree a -> Maybe (Tree a) filterPruneTree p (Node x ns) | p x = Just . Node x $ filterPruneForest p ns | otherwise = Nothing filterPruneForest :: (a -> Bool) -> Forest a -> Forest a filterPruneForest = mapMaybe . filterPruneTree -- | Remove nodes that do not match, and graft the children of the removed node onto the tree in place of the parent. filterGraftTree :: (a -> Bool) -> Tree a -> Forest a filterGraftTree p (Node x ns) | p x = [Node x $ filterGraftForest p ns] | otherwise = filterGraftForest p ns filterGraftForest :: (a -> Bool) -> Forest a -> Forest a filterGraftForest = concatMap . filterGraftTree Ross Paterson wrote: > These functions are similar, and one can imagine many more along similar > lines: get all the subtrees whose roots satisfy a condition, conditions > involving the number of children, etc. There's a concern that the > interface becomes large and unwieldy, but without covering all uses... > perhaps it would be better to provide... > compositions of flatten and levels with the cojoin.. > but maybe that's too abstract. I think it's just that people missed the fact that we already have these functions via the Comonad instance. For that reason, I really haven't missed those functions. I'm not sure why you're saying it's abstract - the Comonad instance for Tree is very concrete, and in fact it's one of the fundamental examples of a comonad. Unfortunately, it's going to be tricky to write implementations of these functions in terms of extend and duplicate in the containers library itself, because containers is distributed with GHC whereas the comonad library isn't even in the Haskell Platform yet (it should be). We should either just document these uses in Data.Tree, or (for now) re-implement unexported versions of extend and duplicate inside Data.Tree, and mention in the documentation that these functions are simple applications of them. Thanks, Yitz From jmacristovao at gmail.com Sun Mar 2 16:47:36 2014 From: jmacristovao at gmail.com (=?ISO-8859-1?B?Sm/jbyBDcmlzdPN2428=?=) Date: Sun, 2 Mar 2014 16:47:36 +0000 Subject: Proposal: improve the Data.Tree API In-Reply-To: References: <530B2A49.8030605@ibotty.net> <20140301113143.GA4558@city.ac.uk> Message-ID: Hi again, Sorry for the delay. > I like lookupTree (being the one who suggested that) Indeed :) I'll include the new version of the proposal at end of the email. Just some quick notes first: > Why is filter now missing? That's the one I've needed the most. It isn't. Me too. Its just in a different order regarding proposal v1. But: > Note however, that there are two possible implementations > of filtering for Trees and Forests. The type signature you > provided doesn't match any of them, so I'm not sure exactly what > you had in mind. I agree! My proposal was actual identical to your filterPruneTree, where the first node was not actually analysed, but always kept. I agree that this is not the best approach, so yours seem fine (and I've included them). I do however raise the question: could one of them be 'promoted' to a simpler just 'filter' name? > I think it's just that people missed the fact that we already > have these functions via the Comonad instance. Indeed, that is my case, and I can only guess, many others. Please take the following opinion as one of a beginner, not as criticism, which it isn't: So, my opinion on this is that since comonads are not included in the haskell platform (for now), we should provide a more complete api. On the other hand, if the comonads are indeed a better aproach, then provide a link to comonads and _good dead simple examples on usage_. Right now I look at the comonad api and cannot see how to use it on trees. I guess I don't understand the utility of cojoin. My limitation, I'm sure... Consider proposal 3.0.b Milan's idea of splitting forest functions to a different submodule. Milan, could you please elaborate on that? I didn't quite get how they would have the same name... (My) Proposal 3.0 a) (Ord instance for Tree) -- | get the sub-tree rooted at the first (left-most, depth-first) occurrence -- of the specified node value lookupTree :: Eq a => a -> Tree a -> Maybe (Tree a) -- | get the sub-tree rooted at the first (left-most, depth-first) value that -- matches the provided condition lookupTreeBy :: (a -> Bool) -> Tree a -> Maybe (Tree a) -- | get the sub-tree for the specified node value in the first tree in -- forest in which it occurs. lookupTreeInForest :: Eq a => a -> [Tree a] -> Maybe (Tree a) -- | get the sub-tree for the specified node value in the first tree in -- forest in which it occurs. lookupTreeInForestBy :: (a -> Bool) -> [Tree a] -> Maybe (Tree a) -- | Size of the (flattened) tree size :: Tree a -> Int size = getSum . F.foldMap (const $ Sum 1) -- | Maximum depth of tree maxDepth :: Tree a -> Int -- | Remove all nodes past a certain depth prune :: Int -> Tree a -> Tree a -- | Take the mirror-image of a tree mirror :: Tree a -> Tree a mirror (Node a ts) = Node a . reverse $ map mirror ts -- | List of subtrees (including the tree itself), in pre-order. subTrees :: Tree a -> [Tree a] -- | List of subtrees at each level of the tree. subTreesByLevel :: Tree a -> [[Tree a]] -- | Label each node of the tree with its full subtree. cojoin :: :: Tree a -> Tree (Tree a) cojoin t@(Node _ ts) = Node t (map cojoin ts) -- | Prune every subtree whose root label does not match. filterPruneTree :: (a -> Bool) -> Tree a -> Maybe (Tree a) filterPruneTree p (Node x ns) | p x = Just . Node x $ filterPruneForest p ns | otherwise = Nothing filterPruneForest :: (a -> Bool) -> Forest a -> Forest a filterPruneForest = mapMaybe . filterPruneTree -- | Remove nodes that do not match, and graft the children of the removed node onto the tree in place of the parent. filterGraftTree :: (a -> Bool) -> Tree a -> Forest a filterGraftTree p (Node x ns) | p x = [Node x $ filterGraftForest p ns] | otherwise = filterGraftForest p ns filterGraftForest :: (a -> Bool) -> Forest a -> Forest a filterGraftForest = concatMap . filterGraftTree 2014-03-02 13:08 GMT+00:00 Yitzchak Gale : > Jo?o Crist?v?o wrote: > >> So, proposal 2.0, with the received feedback: > >> > >> -- | get the sub-tree rooted at the first (left-most, depth-first) > occurrence > >> -- of the specified node value > >> lookupTree :: Eq a => a -> Tree a -> Maybe (Tree a) > >> > >> -- | get the sub-tree rooted at the first (left-most, depth-first) > value that > >> -- matches the provided condition > >> findTree :: (a -> Bool) -> Tree a -> Maybe (Tree a) > >> > >> -- | get the sub-tree for the specified node value in the first tree in > >> -- forest in which it occurs. > >> lookupTreeInForest :: Eq a => a -> [Tree a] -> Maybe (Tree a) > > Why is filter now missing? That's the one I've needed the most. > > Note however, that there are two possible implementations > of filtering for Trees and Forests. The type signature you > provided doesn't match any of them, so I'm not sure exactly what > you had in mind. I support adding all four of these: > > -- | Prune every subtree whose root label does not match. > filterPruneTree :: (a -> Bool) -> Tree a -> Maybe (Tree a) > filterPruneTree p (Node x ns) > | p x = Just . Node x $ filterPruneForest p ns > | otherwise = Nothing > > filterPruneForest :: (a -> Bool) -> Forest a -> Forest a > filterPruneForest = mapMaybe . filterPruneTree > > -- | Remove nodes that do not match, and graft the children of the > removed node onto the tree in place of the parent. > filterGraftTree :: (a -> Bool) -> Tree a -> Forest a > filterGraftTree p (Node x ns) > | p x = [Node x $ filterGraftForest p ns] > | otherwise = filterGraftForest p ns > > filterGraftForest :: (a -> Bool) -> Forest a -> Forest a > filterGraftForest = concatMap . filterGraftTree > > Ross Paterson wrote: > > These functions are similar, and one can imagine many more along similar > > lines: get all the subtrees whose roots satisfy a condition, conditions > > involving the number of children, etc. There's a concern that the > > interface becomes large and unwieldy, but without covering all uses... > > perhaps it would be better to provide... > > compositions of flatten and levels with the cojoin.. > > but maybe that's too abstract. > > I think it's just that people missed the fact that we already > have these functions via the Comonad instance. > For that reason, I really haven't missed those functions. > I'm not sure why you're saying it's abstract - the Comonad > instance for Tree is very concrete, and in fact it's one of the > fundamental examples of a comonad. > > Unfortunately, it's going to be tricky to write implementations > of these functions in terms of extend and duplicate in the > containers library itself, because containers is distributed > with GHC whereas the comonad library isn't even in the > Haskell Platform yet (it should be). > > We should either just document these uses in Data.Tree, > or (for now) re-implement unexported versions of > extend and duplicate inside Data.Tree, and mention > in the documentation that these functions are simple > applications of them. > > Thanks, > Yitz > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ashley at semantic.org Mon Mar 3 05:28:27 2014 From: ashley at semantic.org (Ashley Yakeley) Date: Sun, 02 Mar 2014 21:28:27 -0800 Subject: ANN: time-1.4.2 Message-ID: <531412FB.9050105@semantic.org> time-1.4.2 is now available from Hackage. This update is one contributed improvement, Safe Haskell annotation, from Omari Norman. Thanks! -- Ashley Yakeley From winterkoninkje at gmail.com Sat Mar 8 04:03:32 2014 From: winterkoninkje at gmail.com (wren ng thornton) Date: Fri, 7 Mar 2014 23:03:32 -0500 Subject: Alex and GHC 7.8 Message-ID: Hello, In testing my packages for the impending GHC 7.8 release, I ran into some issues with Alex-generated code. In particular, it looks like the (>=#) and (==#) operators now return Int# instead of Bool, so expressions like if (offset >=# 0#) && (check ==# ord_c) then ... no longer type check. Is this a known issue? Are there any plans to fix it? I'd offer to submit a pull-request, but I'm not familiar with the Alex codebase so that'd take a while -- Live well, ~wren From carter.schonwald at gmail.com Sat Mar 8 04:12:03 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 7 Mar 2014 23:12:03 -0500 Subject: Alex and GHC 7.8 In-Reply-To: References: Message-ID: you need to use the new versions of alex and happy cabal update ; cabal install alex happy On Fri, Mar 7, 2014 at 11:03 PM, wren ng thornton wrote: > Hello, > > In testing my packages for the impending GHC 7.8 release, I ran into > some issues with Alex-generated code. In particular, it looks like the > (>=#) and (==#) operators now return Int# instead of Bool, so > expressions like > > if (offset >=# 0#) && (check ==# ord_c) then ... > > no longer type check. Is this a known issue? Are there any plans to > fix it? I'd offer to submit a pull-request, but I'm not familiar with > the Alex codebase so that'd take a while > > -- > Live well, > ~wren > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From winterkoninkje at gmail.com Sat Mar 8 04:45:18 2014 From: winterkoninkje at gmail.com (wren ng thornton) Date: Fri, 7 Mar 2014 23:45:18 -0500 Subject: Alex and GHC 7.8 In-Reply-To: References: Message-ID: On Fri, Mar 7, 2014 at 11:12 PM, Carter Schonwald wrote: > you need to use the new versions of alex and happy > > cabal update ; cabal install alex happy I have version 3.1.3 installed, but I still seem to be getting the same problem -- Live well, ~wren From winterkoninkje at gmail.com Sat Mar 8 04:46:48 2014 From: winterkoninkje at gmail.com (wren ng thornton) Date: Fri, 7 Mar 2014 23:46:48 -0500 Subject: Alex and GHC 7.8 In-Reply-To: References: Message-ID: On Fri, Mar 7, 2014 at 11:45 PM, wren ng thornton wrote: > On Fri, Mar 7, 2014 at 11:12 PM, Carter Schonwald > wrote: >> you need to use the new versions of alex and happy >> >> cabal update ; cabal install alex happy > > I have version 3.1.3 installed, but I still seem to be getting the same problem Hmmm, working now. Seems like cabal wasn't picking up the right alex... -- Live well, ~wren From slyich at gmail.com Sat Mar 8 08:38:16 2014 From: slyich at gmail.com (Sergei Trofimovich) Date: Sat, 8 Mar 2014 11:38:16 +0300 Subject: Alex and GHC 7.8 In-Reply-To: References: Message-ID: <20140308113816.6b647d20@sf> On Fri, 7 Mar 2014 23:46:48 -0500 wren ng thornton wrote: > On Fri, Mar 7, 2014 at 11:45 PM, wren ng thornton > wrote: > > On Fri, Mar 7, 2014 at 11:12 PM, Carter Schonwald > > wrote: > >> you need to use the new versions of alex and happy > >> > >> cabal update ; cabal install alex happy > > > > I have version 3.1.3 installed, but I still seem to be getting the same problem > > Hmmm, working now. Seems like cabal wasn't picking up the right alex... Or you were using already generated old lexer. -- Sergei -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From hvr at gnu.org Sat Mar 8 10:15:20 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Sat, 08 Mar 2014 11:15:20 +0100 Subject: [Final Summary] Proposal: add new Data.Bits.Bits(bitZero) method In-Reply-To: <87wqgnforj.fsf_-_@gnu.org> (Herbert Valerio Riedel's message of "Sat, 22 Feb 2014 11:03:12 +0100") References: <87r473uzyj.fsf@gnu.org> <1759239.FYxPxuDdch@berenger> <87ha7zuhyy.fsf_-_@gnu.org> <87wqgnforj.fsf_-_@gnu.org> Message-ID: <878uslm1xj.fsf_-_@gnu.org> On 2014-02-22 at 11:03:12 +0100, Herbert Valerio Riedel wrote: > Here's the result of the proposal > >>> Introduce a new class method >>> >>> class Bits a where >>> ... >>> -- | Value with all bits cleared >>> <0-value-method> :: a >>> ... >>> >>> modulo naming of '<0-value-method>' Unless I missed any votes, the current tally stands at for `Bits.zero` - ARJANEN Lo?c Jean David - Henning Thielemann - Herbert Valerio Riedel (+0.99) for 'Data.Bits.zeroBits' - Edward Kmett - Eric Mertens - Herbert Valerio Riedel - Twan van Laarhoven - (maybe?) ARJANEN Lo?c Jean David - Anthony Cowley (+0.5) This tilts the majority towards the name 'zeroBits' As the proposal-deadline was close to the RC2 release, this made it into GHC 7.8.1-RC2, and therefore GHC 7.8.1/base-4.7.0.0 will come with `Data.Bits.zeroBits`[1] Fwiw, there were some alternative names suggested, but those didn't gain significant support: cleared, noBits, clearedBits, whereDidTheBitsGo, notOneBit, allZeroes Beyond this proposal, it was hinted at that we might also want a name for 'complement zeroBits' (although that maybe a FiniteBits-instance), names suggested for that were allBits, allOnes, oneBits, iHaveAllTheBits, everyLastBit Cheers, hvr [1]: http://git.haskell.org/packages/base.git/commitdiff/147bca65bfac216bddff3ccde89409ca6323bb62 From roma at ro-che.info Sat Mar 8 12:10:50 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Sat, 8 Mar 2014 14:10:50 +0200 Subject: Alex and GHC 7.8 In-Reply-To: References: Message-ID: <20140308121050.GA14066@sniper> See http://ro-che.info/articles/2014-03-08-happy-alex-ghc-7.8.html * wren ng thornton [2014-03-07 23:03:32-0500] > Hello, > > In testing my packages for the impending GHC 7.8 release, I ran into > some issues with Alex-generated code. In particular, it looks like the > (>=#) and (==#) operators now return Int# instead of Bool, so > expressions like > > if (offset >=# 0#) && (check ==# ord_c) then ... > > no longer type check. Is this a known issue? Are there any plans to > fix it? I'd offer to submit a pull-request, but I'm not familiar with > the Alex codebase so that'd take a while > > -- > Live well, > ~wren > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From roma at ro-che.info Mon Mar 10 10:11:27 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Mon, 10 Mar 2014 12:11:27 +0200 Subject: Data.Dynamic: Any vs existential Message-ID: <20140310101127.GA7916@sniper> In Data.Dynamic, Dynamic is defined as data Dynamic = Dynamic TypeRep Any Does this have any advantage over a safer data Dynamic = forall a. Typeable a => Dynamic a ? Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From roma at ro-che.info Mon Mar 10 10:35:10 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Mon, 10 Mar 2014 12:35:10 +0200 Subject: Data.Dynamic: Any vs existential In-Reply-To: <20140310101127.GA7916@sniper> References: <20140310101127.GA7916@sniper> Message-ID: <20140310103510.GA12067@sniper> Ok, one reason is that the TypeRep won't be cached in the Dynamic value. Even in GHC 7.8 Typeable is defined as class Typeable a where typeRep# :: Proxy# a -> TypeRep instead of class Typeable a where typeRep :: Tagged a TypeRep Why? Is this an oversight? * Roman Cheplyaka [2014-03-10 12:11:27+0200] > In Data.Dynamic, Dynamic is defined as > > data Dynamic = Dynamic TypeRep Any > > Does this have any advantage over a safer > > data Dynamic = forall a. Typeable a => Dynamic a > > ? > > Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From simonpj at microsoft.com Mon Mar 10 11:26:42 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 10 Mar 2014 11:26:42 +0000 Subject: Data.Dynamic: Any vs existential In-Reply-To: <20140310103510.GA12067@sniper> References: <20140310101127.GA7916@sniper> <20140310103510.GA12067@sniper> Message-ID: <59543203684B2244980D7E4057D5FBC1487E0CD1@DB3EX14MBXC306.europe.corp.microsoft.com> Dear Core Libraries committee I think Roman is right here. Moreover we have known this for at least I think seven years http://comments.gmane.org/gmane.comp.lang.haskell.cafe/20097, where I wrote: | Yes, Dynamic preceded the Typeable class, I think. | Were we to do it today, I think we'd have | | data Dynamic = forall a . (Typeable a) => Dynamic a | | Whether it's worth changing, I'm not sure. It's a library so, | if a change desirable, anyone could take a lead. The new representation for Dynamic would be good because it's less insecure than all this "Obj" nonsense, instead relying on Typeable, which is pretty good these days. Pedro is the most recent visitor to this territory and may have views. Roman's point about the method for the Typeable class is a good one too, and not one I've seen discussed. Over to you Simon | -----Original Message----- | From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of | Roman Cheplyaka | Sent: 10 March 2014 10:35 | To: libraries at haskell.org | Subject: Re: Data.Dynamic: Any vs existential | | Ok, one reason is that the TypeRep won't be cached in the Dynamic value. | Even in GHC 7.8 Typeable is defined as | | class Typeable a where | typeRep# :: Proxy# a -> TypeRep | | instead of | | class Typeable a where | typeRep :: Tagged a TypeRep | | Why? Is this an oversight? | | * Roman Cheplyaka [2014-03-10 12:11:27+0200] | > In Data.Dynamic, Dynamic is defined as | > | > data Dynamic = Dynamic TypeRep Any | > | > Does this have any advantage over a safer | > | > data Dynamic = forall a. Typeable a => Dynamic a | > | > ? | > | > Roman From nikita.y.volkov at gmail.com Mon Mar 10 12:08:16 2014 From: nikita.y.volkov at gmail.com (Nikita Volkov) Date: Mon, 10 Mar 2014 16:08:16 +0400 Subject: Data.Dynamic: Any vs existential In-Reply-To: <59543203684B2244980D7E4057D5FBC1487E0CD1@DB3EX14MBXC306.europe.corp.microsoft.com> References: <20140310101127.GA7916@sniper> <20140310103510.GA12067@sniper> <59543203684B2244980D7E4057D5FBC1487E0CD1@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: What about the memory footprint? I recall making measurements using "ghc-datasize" package and the existential appeared to occupy much more space. 2014-03-10 15:26 GMT+04:00 Simon Peyton Jones : > Dear Core Libraries committee > > I think Roman is right here. Moreover we have known this for at least I > think seven years > http://comments.gmane.org/gmane.comp.lang.haskell.cafe/20097, where I > wrote: > > | Yes, Dynamic preceded the Typeable class, I think. > | Were we to do it today, I think we'd have > | > | data Dynamic = forall a . (Typeable a) => Dynamic a > | > | Whether it's worth changing, I'm not sure. It's a library so, > | if a change desirable, anyone could take a lead. > > The new representation for Dynamic would be good because it's less > insecure than all this "Obj" nonsense, instead relying on Typeable, which > is pretty good these days. > > Pedro is the most recent visitor to this territory and may have views. > > Roman's point about the method for the Typeable class is a good one too, > and not one I've seen discussed. > > Over to you > > Simon > > | -----Original Message----- > | From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of > | Roman Cheplyaka > | Sent: 10 March 2014 10:35 > | To: libraries at haskell.org > | Subject: Re: Data.Dynamic: Any vs existential > | > | Ok, one reason is that the TypeRep won't be cached in the Dynamic value. > | Even in GHC 7.8 Typeable is defined as > | > | class Typeable a where > | typeRep# :: Proxy# a -> TypeRep > | > | instead of > | > | class Typeable a where > | typeRep :: Tagged a TypeRep > | > | Why? Is this an oversight? > | > | * Roman Cheplyaka [2014-03-10 12:11:27+0200] > | > In Data.Dynamic, Dynamic is defined as > | > > | > data Dynamic = Dynamic TypeRep Any > | > > | > Does this have any advantage over a safer > | > > | > data Dynamic = forall a. Typeable a => Dynamic a > | > > | > ? > | > > | > Roman > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Mon Mar 10 12:30:05 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon, 10 Mar 2014 13:30:05 +0100 Subject: Proposal: add createPipe to base Message-ID: I've written a cross-platform* implementation of the pipe() syscall, currently for use within Cabal: createPipe :: IO (Handle, Handle) https://github.com/haskell/cabal/blob/master/Cabal/tests/Distribution/Compat/CreatePipe.hsc It's a bit of a shame to leave it in Cabal as it's generally useful. I propose we add it to System.IO. Note that we'd have to copy the 5 lines in System.Posix.IO.createPipe into base as the above implementation would otherwise depend on the unix package. Discussion period: 3 weeks. * Only tested on OS X, Windows, and Linux. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Mon Mar 10 12:32:06 2014 From: michael at snoyman.com (Michael Snoyman) Date: Mon, 10 Mar 2014 14:32:06 +0200 Subject: Proposal: add createPipe to base In-Reply-To: References: Message-ID: On Mon, Mar 10, 2014 at 2:30 PM, Johan Tibell wrote: > I've written a cross-platform* implementation of the pipe() syscall, > currently for use within Cabal: > > createPipe :: IO (Handle, Handle) > > https://github.com/haskell/cabal/blob/master/Cabal/tests/Distribution/Compat/CreatePipe.hsc > > It's a bit of a shame to leave it in Cabal as it's generally useful. > > I propose we add it to System.IO. Note that we'd have to copy the 5 lines > in System.Posix.IO.createPipe into base as the above implementation would > otherwise depend on the unix package. > > Discussion period: 3 weeks. > > * Only tested on OS X, Windows, and Linux. > > +1. I've needed this in the past when working with process, and ended up writing POSIX-only code as a result. -------------- next part -------------- An HTML attachment was scrubbed... URL: From igloo at earth.li Mon Mar 10 12:47:46 2014 From: igloo at earth.li (Ian Lynagh) Date: Mon, 10 Mar 2014 12:47:46 +0000 Subject: Proposal: add createPipe to base In-Reply-To: References: Message-ID: <20140310124746.GA11171@matrix.chaos.earth.li> On Mon, Mar 10, 2014 at 02:32:06PM +0200, Michael Snoyman wrote: > On Mon, Mar 10, 2014 at 2:30 PM, Johan Tibell wrote: > > > I propose we add it to System.IO. Note that we'd have to copy the 5 lines > > in System.Posix.IO.createPipe into base as the above implementation would > > otherwise depend on the unix package. > > > +1. I've needed this in the past when working with process, and ended up > writing POSIX-only code as a result. Would it make more sense to put it in process, and thus avoid needing to copy/move code into base? Thanks Ian From johan.tibell at gmail.com Mon Mar 10 12:54:29 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon, 10 Mar 2014 13:54:29 +0100 Subject: Proposal: add createPipe to base In-Reply-To: <20140310124746.GA11171@matrix.chaos.earth.li> References: <20140310124746.GA11171@matrix.chaos.earth.li> Message-ID: On Mon, Mar 10, 2014 at 1:47 PM, Ian Lynagh wrote: > On Mon, Mar 10, 2014 at 02:32:06PM +0200, Michael Snoyman wrote: > > On Mon, Mar 10, 2014 at 2:30 PM, Johan Tibell >wrote: > > > > > I propose we add it to System.IO. Note that we'd have to copy the 5 > lines > > > in System.Posix.IO.createPipe into base as the above implementation > would > > > otherwise depend on the unix package. > > > > > +1. I've needed this in the past when working with process, and ended up > > writing POSIX-only code as a result. > > Would it make more sense to put it in process, and thus avoid needing to > copy/move code into base? > I'm certainly open to that idea. If the only uses of pipes are for processes, I think that makes sense. Are there any typical non-process uses of pipes? I can't think of any right now. -- Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Mon Mar 10 13:01:39 2014 From: michael at snoyman.com (Michael Snoyman) Date: Mon, 10 Mar 2014 15:01:39 +0200 Subject: Proposal: add createPipe to base In-Reply-To: <20140310124746.GA11171@matrix.chaos.earth.li> References: <20140310124746.GA11171@matrix.chaos.earth.li> Message-ID: On Mon, Mar 10, 2014 at 2:47 PM, Ian Lynagh wrote: > On Mon, Mar 10, 2014 at 02:32:06PM +0200, Michael Snoyman wrote: > > On Mon, Mar 10, 2014 at 2:30 PM, Johan Tibell >wrote: > > > > > I propose we add it to System.IO. Note that we'd have to copy the 5 > lines > > > in System.Posix.IO.createPipe into base as the above implementation > would > > > otherwise depend on the unix package. > > > > > +1. I've needed this in the past when working with process, and ended up > > writing POSIX-only code as a result. > > Would it make more sense to put it in process, and thus avoid needing to > copy/move code into base? > > > I have no opinion on where it should go, process would be fine with me. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Mon Mar 10 13:18:40 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 10 Mar 2014 09:18:40 -0400 Subject: Proposal: add createPipe to base In-Reply-To: References: <20140310124746.GA11171@matrix.chaos.earth.li> Message-ID: On Mon, Mar 10, 2014 at 8:54 AM, Johan Tibell wrote: > On Mon, Mar 10, 2014 at 1:47 PM, Ian Lynagh wrote: > >> On Mon, Mar 10, 2014 at 02:32:06PM +0200, Michael Snoyman wrote: >> > On Mon, Mar 10, 2014 at 2:30 PM, Johan Tibell > >wrote: >> > > I propose we add it to System.IO. Note that we'd have to copy the 5 >> lines >> > > in System.Posix.IO.createPipe into base as the above implementation >> would >> > > otherwise depend on the unix package. >> > > >> > +1. I've needed this in the past when working with process, and ended up >> > writing POSIX-only code as a result. >> >> Would it make more sense to put it in process, and thus avoid needing to >> copy/move code into base? >> > > I'm certainly open to that idea. If the only uses of pipes are for > processes, I think that makes sense. Are there any typical non-process uses > of pipes? I can't think of any right now. > I know of one in C, and it seems potentially applicable to Haskell as well, but it's mostly(?) a Unix-ism: you allocate a pipe, write to it in a signal handler, and monitor the read end in an event loop (in Haskell, a thread) in order to change an asynchronous signal that may have happened when it's unsafe to e.g. allocate memory into a synchronous event that can be handled safely. Note that you must use an unbuffered write from System.Posix.IO to write from the signal handler safely, so this introduces a hard dependency on the `unix` package; although there may be a win32 equivalent. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.doel at gmail.com Mon Mar 10 15:54:34 2014 From: dan.doel at gmail.com (Dan Doel) Date: Mon, 10 Mar 2014 11:54:34 -0400 Subject: [core libraries] RE: Data.Dynamic: Any vs existential In-Reply-To: <59543203684B2244980D7E4057D5FBC1487E0CD1@DB3EX14MBXC306.europe.corp.microsoft.com> References: <20140310101127.GA7916@sniper> <20140310103510.GA12067@sniper> <59543203684B2244980D7E4057D5FBC1487E0CD1@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: On Mon, Mar 10, 2014 at 7:26 AM, Simon Peyton Jones wrote: > Dear Core Libraries committee > > I think Roman is right here. Moreover we have known this for at least I > think seven years > http://comments.gmane.org/gmane.comp.lang.haskell.cafe/20097, where I > wrote: > > | Yes, Dynamic preceded the Typeable class, I think. > | Were we to do it today, I think we'd have > | > | data Dynamic = forall a . (Typeable a) => Dynamic a > | > | Whether it's worth changing, I'm not sure. It's a library so, > | if a change desirable, anyone could take a lead. > > The new representation for Dynamic would be good because it's less > insecure than all this "Obj" nonsense, instead relying on Typeable, which > is pretty good these days. > > Pedro is the most recent visitor to this territory and may have views. > > Roman's point about the method for the Typeable class is a good one too, > and not one I've seen discussed. > > Over to you > I, at least, am in favor of this. I've thought for a while that the ideal form of all this is something like: data TypeRep a -- indexed by a class Typeable a where typeRep :: TypeRep a data Dynamic = forall a. Dynamic (TypeRep a) a Where, ideally, TypeRep is an indexed type, and you can match on it to refine its argument. Then Typeable just becomes the implicit version of this evidence, for convenience. TypeRep versions of cast would also have to be primitive probably (since one can not, a priori, enumerate the diagonal of all possible monotypes, now and in the future). Anyhow, I don't know if this entire interface is or will be implementable in GHC (the idea comes from a document about JHC way back, although I don't know if even it implements this), but using Typeable in an existential captures the Dynamic part of it, at least. Also, I hadn't seen the Tagged version of Typeable before (and hadn't thought of it myself). I expect it's an oversight that this wasn't the form chosen, as it seems superior to me. In fact, it seems like every situation where the 0-width Proxy# could be used, Tagged could also be used instead, and is automatically 0-width, and has better sharing behavior? Unless you explicitly don't want sharing, that is. It seems like any relative inconvenience could probably be alleviated by the proxy function in tagged, while keeping the nicer behavior. -- Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Mon Mar 10 17:44:13 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 10 Mar 2014 13:44:13 -0400 Subject: [core libraries] RE: Data.Dynamic: Any vs existential In-Reply-To: References: <20140310101127.GA7916@sniper> <20140310103510.GA12067@sniper> <59543203684B2244980D7E4057D5FBC1487E0CD1@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: +++++1000 to dan doels strawman suggestion. I'm a huge fan of indexed types style apis like that one. On Mon, Mar 10, 2014 at 11:54 AM, Dan Doel wrote: > On Mon, Mar 10, 2014 at 7:26 AM, Simon Peyton Jones > wrote: > >> Dear Core Libraries committee >> >> I think Roman is right here. Moreover we have known this for at least I >> think seven years >> http://comments.gmane.org/gmane.comp.lang.haskell.cafe/20097, where I >> wrote: >> >> | Yes, Dynamic preceded the Typeable class, I think. >> | Were we to do it today, I think we'd have >> | >> | data Dynamic = forall a . (Typeable a) => Dynamic a >> | >> | Whether it's worth changing, I'm not sure. It's a library so, >> | if a change desirable, anyone could take a lead. >> >> The new representation for Dynamic would be good because it's less >> insecure than all this "Obj" nonsense, instead relying on Typeable, which >> is pretty good these days. >> >> Pedro is the most recent visitor to this territory and may have views. >> >> Roman's point about the method for the Typeable class is a good one too, >> and not one I've seen discussed. >> >> Over to you >> > > I, at least, am in favor of this. I've thought for a while that the ideal > form of all this is something like: > > data TypeRep a -- indexed by a > > class Typeable a where > typeRep :: TypeRep a > > data Dynamic = forall a. Dynamic (TypeRep a) a > > > Where, ideally, TypeRep is an indexed type, and you can match on it to > refine its argument. Then Typeable just becomes the implicit version of > this evidence, for convenience. TypeRep versions of cast would also have to > be primitive probably (since one can not, a priori, enumerate the diagonal > of all possible monotypes, now and in the future). > > Anyhow, I don't know if this entire interface is or will be implementable > in GHC (the idea comes from a document about JHC way back, although I don't > know if even it implements this), but using Typeable in an existential > captures the Dynamic part of it, at least. > > Also, I hadn't seen the Tagged version of Typeable before (and hadn't > thought of it myself). I expect it's an oversight that this wasn't the form > chosen, as it seems superior to me. In fact, it seems like every situation > where the 0-width Proxy# could be used, Tagged could also be used instead, > and is automatically 0-width, and has better sharing behavior? Unless you > explicitly don't want sharing, that is. > > It seems like any relative inconvenience could probably be alleviated by > the proxy function in tagged, while keeping the nicer behavior. > > -- Dan > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.doel at gmail.com Mon Mar 10 18:01:47 2014 From: dan.doel at gmail.com (Dan Doel) Date: Mon, 10 Mar 2014 14:01:47 -0400 Subject: Data.Dynamic: Any vs existential In-Reply-To: <20140310103510.GA12067@sniper> References: <20140310101127.GA7916@sniper> <20140310103510.GA12067@sniper> Message-ID: On Mon, Mar 10, 2014 at 6:35 AM, Roman Cheplyaka wrote: > Ok, one reason is that the TypeRep won't be cached in the Dynamic value. > Even in GHC 7.8 Typeable is defined as > > class Typeable a where > typeRep# :: Proxy# a -> TypeRep > > instead of > > class Typeable a where > typeRep :: Tagged a TypeRep > > Why? Is this an oversight? > I talked with Ed about this, and he noted that this might be a false problem. Certainly, the Proxy# is never actually used, so as long as the generated instances are of the form: typeRep# = let tr = ... in \_ -> tr the TypeReps are shared, and are at most a bit of indirection away. Also, how different are (Tagged tr :: Tagged a TypeRep) and ((\_ -> tr) :: Proxy# a -> TypeRep) at a low level? I know the constructor of the former disappears in core, but don't know what specifically happens with 0-width fields like Proxy#. Is the latter slightly less efficient? If so, can the optimizer eliminate the difference for cases like this? -- Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Mon Mar 10 18:09:01 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Mon, 10 Mar 2014 20:09:01 +0200 Subject: [core libraries] RE: Data.Dynamic: Any vs existential In-Reply-To: References: <20140310101127.GA7916@sniper> <20140310103510.GA12067@sniper> <59543203684B2244980D7E4057D5FBC1487E0CD1@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: <20140310180901.GA27976@sniper> Adding a phantom type to TypeRep itself will break a lot of code (the untyped TypeRep is used quite a bit) without any real benefit (it's essentially the same as Tagged a TypeRep). * Carter Schonwald [2014-03-10 13:44:13-0400] > +++++1000 to dan doels strawman suggestion. > > I'm a huge fan of indexed types style apis like that one. > > > On Mon, Mar 10, 2014 at 11:54 AM, Dan Doel wrote: > > > On Mon, Mar 10, 2014 at 7:26 AM, Simon Peyton Jones > > wrote: > > > >> Dear Core Libraries committee > >> > >> I think Roman is right here. Moreover we have known this for at least I > >> think seven years > >> http://comments.gmane.org/gmane.comp.lang.haskell.cafe/20097, where I > >> wrote: > >> > >> | Yes, Dynamic preceded the Typeable class, I think. > >> | Were we to do it today, I think we'd have > >> | > >> | data Dynamic = forall a . (Typeable a) => Dynamic a > >> | > >> | Whether it's worth changing, I'm not sure. It's a library so, > >> | if a change desirable, anyone could take a lead. > >> > >> The new representation for Dynamic would be good because it's less > >> insecure than all this "Obj" nonsense, instead relying on Typeable, which > >> is pretty good these days. > >> > >> Pedro is the most recent visitor to this territory and may have views. > >> > >> Roman's point about the method for the Typeable class is a good one too, > >> and not one I've seen discussed. > >> > >> Over to you > >> > > > > I, at least, am in favor of this. I've thought for a while that the ideal > > form of all this is something like: > > > > data TypeRep a -- indexed by a > > > > class Typeable a where > > typeRep :: TypeRep a > > > > data Dynamic = forall a. Dynamic (TypeRep a) a > > > > > > Where, ideally, TypeRep is an indexed type, and you can match on it to > > refine its argument. Then Typeable just becomes the implicit version of > > this evidence, for convenience. TypeRep versions of cast would also have to > > be primitive probably (since one can not, a priori, enumerate the diagonal > > of all possible monotypes, now and in the future). > > > > Anyhow, I don't know if this entire interface is or will be implementable > > in GHC (the idea comes from a document about JHC way back, although I don't > > know if even it implements this), but using Typeable in an existential > > captures the Dynamic part of it, at least. > > > > Also, I hadn't seen the Tagged version of Typeable before (and hadn't > > thought of it myself). I expect it's an oversight that this wasn't the form > > chosen, as it seems superior to me. In fact, it seems like every situation > > where the 0-width Proxy# could be used, Tagged could also be used instead, > > and is automatically 0-width, and has better sharing behavior? Unless you > > explicitly don't want sharing, that is. > > > > It seems like any relative inconvenience could probably be alleviated by > > the proxy function in tagged, while keeping the nicer behavior. > > > > -- Dan > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From ekmett at gmail.com Mon Mar 10 19:29:49 2014 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 10 Mar 2014 15:29:49 -0400 Subject: Proposal: add createPipe to base In-Reply-To: References: Message-ID: +1 for me. I have a slight preference for putting it in process over base given that we're considering a mass exodus of material from base in a couple of years and it'd be one more thing to move, but it is a very slight preference. -Edward On Mon, Mar 10, 2014 at 8:30 AM, Johan Tibell wrote: > I've written a cross-platform* implementation of the pipe() syscall, > currently for use within Cabal: > > createPipe :: IO (Handle, Handle) > > https://github.com/haskell/cabal/blob/master/Cabal/tests/Distribution/Compat/CreatePipe.hsc > > It's a bit of a shame to leave it in Cabal as it's generally useful. > > I propose we add it to System.IO. Note that we'd have to copy the 5 lines > in System.Posix.IO.createPipe into base as the above implementation would > otherwise depend on the unix package. > > Discussion period: 3 weeks. > > * Only tested on OS X, Windows, and Linux. > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas at incubaid.com Mon Mar 10 19:41:23 2014 From: nicolas at incubaid.com (Nicolas Trangez) Date: Mon, 10 Mar 2014 20:41:23 +0100 Subject: Proposal: add createPipe to base In-Reply-To: References: <20140310124746.GA11171@matrix.chaos.earth.li> Message-ID: On Mar 10, 2014 1:54 PM, "Johan Tibell" wrote: > > On Mon, Mar 10, 2014 at 1:47 PM, Ian Lynagh wrote: >> >> On Mon, Mar 10, 2014 at 02:32:06PM +0200, Michael Snoyman wrote: >> > On Mon, Mar 10, 2014 at 2:30 PM, Johan Tibell wrote: >> > >> > > I propose we add it to System.IO. Note that we'd have to copy the 5 lines >> > > in System.Posix.IO.createPipe into base as the above implementation would >> > > otherwise depend on the unix package. >> > > >> > +1. I've needed this in the past when working with process, and ended up >> > writing POSIX-only code as a result. >> >> Would it make more sense to put it in process, and thus avoid needing to >> copy/move code into base? > > > I'm certainly open to that idea. If the only uses of pipes are for processes, I think that makes sense. Are there any typical non-process uses of pipes? I can't think of any right now. Yes: transferring data from one socket to another in a zero-copy fashion using the 'splice' syscall in Linux requires passing stuff through a pipe (used as a buffer). I for one wouldn't consider a dependency on 'process' to write such code (if I ever would in Haskell...) to be a problem though. Nicolas -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Mon Mar 10 20:04:02 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Mon, 10 Mar 2014 21:04:02 +0100 Subject: Proposal: add createPipe to base In-Reply-To: (Johan Tibell's message of "Mon, 10 Mar 2014 13:30:05 +0100") References: Message-ID: <87siqpizwt.fsf@gnu.org> On 2014-03-10 at 13:30:05 +0100, Johan Tibell wrote: > I've written a cross-platform* implementation of the pipe() syscall, > currently for use within Cabal: > > createPipe :: IO (Handle, Handle) > https://github.com/haskell/cabal/blob/master/Cabal/tests/Distribution/Compat/CreatePipe.hsc > > It's a bit of a shame to leave it in Cabal as it's generally useful. > > I propose we add it to System.IO. Note that we'd have to copy the 5 lines > in System.Posix.IO.createPipe into base as the above implementation would > otherwise depend on the unix package. +1 from me (with a preference to put it in 'process' if that's still on the table) From carter.schonwald at gmail.com Mon Mar 10 20:04:21 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 10 Mar 2014 16:04:21 -0400 Subject: [core libraries] RE: Data.Dynamic: Any vs existential In-Reply-To: <20140310180901.GA27976@sniper> References: <20140310101127.GA7916@sniper> <20140310103510.GA12067@sniper> <59543203684B2244980D7E4057D5FBC1487E0CD1@DB3EX14MBXC306.europe.corp.microsoft.com> <20140310180901.GA27976@sniper> Message-ID: isn't it a GADT/singleton/data family more than a phantom? On Mon, Mar 10, 2014 at 2:09 PM, Roman Cheplyaka wrote: > Adding a phantom type to TypeRep itself will break a lot of code (the > untyped > TypeRep is used quite a bit) without any real benefit (it's essentially > the same > as Tagged a TypeRep). > > * Carter Schonwald [2014-03-10 13:44:13-0400] > > +++++1000 to dan doels strawman suggestion. > > > > I'm a huge fan of indexed types style apis like that one. > > > > > > On Mon, Mar 10, 2014 at 11:54 AM, Dan Doel wrote: > > > > > On Mon, Mar 10, 2014 at 7:26 AM, Simon Peyton Jones < > simonpj at microsoft.com > > > > wrote: > > > > > >> Dear Core Libraries committee > > >> > > >> I think Roman is right here. Moreover we have known this for at least > I > > >> think seven years > > >> http://comments.gmane.org/gmane.comp.lang.haskell.cafe/20097, where I > > >> wrote: > > >> > > >> | Yes, Dynamic preceded the Typeable class, I think. > > >> | Were we to do it today, I think we'd have > > >> | > > >> | data Dynamic = forall a . (Typeable a) => Dynamic a > > >> | > > >> | Whether it's worth changing, I'm not sure. It's a library so, > > >> | if a change desirable, anyone could take a lead. > > >> > > >> The new representation for Dynamic would be good because it's less > > >> insecure than all this "Obj" nonsense, instead relying on Typeable, > which > > >> is pretty good these days. > > >> > > >> Pedro is the most recent visitor to this territory and may have views. > > >> > > >> Roman's point about the method for the Typeable class is a good one > too, > > >> and not one I've seen discussed. > > >> > > >> Over to you > > >> > > > > > > I, at least, am in favor of this. I've thought for a while that the > ideal > > > form of all this is something like: > > > > > > data TypeRep a -- indexed by a > > > > > > class Typeable a where > > > typeRep :: TypeRep a > > > > > > data Dynamic = forall a. Dynamic (TypeRep a) a > > > > > > > > > Where, ideally, TypeRep is an indexed type, and you can match on it to > > > refine its argument. Then Typeable just becomes the implicit version of > > > this evidence, for convenience. TypeRep versions of cast would also > have to > > > be primitive probably (since one can not, a priori, enumerate the > diagonal > > > of all possible monotypes, now and in the future). > > > > > > Anyhow, I don't know if this entire interface is or will be > implementable > > > in GHC (the idea comes from a document about JHC way back, although I > don't > > > know if even it implements this), but using Typeable in an existential > > > captures the Dynamic part of it, at least. > > > > > > Also, I hadn't seen the Tagged version of Typeable before (and hadn't > > > thought of it myself). I expect it's an oversight that this wasn't the > form > > > chosen, as it seems superior to me. In fact, it seems like every > situation > > > where the 0-width Proxy# could be used, Tagged could also be used > instead, > > > and is automatically 0-width, and has better sharing behavior? Unless > you > > > explicitly don't want sharing, that is. > > > > > > It seems like any relative inconvenience could probably be alleviated > by > > > the proxy function in tagged, while keeping the nicer behavior. > > > > > > -- Dan > > > > > > _______________________________________________ > > > Libraries mailing list > > > Libraries at haskell.org > > > http://www.haskell.org/mailman/listinfo/libraries > > > > > > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Mon Mar 10 20:18:39 2014 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 10 Mar 2014 16:18:39 -0400 Subject: Data.Dynamic: Any vs existential In-Reply-To: <20140310103510.GA12067@sniper> References: <20140310101127.GA7916@sniper> <20140310103510.GA12067@sniper> Message-ID: One reason for favoring the Proxy# a style over the Tagged style is almost any manipulation of the Tagged variant requires ScopedTypeVariables and a very awkward programming style, while a 0-width proxy can be passed around like an explicit type application. Otherwise they are largely equivalent if you're careful about how the low level definitions work. As the original author of both, I'm not personally wedded to either the Tagged or the Proxy style, but I find in practice the Proxy version leads to much prettier code that is easier to follow. -Edward On Mon, Mar 10, 2014 at 6:35 AM, Roman Cheplyaka wrote: > Ok, one reason is that the TypeRep won't be cached in the Dynamic value. > Even in GHC 7.8 Typeable is defined as > > class Typeable a where > typeRep# :: Proxy# a -> TypeRep > > instead of > > class Typeable a where > typeRep :: Tagged a TypeRep > > Why? Is this an oversight? > > * Roman Cheplyaka [2014-03-10 12:11:27+0200] > > In Data.Dynamic, Dynamic is defined as > > > > data Dynamic = Dynamic TypeRep Any > > > > Does this have any advantage over a safer > > > > data Dynamic = forall a. Typeable a => Dynamic a > > > > ? > > > > Roman > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Mon Mar 10 20:25:59 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Mon, 10 Mar 2014 22:25:59 +0200 Subject: [core libraries] RE: Data.Dynamic: Any vs existential In-Reply-To: References: <20140310101127.GA7916@sniper> <20140310103510.GA12067@sniper> <59543203684B2244980D7E4057D5FBC1487E0CD1@DB3EX14MBXC306.europe.corp.microsoft.com> <20140310180901.GA27976@sniper> Message-ID: <20140310202559.GA30771@sniper> Right ? I misunderstood what Dan meant on the first reading. Then it's an even more drastic change to Typeable. And it's not clear (to me, at least) how it should work. * Carter Schonwald [2014-03-10 16:04:21-0400] > isn't it a GADT/singleton/data family more than a phantom? > > > > > On Mon, Mar 10, 2014 at 2:09 PM, Roman Cheplyaka wrote: > > > Adding a phantom type to TypeRep itself will break a lot of code (the > > untyped > > TypeRep is used quite a bit) without any real benefit (it's essentially > > the same > > as Tagged a TypeRep). > > > > * Carter Schonwald [2014-03-10 13:44:13-0400] > > > +++++1000 to dan doels strawman suggestion. > > > > > > I'm a huge fan of indexed types style apis like that one. > > > > > > > > > On Mon, Mar 10, 2014 at 11:54 AM, Dan Doel wrote: > > > > > > > On Mon, Mar 10, 2014 at 7:26 AM, Simon Peyton Jones < > > simonpj at microsoft.com > > > > > wrote: > > > > > > > >> Dear Core Libraries committee > > > >> > > > >> I think Roman is right here. Moreover we have known this for at least > > I > > > >> think seven years > > > >> http://comments.gmane.org/gmane.comp.lang.haskell.cafe/20097, where I > > > >> wrote: > > > >> > > > >> | Yes, Dynamic preceded the Typeable class, I think. > > > >> | Were we to do it today, I think we'd have > > > >> | > > > >> | data Dynamic = forall a . (Typeable a) => Dynamic a > > > >> | > > > >> | Whether it's worth changing, I'm not sure. It's a library so, > > > >> | if a change desirable, anyone could take a lead. > > > >> > > > >> The new representation for Dynamic would be good because it's less > > > >> insecure than all this "Obj" nonsense, instead relying on Typeable, > > which > > > >> is pretty good these days. > > > >> > > > >> Pedro is the most recent visitor to this territory and may have views. > > > >> > > > >> Roman's point about the method for the Typeable class is a good one > > too, > > > >> and not one I've seen discussed. > > > >> > > > >> Over to you > > > >> > > > > > > > > I, at least, am in favor of this. I've thought for a while that the > > ideal > > > > form of all this is something like: > > > > > > > > data TypeRep a -- indexed by a > > > > > > > > class Typeable a where > > > > typeRep :: TypeRep a > > > > > > > > data Dynamic = forall a. Dynamic (TypeRep a) a > > > > > > > > > > > > Where, ideally, TypeRep is an indexed type, and you can match on it to > > > > refine its argument. Then Typeable just becomes the implicit version of > > > > this evidence, for convenience. TypeRep versions of cast would also > > have to > > > > be primitive probably (since one can not, a priori, enumerate the > > diagonal > > > > of all possible monotypes, now and in the future). > > > > > > > > Anyhow, I don't know if this entire interface is or will be > > implementable > > > > in GHC (the idea comes from a document about JHC way back, although I > > don't > > > > know if even it implements this), but using Typeable in an existential > > > > captures the Dynamic part of it, at least. > > > > > > > > Also, I hadn't seen the Tagged version of Typeable before (and hadn't > > > > thought of it myself). I expect it's an oversight that this wasn't the > > form > > > > chosen, as it seems superior to me. In fact, it seems like every > > situation > > > > where the 0-width Proxy# could be used, Tagged could also be used > > instead, > > > > and is automatically 0-width, and has better sharing behavior? Unless > > you > > > > explicitly don't want sharing, that is. > > > > > > > > It seems like any relative inconvenience could probably be alleviated > > by > > > > the proxy function in tagged, while keeping the nicer behavior. > > > > > > > > -- Dan > > > > > > > > _______________________________________________ > > > > Libraries mailing list > > > > Libraries at haskell.org > > > > http://www.haskell.org/mailman/listinfo/libraries > > > > > > > > > > > > > _______________________________________________ > > > Libraries mailing list > > > Libraries at haskell.org > > > http://www.haskell.org/mailman/listinfo/libraries > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From dan.doel at gmail.com Mon Mar 10 20:38:52 2014 From: dan.doel at gmail.com (Dan Doel) Date: Mon, 10 Mar 2014 16:38:52 -0400 Subject: [core libraries] RE: Data.Dynamic: Any vs existential In-Reply-To: <20140310202559.GA30771@sniper> References: <20140310101127.GA7916@sniper> <20140310103510.GA12067@sniper> <59543203684B2244980D7E4057D5FBC1487E0CD1@DB3EX14MBXC306.europe.corp.microsoft.com> <20140310180901.GA27976@sniper> <20140310202559.GA30771@sniper> Message-ID: Note, I'm not proposing that we change Typeable to match my vision. I just think that it is (closer to) an ideal formulation, and the existential Dynamic is closer to it, and thus good. :) Changing the definition of Dynamic should have about 0 cost API-wise, which makes it a no brainer. The same can't be said for the rest of my ideal Typeable, though, which probably rules it out. On Mon, Mar 10, 2014 at 4:25 PM, Roman Cheplyaka wrote: > Right -- I misunderstood what Dan meant on the first reading. > > Then it's an even more drastic change to Typeable. And it's not clear (to > me, at > least) how it should work. > > * Carter Schonwald [2014-03-10 16:04:21-0400] > > isn't it a GADT/singleton/data family more than a phantom? > > > > > > > > > > On Mon, Mar 10, 2014 at 2:09 PM, Roman Cheplyaka > wrote: > > > > > Adding a phantom type to TypeRep itself will break a lot of code (the > > > untyped > > > TypeRep is used quite a bit) without any real benefit (it's essentially > > > the same > > > as Tagged a TypeRep). > > > > > > * Carter Schonwald [2014-03-10 > 13:44:13-0400] > > > > +++++1000 to dan doels strawman suggestion. > > > > > > > > I'm a huge fan of indexed types style apis like that one. > > > > > > > > > > > > On Mon, Mar 10, 2014 at 11:54 AM, Dan Doel > wrote: > > > > > > > > > On Mon, Mar 10, 2014 at 7:26 AM, Simon Peyton Jones < > > > simonpj at microsoft.com > > > > > > wrote: > > > > > > > > > >> Dear Core Libraries committee > > > > >> > > > > >> I think Roman is right here. Moreover we have known this for at > least > > > I > > > > >> think seven years > > > > >> http://comments.gmane.org/gmane.comp.lang.haskell.cafe/20097, > where I > > > > >> wrote: > > > > >> > > > > >> | Yes, Dynamic preceded the Typeable class, I think. > > > > >> | Were we to do it today, I think we'd have > > > > >> | > > > > >> | data Dynamic = forall a . (Typeable a) => Dynamic a > > > > >> | > > > > >> | Whether it's worth changing, I'm not sure. It's a library so, > > > > >> | if a change desirable, anyone could take a lead. > > > > >> > > > > >> The new representation for Dynamic would be good because it's less > > > > >> insecure than all this "Obj" nonsense, instead relying on > Typeable, > > > which > > > > >> is pretty good these days. > > > > >> > > > > >> Pedro is the most recent visitor to this territory and may have > views. > > > > >> > > > > >> Roman's point about the method for the Typeable class is a good > one > > > too, > > > > >> and not one I've seen discussed. > > > > >> > > > > >> Over to you > > > > >> > > > > > > > > > > I, at least, am in favor of this. I've thought for a while that the > > > ideal > > > > > form of all this is something like: > > > > > > > > > > data TypeRep a -- indexed by a > > > > > > > > > > class Typeable a where > > > > > typeRep :: TypeRep a > > > > > > > > > > data Dynamic = forall a. Dynamic (TypeRep a) a > > > > > > > > > > > > > > > Where, ideally, TypeRep is an indexed type, and you can match on > it to > > > > > refine its argument. Then Typeable just becomes the implicit > version of > > > > > this evidence, for convenience. TypeRep versions of cast would also > > > have to > > > > > be primitive probably (since one can not, a priori, enumerate the > > > diagonal > > > > > of all possible monotypes, now and in the future). > > > > > > > > > > Anyhow, I don't know if this entire interface is or will be > > > implementable > > > > > in GHC (the idea comes from a document about JHC way back, > although I > > > don't > > > > > know if even it implements this), but using Typeable in an > existential > > > > > captures the Dynamic part of it, at least. > > > > > > > > > > Also, I hadn't seen the Tagged version of Typeable before (and > hadn't > > > > > thought of it myself). I expect it's an oversight that this wasn't > the > > > form > > > > > chosen, as it seems superior to me. In fact, it seems like every > > > situation > > > > > where the 0-width Proxy# could be used, Tagged could also be used > > > instead, > > > > > and is automatically 0-width, and has better sharing behavior? > Unless > > > you > > > > > explicitly don't want sharing, that is. > > > > > > > > > > It seems like any relative inconvenience could probably be > alleviated > > > by > > > > > the proxy function in tagged, while keeping the nicer behavior. > > > > > > > > > > -- Dan > > > > > > > > > > _______________________________________________ > > > > > Libraries mailing list > > > > > Libraries at haskell.org > > > > > http://www.haskell.org/mailman/listinfo/libraries > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Libraries mailing list > > > > Libraries at haskell.org > > > > http://www.haskell.org/mailman/listinfo/libraries > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Mar 10 20:49:14 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 10 Mar 2014 20:49:14 +0000 Subject: Data.Dynamic: Any vs existential In-Reply-To: References: <20140310101127.GA7916@sniper> <20140310103510.GA12067@sniper> Message-ID: <59543203684B2244980D7E4057D5FBC1487E1A7A@DB3EX14MBXC306.europe.corp.microsoft.com> It's certainly true that, with the current setup, a monomorphic instance will look like instance Typeable Foo where typeRep# = \_ -> (...something...) :: TypeRep and the optimiser will float the (...something...) to top level. But this is an optimisation, not true by construction. For example, a non-top-level instance might look like instance (Typeable a, Typeable b) => Typeable (a b) where typeRep# = \_ -> mkAppTy (typeRep# (undefined::Proxy a)) (typeRep# (undefined :: Proxy b)) And that in turn will become $dfTyApp = /\a b. \(d1::Typeable a) (d2::Typeable b). \_ -> mkAppTy (d1 a) (d2 b) (I'm missing out some newtypes etc.) Now, will the (d1 a) and (d2 b) be floated outside the \_? Not so certain. It depends on the let-floater. The good thing about the Tagged stuff is that there is no lambda in the first place, so the issue doesn't arise. It's ok if the programming interface is less easy to use; Data.Typeable.typeOf is already a function, not a method. The method is called typeRep#, and is internal. So I think you can go ahead and improve the design. But it's clearly a library-committee decision; I'll just do what you say. Simon From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Dan Doel Sent: 10 March 2014 18:02 To: Roman Cheplyaka Cc: Haskell Libraries Subject: Re: Data.Dynamic: Any vs existential On Mon, Mar 10, 2014 at 6:35 AM, Roman Cheplyaka > wrote: Ok, one reason is that the TypeRep won't be cached in the Dynamic value. Even in GHC 7.8 Typeable is defined as class Typeable a where typeRep# :: Proxy# a -> TypeRep instead of class Typeable a where typeRep :: Tagged a TypeRep Why? Is this an oversight? I talked with Ed about this, and he noted that this might be a false problem. Certainly, the Proxy# is never actually used, so as long as the generated instances are of the form: typeRep# = let tr = ... in \_ -> tr the TypeReps are shared, and are at most a bit of indirection away. Also, how different are (Tagged tr :: Tagged a TypeRep) and ((\_ -> tr) :: Proxy# a -> TypeRep) at a low level? I know the constructor of the former disappears in core, but don't know what specifically happens with 0-width fields like Proxy#. Is the latter slightly less efficient? If so, can the optimizer eliminate the difference for cases like this? -- Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Mon Mar 10 22:25:58 2014 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 10 Mar 2014 18:25:58 -0400 Subject: [core libraries] RE: Data.Dynamic: Any vs existential In-Reply-To: <59543203684B2244980D7E4057D5FBC1487E1A7A@DB3EX14MBXC306.europe.corp.microsoft.com> References: <20140310101127.GA7916@sniper> <20140310103510.GA12067@sniper> <59543203684B2244980D7E4057D5FBC1487E1A7A@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: I'm open to moving Tagged into base with 7.10. Since it'll make the resultant code less likely to break for artificial reasons involving lifting, etc. and as it is mostly an internal API anyways, I don't have much I can say against it. Though that said, my poor tagged package will have had its innards slurped out one module at time over the course of years. ;) -Edward On Mon, Mar 10, 2014 at 4:49 PM, Simon Peyton Jones wrote: > It?s certainly true that, with the current setup, a monomorphic instance > will look like > > > > instance Typeable Foo where > > typeRep# = \_ -> (...something...) :: TypeRep > > > > and the optimiser will float the (...something...) to top level. But this > is an optimisation, not true by construction. For example, a non-top-level > instance might look like > > > > instance (Typeable a, Typeable b) => Typeable (a b) where > > typeRep# = \_ -> mkAppTy (typeRep# (undefined::Proxy a)) > > (typeRep# (undefined :: Proxy b)) > > > > And that in turn will become > > > > $dfTyApp = /\a b. \(d1::Typeable a) (d2::Typeable b). > > \_ -> mkAppTy (d1 a) (d2 b) > > > > (I?m missing out some newtypes etc.) Now, will the (d1 a) and (d2 b) be > floated outside the \_? Not so certain. It depends on the let-floater. > > > > The good thing about the Tagged stuff is that there is no lambda in the > first place, so the issue doesn?t arise. > > > > It?s ok if the programming interface is less easy to use; > Data.Typeable.typeOf is already a function, not a method. The method is > called typeRep#, and is internal. > > > > So I think you can go ahead and improve the design. But it?s clearly a > library-committee decision; I?ll just do what you say. > > > > Simon > > > > *From:* Libraries [mailto:libraries-bounces at haskell.org] *On Behalf Of *Dan > Doel > *Sent:* 10 March 2014 18:02 > *To:* Roman Cheplyaka > *Cc:* Haskell Libraries > > *Subject:* Re: Data.Dynamic: Any vs existential > > > > On Mon, Mar 10, 2014 at 6:35 AM, Roman Cheplyaka wrote: > > Ok, one reason is that the TypeRep won't be cached in the Dynamic value. > Even in GHC 7.8 Typeable is defined as > > class Typeable a where > typeRep# :: Proxy# a -> TypeRep > > instead of > > class Typeable a where > typeRep :: Tagged a TypeRep > > Why? Is this an oversight? > > > > I talked with Ed about this, and he noted that this might be a false > problem. Certainly, the Proxy# is never actually used, so as long as the > generated instances are of the form: > > typeRep# = let tr = ... in \_ -> tr > > the TypeReps are shared, and are at most a bit of indirection away. Also, > how different are (Tagged tr :: Tagged a TypeRep) and ((\_ -> tr) :: Proxy# > a -> TypeRep) at a low level? I know the constructor of the former > disappears in core, but don't know what specifically happens with 0-width > fields like Proxy#. Is the latter slightly less efficient? If so, can the > optimizer eliminate the difference for cases like this? > > -- Dan > > -- > You received this message because you are subscribed to the Google Groups > "haskell-core-libraries" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to haskell-core-libraries+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From haskell at nand.wakku.to Tue Mar 11 01:24:21 2014 From: haskell at nand.wakku.to (Niklas Haas) Date: Tue, 11 Mar 2014 02:24:21 +0100 Subject: [containers] Proposal: Add traverseKeys, traverseKeysWith, traverseKeysMonotonic to Data.Map Message-ID: <20140311022421.GA4339@nanodesu.talocan.mine.nu> Hello all, While programming a specific type of map update I came across a great need for a 'traverseKeys' function. I ended up making it myself but it was still less efficient than it needed to be because my traversal function was actually monotonic. I went ahead and added this along with some variants to Data.Map. > traverseKeys :: (Applicative f, Ord k2) => (k1 -> f k2) -> Map k1 a -> f (Map k2 a) > traverseKeysWith :: (Applicative f, Ord k2) => (a -> a -> a) -> (k1 -> f k2) -> Map k1 a -> f (Map k2 a) > traverseKeysMonotonic :: (Applicative f, Ord k2) => (k1 -> f k2) -> Map k1 a -> f (Map k2 a) A full patch can be found here: https://github.com/nandykins/containers/commit/a8b0ebd57653bc0a309af69d732356e3572c455c Let me know what you think, Discussion period: 2 weeks From stefan at vectorfabrics.com Tue Mar 11 05:08:40 2014 From: stefan at vectorfabrics.com (Stefan Holdermans) Date: Tue, 11 Mar 2014 06:08:40 +0100 Subject: Proposal: add createPipe to base In-Reply-To: <20140310124746.GA11171@matrix.chaos.earth.li> References: <20140310124746.GA11171@matrix.chaos.earth.li> Message-ID: >>> I propose we add it to System.IO. Note that we'd have to copy the 5 lines >>> in System.Posix.IO.createPipe into base as the above implementation would >>> otherwise depend on the unix package. >>> >> +1. I've needed this in the past when working with process, and ended up >> writing POSIX-only code as a result. +1 one from me, with a preference for process over base. Cheers, Stefan From ekmett at gmail.com Tue Mar 11 08:30:52 2014 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 11 Mar 2014 04:30:52 -0400 Subject: [containers] Proposal: Add traverseKeys, traverseKeysWith, traverseKeysMonotonic to Data.Map In-Reply-To: <20140311022421.GA4339@nanodesu.talocan.mine.nu> References: <20140311022421.GA4339@nanodesu.talocan.mine.nu> Message-ID: I have to admit I'm not a huge fan of these functions. The major objections that come to mind: * They can't be made to pass the Traversable/Traversal laws and can't be implemented much more efficiently than the naive 'dump it out to a list and read it back in' approach, so baking them into the library doesn't add much * The names are dreadfully confusing next to combinators like traverseWithKey that *do* pass the laws. * If you use fromDistinctAscList you'll get much of the benefit of the monotonic walk you're doing now. Moreover fromList basically gets almost the same performance as fromDistinctAscList these days. Did you benchmark to see how much the custom traversal helps? Between those concerns I'm currently -1 on adding these. -Edward On Mon, Mar 10, 2014 at 9:24 PM, Niklas Haas wrote: > Hello all, > > While programming a specific type of map update I came across a great > need for a 'traverseKeys' function. I ended up making it myself but it > was still less efficient than it needed to be because my traversal > function was actually monotonic. > > I went ahead and added this along with some variants to Data.Map. > > > traverseKeys :: (Applicative f, Ord k2) => (k1 -> f k2) -> Map k1 a -> f > (Map k2 a) > > traverseKeysWith :: (Applicative f, Ord k2) => (a -> a -> a) -> (k1 -> f > k2) -> Map k1 a -> f (Map k2 a) > > traverseKeysMonotonic :: (Applicative f, Ord k2) => (k1 -> f k2) -> Map > k1 a -> f (Map k2 a) > > A full patch can be found here: > > https://github.com/nandykins/containers/commit/a8b0ebd57653bc0a309af69d732356e3572c455c > > Let me know what you think, > > Discussion period: 2 weeks > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From haskell at nand.wakku.to Tue Mar 11 08:37:01 2014 From: haskell at nand.wakku.to (Niklas Haas) Date: Tue, 11 Mar 2014 09:37:01 +0100 Subject: [containers] Proposal: Add traverseKeys, traverseKeysWith, traverseKeysMonotonic to Data.Map In-Reply-To: References: <20140311022421.GA4339@nanodesu.talocan.mine.nu> Message-ID: <20140311093701.GA29268@nanodesu.talocan.mine.nu> > I have to admit I'm not a huge fan of these functions. The major objections > that come to mind: > > * They can't be made to pass the Traversable/Traversal laws and can't be > implemented much more efficiently than the naive 'dump it out to a list and > read it back in' approach, so baking them into the library doesn't add much > > * The names are dreadfully confusing next to combinators like > traverseWithKey that *do* pass the laws. > > * If you use fromDistinctAscList you'll get much of the benefit of the > monotonic walk you're doing now. Moreover fromList basically gets almost > the same performance as fromDistinctAscList these days. Did you benchmark > to see how much the custom traversal helps? > > Between those concerns I'm currently -1 on adding these. > > -Edward Good point about fromDistinctAscList, I didn't think about that. I haven't gotten round to benchmarking them yet, I'll do that if anybody else expresses interest but otherwise I'm also prepared to let this proposal die. Re: traversal laws, I suppose that would be fair argument for dropping or at least changing the names of 'traverseKeys' and 'traverseKeysWith', though the traversal laws certainly should hold for 'traverseKeysMonotonic'. It may be worth only keeping that version around, perhaps depending on whether or not it results in a significant speed increase over hand-rolling it with fromDistinctAscList. From jwlato at gmail.com Tue Mar 11 08:45:59 2014 From: jwlato at gmail.com (John Lato) Date: Tue, 11 Mar 2014 01:45:59 -0700 Subject: [containers] Proposal: Add traverseKeys, traverseKeysWith, traverseKeysMonotonic to Data.Map In-Reply-To: <20140311093701.GA29268@nanodesu.talocan.mine.nu> References: <20140311022421.GA4339@nanodesu.talocan.mine.nu> <20140311093701.GA29268@nanodesu.talocan.mine.nu> Message-ID: On Tue, Mar 11, 2014 at 1:37 AM, Niklas Haas wrote: > > I have to admit I'm not a huge fan of these functions. The major > objections > > that come to mind: > > > > * They can't be made to pass the Traversable/Traversal laws and can't be > > implemented much more efficiently than the naive 'dump it out to a list > and > > read it back in' approach, so baking them into the library doesn't add > much > > > > * The names are dreadfully confusing next to combinators like > > traverseWithKey that *do* pass the laws. > > > > * If you use fromDistinctAscList you'll get much of the benefit of the > > monotonic walk you're doing now. Moreover fromList basically gets almost > > the same performance as fromDistinctAscList these days. Did you benchmark > > to see how much the custom traversal helps? > > > > Between those concerns I'm currently -1 on adding these. > > > > -Edward > > Good point about fromDistinctAscList, I didn't think about that. > I haven't gotten round to benchmarking them yet, I'll do that if anybody > else expresses interest but otherwise I'm also prepared to let this > proposal die. > > Re: traversal laws, I suppose that would be fair argument for > dropping or at least changing the names of 'traverseKeys' and > 'traverseKeysWith', though the traversal laws certainly should hold for > 'traverseKeysMonotonic'. It may be worth only keeping that version > around, perhaps depending on whether or not it results in a significant > speed increase over hand-rolling it with fromDistinctAscList. I would support adding a slight generalization, `traverseWithKeyMonotonic`, presuming that it is significantly faster than using fromDistinctAscList. John L. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Tue Mar 11 12:38:08 2014 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 11 Mar 2014 08:38:08 -0400 Subject: [containers] Proposal: Add traverseKeys, traverseKeysWith, traverseKeysMonotonic to Data.Map In-Reply-To: References: <20140311022421.GA4339@nanodesu.talocan.mine.nu> <20140311093701.GA29268@nanodesu.talocan.mine.nu> Message-ID: What does it mean to talk about a monotonic function with Applicative side-effects (a -> f b) in this setting? I'm not able to determine how laws for such a beast work. You can reason about just the pure case easily. That is a strict generalization, but the whole point of using it is to string together effects, no? For *some* instances it is positional. e.g. using a ZipList means that for each position in the ZipList generated the function must be monotone. For others it is a global statement. e.g. the list monad to properly be monotone you'd need to consider the maximal element in each result list against the minimal element of the next result list Yes, you can reason it through casewise, by knowing which of the b's in the f's get merged by the particular Applicative, but the fact that you *have*to reason it through casewise without being able to express uniform laws about the operation indicates to me that it may be a less well defined notion than you might at first think. -Edward On Tue, Mar 11, 2014 at 4:45 AM, John Lato wrote: > On Tue, Mar 11, 2014 at 1:37 AM, Niklas Haas wrote: > >> > I have to admit I'm not a huge fan of these functions. The major >> objections >> > that come to mind: >> > >> > * They can't be made to pass the Traversable/Traversal laws and can't be >> > implemented much more efficiently than the naive 'dump it out to a list >> and >> > read it back in' approach, so baking them into the library doesn't add >> much >> > >> > * The names are dreadfully confusing next to combinators like >> > traverseWithKey that *do* pass the laws. >> > >> > * If you use fromDistinctAscList you'll get much of the benefit of the >> > monotonic walk you're doing now. Moreover fromList basically gets almost >> > the same performance as fromDistinctAscList these days. Did you >> benchmark >> > to see how much the custom traversal helps? >> > >> > Between those concerns I'm currently -1 on adding these. >> > >> > -Edward >> >> Good point about fromDistinctAscList, I didn't think about that. >> I haven't gotten round to benchmarking them yet, I'll do that if anybody >> else expresses interest but otherwise I'm also prepared to let this >> proposal die. >> >> Re: traversal laws, I suppose that would be fair argument for >> dropping or at least changing the names of 'traverseKeys' and >> 'traverseKeysWith', though the traversal laws certainly should hold for >> 'traverseKeysMonotonic'. It may be worth only keeping that version >> around, perhaps depending on whether or not it results in a significant >> speed increase over hand-rolling it with fromDistinctAscList. > > > I would support adding a slight generalization, > `traverseWithKeyMonotonic`, presuming that it is significantly faster than > using fromDistinctAscList. > > John L. > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tkn.akio at gmail.com Wed Mar 12 00:02:25 2014 From: tkn.akio at gmail.com (Akio Takano) Date: Wed, 12 Mar 2014 09:02:25 +0900 Subject: [containers] Proposal: Add traverseKeys, traverseKeysWith, traverseKeysMonotonic to Data.Map In-Reply-To: References: <20140311022421.GA4339@nanodesu.talocan.mine.nu> <20140311093701.GA29268@nanodesu.talocan.mine.nu> Message-ID: Hi, On Tue, Mar 11, 2014 at 9:38 PM, Edward Kmett wrote: > What does it mean to talk about a monotonic function with Applicative > side-effects (a -> f b) in this setting? > > I'm not able to determine how laws for such a beast work. Would a definition like the below help? A function (m :: a -> f b) is monotonic iff for all finite (xs :: [a]), the following two expressions are equivalent: isMonotonic <$> traverse (\x -> (x,) <$> m x) xs True <$ traverse (\x -> (x,) <$> m x) xs where isMonotonic :: (Ord a, Ord b) => [(a, b)] -> Bool isMonotonic xs = and $ zipWith (<=) sorted (drop 1 sorted) where sorted = sortBy (compare `on` fst) xs -- Takano Akio From bergey at alum.mit.edu Thu Mar 13 16:43:18 2014 From: bergey at alum.mit.edu (Daniel Bergey) Date: Thu, 13 Mar 2014 16:43:18 +0000 Subject: adoption or NMU for arithmoi Message-ID: <87a9cuf3rt.fsf@chladni.lan> The arithmoi package[1] does not build on GHC 7.8.1, and the maintainer does not appear to be reachable. diagram-contrib[2] depends on arithmoi, which is why I and others have been working on this. Brent reported the build failure on 2013-12-23[3]. Carter Schonwald and I wrote a patch[4] mid-February. After Austin Seipp provided ghc-prim-compat[5], I wrote an new patch[6] using that module. Daniel Fischer, the author of arithmoi, has not replied to either pull request, nor to an email I sent him a week ago today. Unless someone knows other channels by which to reach Daniel Fischer, I'd like to request that someone upload my patched version of arithmoi to Hackage. I'm not sure how this process usually works; are there other steps I should take? Thank you, Daniel Footnotes: [1] http://hackage.haskell.org/package/arithmoi [2] http://hackage.haskell.org/package/diagrams-contrib [3] https://bitbucket.org/dafis/arithmoi/issue/4/equality-primop-type-error-under-base-47 [4] https://bitbucket.org/carter/arithmoi/ [5] https://github.com/thoughtpolice/ghc-prim-compat [6] https://bitbucket.org/bergey/arithmoi/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From daniel.is.fischer at googlemail.com Thu Mar 13 17:14:24 2014 From: daniel.is.fischer at googlemail.com (Daniel Fischer) Date: Thu, 13 Mar 2014 18:14:24 +0100 Subject: adoption or NMU for arithmoi In-Reply-To: <87a9cuf3rt.fsf@chladni.lan> References: <87a9cuf3rt.fsf@chladni.lan> Message-ID: <11072470.yTvuZRk8rS@linux-hpeb.site> On Thursday 13 March 2014, 16:43:18, Daniel Bergey wrote: > The arithmoi package[1] does not build on GHC 7.8.1, and the maintainer > does not appear to be reachable. diagram-contrib[2] depends on > arithmoi, which is why I and others have been working on this. Sorry, I'm going through a phase of extreme lack of drive and energy to do anything programming related. (And the 7.8 release was always still not yet quite imminent, so I pushed it away for another day...) Let me see if I can pull and test today. And if I figure out how, I could add Brent or you to the list of people allowed to upload on Hackage. Many thanks to Brent, Carter and you for your efforts, Daniel From carter.schonwald at gmail.com Thu Mar 13 17:40:48 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 13 Mar 2014 13:40:48 -0400 Subject: adoption or NMU for arithmoi In-Reply-To: <11072470.yTvuZRk8rS@linux-hpeb.site> References: <87a9cuf3rt.fsf@chladni.lan> <11072470.yTvuZRk8rS@linux-hpeb.site> Message-ID: dan, thanks for surfacing. i can (with your permission, using my hackage trustee powers) add myself or brent or dan to the arithmoi package uploaders group. I do think arithmoi does need a benchmarking suite to justify some of the current code it has, but thats a different project for another day :) On Thu, Mar 13, 2014 at 1:14 PM, Daniel Fischer < daniel.is.fischer at googlemail.com> wrote: > On Thursday 13 March 2014, 16:43:18, Daniel Bergey wrote: > > The arithmoi package[1] does not build on GHC 7.8.1, and the maintainer > > does not appear to be reachable. diagram-contrib[2] depends on > > arithmoi, which is why I and others have been working on this. > > Sorry, I'm going through a phase of extreme lack of drive and energy to do > anything programming related. (And the 7.8 release was always still not yet > quite imminent, so I pushed it away for another day...) > > Let me see if I can pull and test today. And if I figure out how, I could > add > Brent or you to the list of people allowed to upload on Hackage. > > Many thanks to Brent, Carter and you for your efforts, > Daniel > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bergey at alum.mit.edu Thu Mar 13 18:32:41 2014 From: bergey at alum.mit.edu (Daniel Bergey) Date: Thu, 13 Mar 2014 18:32:41 +0000 Subject: adoption or NMU for arithmoi In-Reply-To: <11072470.yTvuZRk8rS@linux-hpeb.site> References: <87a9cuf3rt.fsf@chladni.lan> <11072470.yTvuZRk8rS@linux-hpeb.site> Message-ID: <877g7yeypi.fsf@chladni.lan> On 2014-03-13 at 17:14, Daniel Fischer wrote: > On Thursday 13 March 2014, 16:43:18, Daniel Bergey wrote: >> The arithmoi package[1] does not build on GHC 7.8.1, and the maintainer >> does not appear to be reachable. diagram-contrib[2] depends on >> arithmoi, which is why I and others have been working on this. > > Sorry, I'm going through a phase of extreme lack of drive and energy to do > anything programming related. (And the 7.8 release was always still not yet > quite imminent, so I pushed it away for another day...) I know how that is. > Let me see if I can pull and test today. And if I figure out how, I could add > Brent or you to the list of people allowed to upload on Hackage. Sounds great. Thank you. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From eir at cis.upenn.edu Thu Mar 13 18:41:42 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Thu, 13 Mar 2014 14:41:42 -0400 Subject: We need to add role annotations for 7.8 Message-ID: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> Hi libraries, Johan, Edward, tl;dr: We really should add role annotations to the libraries that ship with GHC 7.8. In November, I sent this out: http://www.haskell.org/pipermail/libraries/2013-November/021707.html It got several good responses. Some time later, Joachim and I noticed that no action was taken, so we made a bug report, #8718, with a milestone of 7.8.1. I believe we both assumed that would take care of it. However, Simon PJ and I were surprised earlier this week to discover that Map and Set still do not have role annotations. Perhaps the GHC Trac isn't the right place for libraries issues, but posting here didn't quite work, so that seemed like the logical next step. In any case, now that we have the ability to prevent abuses of datatypes like Map and Set through erroneous use of GeneralizedNewtypeDeriving (and the new `coerce`), we should take advantage of this fact for 7.8. See my earlier email for a full explanation. Possibly folks' unfamiliarity with roles are in part to blame for not adding these role annotations. I am happy to help sort out what goes where. But, I need to work with someone with an intimate familiarity with the libraries themselves to help determine what the correct annotations are. For example, Map's first parameter should be nominal (its Ord instance is very relevant) but its second should be representational (there are no particular invariants related to the values of a map). Map is straightforward in this respect; other types probably aren't. Furthermore, I don't have anywhere near a complete list of what even needs attention. (It should be any type abstractly exported from a library.) Can someone help? I've included Johan as the most recent uploader of `containers` and Edward as the head of the core libraries committee. Thanks! Richard From johan.tibell at gmail.com Thu Mar 13 18:49:11 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 13 Mar 2014 19:49:11 +0100 Subject: We need to add role annotations for 7.8 In-Reply-To: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> Message-ID: If you send a pull request for containers I'll merge it and make a release. It needs to be backwards compatible with the last 3 major GHC releases. I think we need to bump the minor version number so people can reliable write dependency bounds to depend on the role being there (as that might be the difference between code compiling or not). Here's a guess which params should be representational: Map k v -- k: nominal, v: represententional Set a -- k: nominal IntMap v -- v: represententional Sequence a -- a: represententional Tree a -- a: represententional On Thu, Mar 13, 2014 at 7:41 PM, Richard Eisenberg wrote: > Hi libraries, Johan, Edward, > > tl;dr: We really should add role annotations to the libraries that ship > with GHC 7.8. > > In November, I sent this out: > http://www.haskell.org/pipermail/libraries/2013-November/021707.html > It got several good responses. Some time later, Joachim and I noticed that > no action was taken, so we made a bug report, #8718, with a milestone of > 7.8.1. I believe we both assumed that would take care of it. However, Simon > PJ and I were surprised earlier this week to discover that Map and Set > still do not have role annotations. Perhaps the GHC Trac isn't the right > place for libraries issues, but posting here didn't quite work, so that > seemed like the logical next step. > > In any case, now that we have the ability to prevent abuses of datatypes > like Map and Set through erroneous use of GeneralizedNewtypeDeriving (and > the new `coerce`), we should take advantage of this fact for 7.8. See my > earlier email for a full explanation. > > Possibly folks' unfamiliarity with roles are in part to blame for not > adding these role annotations. I am happy to help sort out what goes where. > But, I need to work with someone with an intimate familiarity with the > libraries themselves to help determine what the correct annotations are. > For example, Map's first parameter should be nominal (its Ord instance is > very relevant) but its second should be representational (there are no > particular invariants related to the values of a map). Map is > straightforward in this respect; other types probably aren't. Furthermore, > I don't have anywhere near a complete list of what even needs attention. > (It should be any type abstractly exported from a library.) > > Can someone help? I've included Johan as the most recent uploader of > `containers` and Edward as the head of the core libraries committee. > > Thanks! > Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Thu Mar 13 18:50:17 2014 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 13 Mar 2014 14:50:17 -0400 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> Message-ID: That looks correct to me. Analogously for HashMap in unordered-containers of course. On Thu, Mar 13, 2014 at 2:49 PM, Johan Tibell wrote: > If you send a pull request for containers I'll merge it and make a > release. It needs to be backwards compatible with the last 3 major GHC > releases. I think we need to bump the minor version number so people can > reliable write dependency bounds to depend on the role being there (as that > might be the difference between code compiling or not). > > Here's a guess which params should be representational: > > Map k v -- k: nominal, v: represententional > Set a -- k: nominal > IntMap v -- v: represententional > Sequence a -- a: represententional > Tree a -- a: represententional > > > On Thu, Mar 13, 2014 at 7:41 PM, Richard Eisenberg wrote: > >> Hi libraries, Johan, Edward, >> >> tl;dr: We really should add role annotations to the libraries that ship >> with GHC 7.8. >> >> In November, I sent this out: >> http://www.haskell.org/pipermail/libraries/2013-November/021707.html >> It got several good responses. Some time later, Joachim and I noticed >> that no action was taken, so we made a bug report, #8718, with a milestone >> of 7.8.1. I believe we both assumed that would take care of it. However, >> Simon PJ and I were surprised earlier this week to discover that Map and >> Set still do not have role annotations. Perhaps the GHC Trac isn't the >> right place for libraries issues, but posting here didn't quite work, so >> that seemed like the logical next step. >> >> In any case, now that we have the ability to prevent abuses of datatypes >> like Map and Set through erroneous use of GeneralizedNewtypeDeriving (and >> the new `coerce`), we should take advantage of this fact for 7.8. See my >> earlier email for a full explanation. >> >> Possibly folks' unfamiliarity with roles are in part to blame for not >> adding these role annotations. I am happy to help sort out what goes where. >> But, I need to work with someone with an intimate familiarity with the >> libraries themselves to help determine what the correct annotations are. >> For example, Map's first parameter should be nominal (its Ord instance is >> very relevant) but its second should be representational (there are no >> particular invariants related to the values of a map). Map is >> straightforward in this respect; other types probably aren't. Furthermore, >> I don't have anywhere near a complete list of what even needs attention. >> (It should be any type abstractly exported from a library.) >> >> Can someone help? I've included Johan as the most recent uploader of >> `containers` and Edward as the head of the core libraries committee. >> >> Thanks! >> Richard > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Mar 13 18:51:00 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 13 Mar 2014 14:51:00 -0400 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> Message-ID: it'd just need some CPP to maintain compat right? We need it for vector and friends too right? On Thu, Mar 13, 2014 at 2:49 PM, Johan Tibell wrote: > If you send a pull request for containers I'll merge it and make a > release. It needs to be backwards compatible with the last 3 major GHC > releases. I think we need to bump the minor version number so people can > reliable write dependency bounds to depend on the role being there (as that > might be the difference between code compiling or not). > > Here's a guess which params should be representational: > > Map k v -- k: nominal, v: represententional > Set a -- k: nominal > IntMap v -- v: represententional > Sequence a -- a: represententional > Tree a -- a: represententional > > > On Thu, Mar 13, 2014 at 7:41 PM, Richard Eisenberg wrote: > >> Hi libraries, Johan, Edward, >> >> tl;dr: We really should add role annotations to the libraries that ship >> with GHC 7.8. >> >> In November, I sent this out: >> http://www.haskell.org/pipermail/libraries/2013-November/021707.html >> It got several good responses. Some time later, Joachim and I noticed >> that no action was taken, so we made a bug report, #8718, with a milestone >> of 7.8.1. I believe we both assumed that would take care of it. However, >> Simon PJ and I were surprised earlier this week to discover that Map and >> Set still do not have role annotations. Perhaps the GHC Trac isn't the >> right place for libraries issues, but posting here didn't quite work, so >> that seemed like the logical next step. >> >> In any case, now that we have the ability to prevent abuses of datatypes >> like Map and Set through erroneous use of GeneralizedNewtypeDeriving (and >> the new `coerce`), we should take advantage of this fact for 7.8. See my >> earlier email for a full explanation. >> >> Possibly folks' unfamiliarity with roles are in part to blame for not >> adding these role annotations. I am happy to help sort out what goes where. >> But, I need to work with someone with an intimate familiarity with the >> libraries themselves to help determine what the correct annotations are. >> For example, Map's first parameter should be nominal (its Ord instance is >> very relevant) but its second should be representational (there are no >> particular invariants related to the values of a map). Map is >> straightforward in this respect; other types probably aren't. Furthermore, >> I don't have anywhere near a complete list of what even needs attention. >> (It should be any type abstractly exported from a library.) >> >> Can someone help? I've included Johan as the most recent uploader of >> `containers` and Edward as the head of the core libraries committee. >> >> Thanks! >> Richard > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Thu Mar 13 18:51:33 2014 From: austin at well-typed.com (Austin Seipp) Date: Thu, 13 Mar 2014 13:51:33 -0500 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> Message-ID: We were talking about this just this second in IRC. We also need to double-check vector as well. (After that we can also fix https://ghc.haskell.org/trac/ghc/ticket/8767, which I mentioned on IRC earlier.) On Thu, Mar 13, 2014 at 1:50 PM, Edward Kmett wrote: > That looks correct to me. Analogously for HashMap in unordered-containers of > course. > > > On Thu, Mar 13, 2014 at 2:49 PM, Johan Tibell > wrote: >> >> If you send a pull request for containers I'll merge it and make a >> release. It needs to be backwards compatible with the last 3 major GHC >> releases. I think we need to bump the minor version number so people can >> reliable write dependency bounds to depend on the role being there (as that >> might be the difference between code compiling or not). >> >> Here's a guess which params should be representational: >> >> Map k v -- k: nominal, v: represententional >> Set a -- k: nominal >> IntMap v -- v: represententional >> Sequence a -- a: represententional >> Tree a -- a: represententional >> >> >> On Thu, Mar 13, 2014 at 7:41 PM, Richard Eisenberg >> wrote: >>> >>> Hi libraries, Johan, Edward, >>> >>> tl;dr: We really should add role annotations to the libraries that ship >>> with GHC 7.8. >>> >>> In November, I sent this out: >>> http://www.haskell.org/pipermail/libraries/2013-November/021707.html >>> It got several good responses. Some time later, Joachim and I noticed >>> that no action was taken, so we made a bug report, #8718, with a milestone >>> of 7.8.1. I believe we both assumed that would take care of it. However, >>> Simon PJ and I were surprised earlier this week to discover that Map and Set >>> still do not have role annotations. Perhaps the GHC Trac isn't the right >>> place for libraries issues, but posting here didn't quite work, so that >>> seemed like the logical next step. >>> >>> In any case, now that we have the ability to prevent abuses of datatypes >>> like Map and Set through erroneous use of GeneralizedNewtypeDeriving (and >>> the new `coerce`), we should take advantage of this fact for 7.8. See my >>> earlier email for a full explanation. >>> >>> Possibly folks' unfamiliarity with roles are in part to blame for not >>> adding these role annotations. I am happy to help sort out what goes where. >>> But, I need to work with someone with an intimate familiarity with the >>> libraries themselves to help determine what the correct annotations are. For >>> example, Map's first parameter should be nominal (its Ord instance is very >>> relevant) but its second should be representational (there are no particular >>> invariants related to the values of a map). Map is straightforward in this >>> respect; other types probably aren't. Furthermore, I don't have anywhere >>> near a complete list of what even needs attention. (It should be any type >>> abstractly exported from a library.) >>> >>> Can someone help? I've included Johan as the most recent uploader of >>> `containers` and Edward as the head of the core libraries committee. >>> >>> Thanks! >>> Richard >> >> > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From ekmett at gmail.com Thu Mar 13 18:52:21 2014 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 13 Mar 2014 14:52:21 -0400 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> Message-ID: Yep. The role annotation should be CPP guarded. On Thu, Mar 13, 2014 at 2:51 PM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > it'd just need some CPP to maintain compat right? > We need it for vector and friends too right? > > > On Thu, Mar 13, 2014 at 2:49 PM, Johan Tibell wrote: > >> If you send a pull request for containers I'll merge it and make a >> release. It needs to be backwards compatible with the last 3 major GHC >> releases. I think we need to bump the minor version number so people can >> reliable write dependency bounds to depend on the role being there (as that >> might be the difference between code compiling or not). >> >> Here's a guess which params should be representational: >> >> Map k v -- k: nominal, v: represententional >> Set a -- k: nominal >> IntMap v -- v: represententional >> Sequence a -- a: represententional >> Tree a -- a: represententional >> >> >> On Thu, Mar 13, 2014 at 7:41 PM, Richard Eisenberg wrote: >> >>> Hi libraries, Johan, Edward, >>> >>> tl;dr: We really should add role annotations to the libraries that ship >>> with GHC 7.8. >>> >>> In November, I sent this out: >>> http://www.haskell.org/pipermail/libraries/2013-November/021707.html >>> It got several good responses. Some time later, Joachim and I noticed >>> that no action was taken, so we made a bug report, #8718, with a milestone >>> of 7.8.1. I believe we both assumed that would take care of it. However, >>> Simon PJ and I were surprised earlier this week to discover that Map and >>> Set still do not have role annotations. Perhaps the GHC Trac isn't the >>> right place for libraries issues, but posting here didn't quite work, so >>> that seemed like the logical next step. >>> >>> In any case, now that we have the ability to prevent abuses of datatypes >>> like Map and Set through erroneous use of GeneralizedNewtypeDeriving (and >>> the new `coerce`), we should take advantage of this fact for 7.8. See my >>> earlier email for a full explanation. >>> >>> Possibly folks' unfamiliarity with roles are in part to blame for not >>> adding these role annotations. I am happy to help sort out what goes where. >>> But, I need to work with someone with an intimate familiarity with the >>> libraries themselves to help determine what the correct annotations are. >>> For example, Map's first parameter should be nominal (its Ord instance is >>> very relevant) but its second should be representational (there are no >>> particular invariants related to the values of a map). Map is >>> straightforward in this respect; other types probably aren't. Furthermore, >>> I don't have anywhere near a complete list of what even needs attention. >>> (It should be any type abstractly exported from a library.) >>> >>> Can someone help? I've included Johan as the most recent uploader of >>> `containers` and Edward as the head of the core libraries committee. >>> >>> Thanks! >>> Richard >> >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> >> > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Thu Mar 13 18:53:06 2014 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 13 Mar 2014 14:53:06 -0400 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> Message-ID: Note with vector, Data.Vector.Vector is has a representational arg, but all the other vector types have nominal args. On Thu, Mar 13, 2014 at 2:52 PM, Edward Kmett wrote: > Yep. > > The role annotation should be CPP guarded. > > > On Thu, Mar 13, 2014 at 2:51 PM, Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >> it'd just need some CPP to maintain compat right? >> We need it for vector and friends too right? >> >> >> On Thu, Mar 13, 2014 at 2:49 PM, Johan Tibell wrote: >> >>> If you send a pull request for containers I'll merge it and make a >>> release. It needs to be backwards compatible with the last 3 major GHC >>> releases. I think we need to bump the minor version number so people can >>> reliable write dependency bounds to depend on the role being there (as that >>> might be the difference between code compiling or not). >>> >>> Here's a guess which params should be representational: >>> >>> Map k v -- k: nominal, v: represententional >>> Set a -- k: nominal >>> IntMap v -- v: represententional >>> Sequence a -- a: represententional >>> Tree a -- a: represententional >>> >>> >>> On Thu, Mar 13, 2014 at 7:41 PM, Richard Eisenberg wrote: >>> >>>> Hi libraries, Johan, Edward, >>>> >>>> tl;dr: We really should add role annotations to the libraries that ship >>>> with GHC 7.8. >>>> >>>> In November, I sent this out: >>>> http://www.haskell.org/pipermail/libraries/2013-November/021707.html >>>> It got several good responses. Some time later, Joachim and I noticed >>>> that no action was taken, so we made a bug report, #8718, with a milestone >>>> of 7.8.1. I believe we both assumed that would take care of it. However, >>>> Simon PJ and I were surprised earlier this week to discover that Map and >>>> Set still do not have role annotations. Perhaps the GHC Trac isn't the >>>> right place for libraries issues, but posting here didn't quite work, so >>>> that seemed like the logical next step. >>>> >>>> In any case, now that we have the ability to prevent abuses of >>>> datatypes like Map and Set through erroneous use of >>>> GeneralizedNewtypeDeriving (and the new `coerce`), we should take advantage >>>> of this fact for 7.8. See my earlier email for a full explanation. >>>> >>>> Possibly folks' unfamiliarity with roles are in part to blame for not >>>> adding these role annotations. I am happy to help sort out what goes where. >>>> But, I need to work with someone with an intimate familiarity with the >>>> libraries themselves to help determine what the correct annotations are. >>>> For example, Map's first parameter should be nominal (its Ord instance is >>>> very relevant) but its second should be representational (there are no >>>> particular invariants related to the values of a map). Map is >>>> straightforward in this respect; other types probably aren't. Furthermore, >>>> I don't have anywhere near a complete list of what even needs attention. >>>> (It should be any type abstractly exported from a library.) >>>> >>>> Can someone help? I've included Johan as the most recent uploader of >>>> `containers` and Edward as the head of the core libraries committee. >>>> >>>> Thanks! >>>> Richard >>> >>> >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://www.haskell.org/mailman/listinfo/libraries >>> >>> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Thu Mar 13 18:54:11 2014 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 13 Mar 2014 14:54:11 -0400 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> Message-ID: Interestingly I guess the s in `ST s` and `MVector s a` is nominal despite being used as a deliberate phantom. =) On Thu, Mar 13, 2014 at 2:53 PM, Edward Kmett wrote: > Note with vector, Data.Vector.Vector is has a representational arg, but > all the other vector types have nominal args. > > > On Thu, Mar 13, 2014 at 2:52 PM, Edward Kmett wrote: > >> Yep. >> >> The role annotation should be CPP guarded. >> >> >> On Thu, Mar 13, 2014 at 2:51 PM, Carter Schonwald < >> carter.schonwald at gmail.com> wrote: >> >>> it'd just need some CPP to maintain compat right? >>> We need it for vector and friends too right? >>> >>> >>> On Thu, Mar 13, 2014 at 2:49 PM, Johan Tibell wrote: >>> >>>> If you send a pull request for containers I'll merge it and make a >>>> release. It needs to be backwards compatible with the last 3 major GHC >>>> releases. I think we need to bump the minor version number so people can >>>> reliable write dependency bounds to depend on the role being there (as that >>>> might be the difference between code compiling or not). >>>> >>>> Here's a guess which params should be representational: >>>> >>>> Map k v -- k: nominal, v: represententional >>>> Set a -- k: nominal >>>> IntMap v -- v: represententional >>>> Sequence a -- a: represententional >>>> Tree a -- a: represententional >>>> >>>> >>>> On Thu, Mar 13, 2014 at 7:41 PM, Richard Eisenberg wrote: >>>> >>>>> Hi libraries, Johan, Edward, >>>>> >>>>> tl;dr: We really should add role annotations to the libraries that >>>>> ship with GHC 7.8. >>>>> >>>>> In November, I sent this out: >>>>> http://www.haskell.org/pipermail/libraries/2013-November/021707.html >>>>> It got several good responses. Some time later, Joachim and I noticed >>>>> that no action was taken, so we made a bug report, #8718, with a milestone >>>>> of 7.8.1. I believe we both assumed that would take care of it. However, >>>>> Simon PJ and I were surprised earlier this week to discover that Map and >>>>> Set still do not have role annotations. Perhaps the GHC Trac isn't the >>>>> right place for libraries issues, but posting here didn't quite work, so >>>>> that seemed like the logical next step. >>>>> >>>>> In any case, now that we have the ability to prevent abuses of >>>>> datatypes like Map and Set through erroneous use of >>>>> GeneralizedNewtypeDeriving (and the new `coerce`), we should take advantage >>>>> of this fact for 7.8. See my earlier email for a full explanation. >>>>> >>>>> Possibly folks' unfamiliarity with roles are in part to blame for not >>>>> adding these role annotations. I am happy to help sort out what goes where. >>>>> But, I need to work with someone with an intimate familiarity with the >>>>> libraries themselves to help determine what the correct annotations are. >>>>> For example, Map's first parameter should be nominal (its Ord instance is >>>>> very relevant) but its second should be representational (there are no >>>>> particular invariants related to the values of a map). Map is >>>>> straightforward in this respect; other types probably aren't. Furthermore, >>>>> I don't have anywhere near a complete list of what even needs attention. >>>>> (It should be any type abstractly exported from a library.) >>>>> >>>>> Can someone help? I've included Johan as the most recent uploader of >>>>> `containers` and Edward as the head of the core libraries committee. >>>>> >>>>> Thanks! >>>>> Richard >>>> >>>> >>>> >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries at haskell.org >>>> http://www.haskell.org/mailman/listinfo/libraries >>>> >>>> >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://www.haskell.org/mailman/listinfo/libraries >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Thu Mar 13 20:11:20 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Thu, 13 Mar 2014 16:11:20 -0400 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> Message-ID: Patch attached. I only needed Map and Set -- the others are inferred. I guess this was simpler than I thought. :) Richard On Mar 13, 2014, at 2:49 PM, Johan Tibell wrote: > If you send a pull request for containers I'll merge it and make a release. It needs to be backwards compatible with the last 3 major GHC releases. I think we need to bump the minor version number so people can reliable write dependency bounds to depend on the role being there (as that might be the difference between code compiling or not). > > Here's a guess which params should be representational: > > Map k v -- k: nominal, v: represententional > Set a -- k: nominal > IntMap v -- v: represententional > Sequence a -- a: represententional > Tree a -- a: represententional > > > On Thu, Mar 13, 2014 at 7:41 PM, Richard Eisenberg wrote: > Hi libraries, Johan, Edward, > > tl;dr: We really should add role annotations to the libraries that ship with GHC 7.8. > > In November, I sent this out: http://www.haskell.org/pipermail/libraries/2013-November/021707.html > It got several good responses. Some time later, Joachim and I noticed that no action was taken, so we made a bug report, #8718, with a milestone of 7.8.1. I believe we both assumed that would take care of it. However, Simon PJ and I were surprised earlier this week to discover that Map and Set still do not have role annotations. Perhaps the GHC Trac isn't the right place for libraries issues, but posting here didn't quite work, so that seemed like the logical next step. > > In any case, now that we have the ability to prevent abuses of datatypes like Map and Set through erroneous use of GeneralizedNewtypeDeriving (and the new `coerce`), we should take advantage of this fact for 7.8. See my earlier email for a full explanation. > > Possibly folks' unfamiliarity with roles are in part to blame for not adding these role annotations. I am happy to help sort out what goes where. But, I need to work with someone with an intimate familiarity with the libraries themselves to help determine what the correct annotations are. For example, Map's first parameter should be nominal (its Ord instance is very relevant) but its second should be representational (there are no particular invariants related to the values of a map). Map is straightforward in this respect; other types probably aren't. Furthermore, I don't have anywhere near a complete list of what even needs attention. (It should be any type abstractly exported from a library.) > > Can someone help? I've included Johan as the most recent uploader of `containers` and Edward as the head of the core libraries committee. > > Thanks! > Richard > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-role-annotations-to-Map-and-Set.patch Type: application/octet-stream Size: 1582 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Thu Mar 13 20:12:54 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Thu, 13 Mar 2014 16:12:54 -0400 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> Message-ID: <70B4F61C-0DB2-488F-ADED-6CF5A031672A@cis.upenn.edu> This is not shipped with GHC. Johan, as the maintainer of unordered-containers, would you be able to use my patch to be able to do this on your end? Thanks, Richard On Mar 13, 2014, at 2:50 PM, Edward Kmett wrote: > That looks correct to me. Analogously for HashMap in unordered-containers of course. > > > On Thu, Mar 13, 2014 at 2:49 PM, Johan Tibell wrote: > If you send a pull request for containers I'll merge it and make a release. It needs to be backwards compatible with the last 3 major GHC releases. I think we need to bump the minor version number so people can reliable write dependency bounds to depend on the role being there (as that might be the difference between code compiling or not). > > Here's a guess which params should be representational: > > Map k v -- k: nominal, v: represententional > Set a -- k: nominal > IntMap v -- v: represententional > Sequence a -- a: represententional > Tree a -- a: represententional > > > On Thu, Mar 13, 2014 at 7:41 PM, Richard Eisenberg wrote: > Hi libraries, Johan, Edward, > > tl;dr: We really should add role annotations to the libraries that ship with GHC 7.8. > > In November, I sent this out: http://www.haskell.org/pipermail/libraries/2013-November/021707.html > It got several good responses. Some time later, Joachim and I noticed that no action was taken, so we made a bug report, #8718, with a milestone of 7.8.1. I believe we both assumed that would take care of it. However, Simon PJ and I were surprised earlier this week to discover that Map and Set still do not have role annotations. Perhaps the GHC Trac isn't the right place for libraries issues, but posting here didn't quite work, so that seemed like the logical next step. > > In any case, now that we have the ability to prevent abuses of datatypes like Map and Set through erroneous use of GeneralizedNewtypeDeriving (and the new `coerce`), we should take advantage of this fact for 7.8. See my earlier email for a full explanation. > > Possibly folks' unfamiliarity with roles are in part to blame for not adding these role annotations. I am happy to help sort out what goes where. But, I need to work with someone with an intimate familiarity with the libraries themselves to help determine what the correct annotations are. For example, Map's first parameter should be nominal (its Ord instance is very relevant) but its second should be representational (there are no particular invariants related to the values of a map). Map is straightforward in this respect; other types probably aren't. Furthermore, I don't have anywhere near a complete list of what even needs attention. (It should be any type abstractly exported from a library.) > > Can someone help? I've included Johan as the most recent uploader of `containers` and Edward as the head of the core libraries committee. > > Thanks! > Richard > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Thu Mar 13 20:16:49 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Thu, 13 Mar 2014 16:16:49 -0400 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> Message-ID: <5D7A60AB-0397-4C5E-A5E7-80861422AAF4@cis.upenn.edu> I don't know my way around `vector` at all -- not even sure where datatypes are declared. If you can tell me what "the other vector types" are, I suppose I can make the patch. Thanks, Richard On Mar 13, 2014, at 2:53 PM, Edward Kmett wrote: > Note with vector, Data.Vector.Vector is has a representational arg, but all the other vector types have nominal args. > > > On Thu, Mar 13, 2014 at 2:52 PM, Edward Kmett wrote: > Yep. > > The role annotation should be CPP guarded. > > > On Thu, Mar 13, 2014 at 2:51 PM, Carter Schonwald wrote: > it'd just need some CPP to maintain compat right? > We need it for vector and friends too right? > > > On Thu, Mar 13, 2014 at 2:49 PM, Johan Tibell wrote: > If you send a pull request for containers I'll merge it and make a release. It needs to be backwards compatible with the last 3 major GHC releases. I think we need to bump the minor version number so people can reliable write dependency bounds to depend on the role being there (as that might be the difference between code compiling or not). > > Here's a guess which params should be representational: > > Map k v -- k: nominal, v: represententional > Set a -- k: nominal > IntMap v -- v: represententional > Sequence a -- a: represententional > Tree a -- a: represententional > > > On Thu, Mar 13, 2014 at 7:41 PM, Richard Eisenberg wrote: > Hi libraries, Johan, Edward, > > tl;dr: We really should add role annotations to the libraries that ship with GHC 7.8. > > In November, I sent this out: http://www.haskell.org/pipermail/libraries/2013-November/021707.html > It got several good responses. Some time later, Joachim and I noticed that no action was taken, so we made a bug report, #8718, with a milestone of 7.8.1. I believe we both assumed that would take care of it. However, Simon PJ and I were surprised earlier this week to discover that Map and Set still do not have role annotations. Perhaps the GHC Trac isn't the right place for libraries issues, but posting here didn't quite work, so that seemed like the logical next step. > > In any case, now that we have the ability to prevent abuses of datatypes like Map and Set through erroneous use of GeneralizedNewtypeDeriving (and the new `coerce`), we should take advantage of this fact for 7.8. See my earlier email for a full explanation. > > Possibly folks' unfamiliarity with roles are in part to blame for not adding these role annotations. I am happy to help sort out what goes where. But, I need to work with someone with an intimate familiarity with the libraries themselves to help determine what the correct annotations are. For example, Map's first parameter should be nominal (its Ord instance is very relevant) but its second should be representational (there are no particular invariants related to the values of a map). Map is straightforward in this respect; other types probably aren't. Furthermore, I don't have anywhere near a complete list of what even needs attention. (It should be any type abstractly exported from a library.) > > Can someone help? I've included Johan as the most recent uploader of `containers` and Edward as the head of the core libraries committee. > > Thanks! > Richard > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Thu Mar 13 20:17:36 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Thu, 13 Mar 2014 16:17:36 -0400 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> Message-ID: <4C7389AA-E195-4032-846A-4F7A5E23062B@cis.upenn.edu> This one we get for free. State#'s parameter is nominal (it's declared within GHC and I made that change when I did all the core role stuff), so that role gets inherited throughout. Richard On Mar 13, 2014, at 2:54 PM, Edward Kmett wrote: > Interestingly I guess the s in `ST s` and `MVector s a` is nominal despite being used as a deliberate phantom. =) > > > On Thu, Mar 13, 2014 at 2:53 PM, Edward Kmett wrote: > Note with vector, Data.Vector.Vector is has a representational arg, but all the other vector types have nominal args. > > > On Thu, Mar 13, 2014 at 2:52 PM, Edward Kmett wrote: > Yep. > > The role annotation should be CPP guarded. > > > On Thu, Mar 13, 2014 at 2:51 PM, Carter Schonwald wrote: > it'd just need some CPP to maintain compat right? > We need it for vector and friends too right? > > > On Thu, Mar 13, 2014 at 2:49 PM, Johan Tibell wrote: > If you send a pull request for containers I'll merge it and make a release. It needs to be backwards compatible with the last 3 major GHC releases. I think we need to bump the minor version number so people can reliable write dependency bounds to depend on the role being there (as that might be the difference between code compiling or not). > > Here's a guess which params should be representational: > > Map k v -- k: nominal, v: represententional > Set a -- k: nominal > IntMap v -- v: represententional > Sequence a -- a: represententional > Tree a -- a: represententional > > > On Thu, Mar 13, 2014 at 7:41 PM, Richard Eisenberg wrote: > Hi libraries, Johan, Edward, > > tl;dr: We really should add role annotations to the libraries that ship with GHC 7.8. > > In November, I sent this out: http://www.haskell.org/pipermail/libraries/2013-November/021707.html > It got several good responses. Some time later, Joachim and I noticed that no action was taken, so we made a bug report, #8718, with a milestone of 7.8.1. I believe we both assumed that would take care of it. However, Simon PJ and I were surprised earlier this week to discover that Map and Set still do not have role annotations. Perhaps the GHC Trac isn't the right place for libraries issues, but posting here didn't quite work, so that seemed like the logical next step. > > In any case, now that we have the ability to prevent abuses of datatypes like Map and Set through erroneous use of GeneralizedNewtypeDeriving (and the new `coerce`), we should take advantage of this fact for 7.8. See my earlier email for a full explanation. > > Possibly folks' unfamiliarity with roles are in part to blame for not adding these role annotations. I am happy to help sort out what goes where. But, I need to work with someone with an intimate familiarity with the libraries themselves to help determine what the correct annotations are. For example, Map's first parameter should be nominal (its Ord instance is very relevant) but its second should be representational (there are no particular invariants related to the values of a map). Map is straightforward in this respect; other types probably aren't. Furthermore, I don't have anywhere near a complete list of what even needs attention. (It should be any type abstractly exported from a library.) > > Can someone help? I've included Johan as the most recent uploader of `containers` and Edward as the head of the core libraries committee. > > Thanks! > Richard > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Thu Mar 13 20:20:07 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 13 Mar 2014 21:20:07 +0100 Subject: We need to add role annotations for 7.8 In-Reply-To: <70B4F61C-0DB2-488F-ADED-6CF5A031672A@cis.upenn.edu> References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <70B4F61C-0DB2-488F-ADED-6CF5A031672A@cis.upenn.edu> Message-ID: I get around to it next time I make a release of unordered-containers. Filed https://github.com/tibbe/unordered-containers/issues/73 so I don't forget. On Thu, Mar 13, 2014 at 9:12 PM, Richard Eisenberg wrote: > This is not shipped with GHC. Johan, as the maintainer of > unordered-containers, would you be able to use my patch to be able to do > this on your end? > > Thanks, > Richard > > On Mar 13, 2014, at 2:50 PM, Edward Kmett wrote: > > That looks correct to me. Analogously for HashMap in unordered-containers > of course. > > > On Thu, Mar 13, 2014 at 2:49 PM, Johan Tibell wrote: > >> If you send a pull request for containers I'll merge it and make a >> release. It needs to be backwards compatible with the last 3 major GHC >> releases. I think we need to bump the minor version number so people can >> reliable write dependency bounds to depend on the role being there (as that >> might be the difference between code compiling or not). >> >> Here's a guess which params should be representational: >> >> Map k v -- k: nominal, v: represententional >> Set a -- k: nominal >> IntMap v -- v: represententional >> Sequence a -- a: represententional >> Tree a -- a: represententional >> >> >> On Thu, Mar 13, 2014 at 7:41 PM, Richard Eisenberg wrote: >> >>> Hi libraries, Johan, Edward, >>> >>> tl;dr: We really should add role annotations to the libraries that ship >>> with GHC 7.8. >>> >>> In November, I sent this out: >>> http://www.haskell.org/pipermail/libraries/2013-November/021707.html >>> It got several good responses. Some time later, Joachim and I noticed >>> that no action was taken, so we made a bug report, #8718, with a milestone >>> of 7.8.1. I believe we both assumed that would take care of it. However, >>> Simon PJ and I were surprised earlier this week to discover that Map and >>> Set still do not have role annotations. Perhaps the GHC Trac isn't the >>> right place for libraries issues, but posting here didn't quite work, so >>> that seemed like the logical next step. >>> >>> In any case, now that we have the ability to prevent abuses of datatypes >>> like Map and Set through erroneous use of GeneralizedNewtypeDeriving (and >>> the new `coerce`), we should take advantage of this fact for 7.8. See my >>> earlier email for a full explanation. >>> >>> Possibly folks' unfamiliarity with roles are in part to blame for not >>> adding these role annotations. I am happy to help sort out what goes where. >>> But, I need to work with someone with an intimate familiarity with the >>> libraries themselves to help determine what the correct annotations are. >>> For example, Map's first parameter should be nominal (its Ord instance is >>> very relevant) but its second should be representational (there are no >>> particular invariants related to the values of a map). Map is >>> straightforward in this respect; other types probably aren't. Furthermore, >>> I don't have anywhere near a complete list of what even needs attention. >>> (It should be any type abstractly exported from a library.) >>> >>> Can someone help? I've included Johan as the most recent uploader of >>> `containers` and Edward as the head of the core libraries committee. >>> >>> Thanks! >>> Richard >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Thu Mar 13 20:22:00 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 13 Mar 2014 21:22:00 +0100 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> Message-ID: Applied. Do you need a containers release ASAP so it can ship with 7.8? On Thu, Mar 13, 2014 at 9:11 PM, Richard Eisenberg wrote: > Patch attached. I only needed Map and Set -- the others are inferred. I > guess this was simpler than I thought. :) > > Richard > > > On Mar 13, 2014, at 2:49 PM, Johan Tibell wrote: > > If you send a pull request for containers I'll merge it and make a > release. It needs to be backwards compatible with the last 3 major GHC > releases. I think we need to bump the minor version number so people can > reliable write dependency bounds to depend on the role being there (as that > might be the difference between code compiling or not). > > Here's a guess which params should be representational: > > Map k v -- k: nominal, v: represententional > Set a -- k: nominal > IntMap v -- v: represententional > Sequence a -- a: represententional > Tree a -- a: represententional > > > On Thu, Mar 13, 2014 at 7:41 PM, Richard Eisenberg wrote: > >> Hi libraries, Johan, Edward, >> >> tl;dr: We really should add role annotations to the libraries that ship >> with GHC 7.8. >> >> In November, I sent this out: >> http://www.haskell.org/pipermail/libraries/2013-November/021707.html >> It got several good responses. Some time later, Joachim and I noticed >> that no action was taken, so we made a bug report, #8718, with a milestone >> of 7.8.1. I believe we both assumed that would take care of it. However, >> Simon PJ and I were surprised earlier this week to discover that Map and >> Set still do not have role annotations. Perhaps the GHC Trac isn't the >> right place for libraries issues, but posting here didn't quite work, so >> that seemed like the logical next step. >> >> In any case, now that we have the ability to prevent abuses of datatypes >> like Map and Set through erroneous use of GeneralizedNewtypeDeriving (and >> the new `coerce`), we should take advantage of this fact for 7.8. See my >> earlier email for a full explanation. >> >> Possibly folks' unfamiliarity with roles are in part to blame for not >> adding these role annotations. I am happy to help sort out what goes where. >> But, I need to work with someone with an intimate familiarity with the >> libraries themselves to help determine what the correct annotations are. >> For example, Map's first parameter should be nominal (its Ord instance is >> very relevant) but its second should be representational (there are no >> particular invariants related to the values of a map). Map is >> straightforward in this respect; other types probably aren't. Furthermore, >> I don't have anywhere near a complete list of what even needs attention. >> (It should be any type abstractly exported from a library.) >> >> Can someone help? I've included Johan as the most recent uploader of >> `containers` and Edward as the head of the core libraries committee. >> >> Thanks! >> Richard > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Thu Mar 13 20:26:18 2014 From: austin at well-typed.com (Austin Seipp) Date: Thu, 13 Mar 2014 15:26:18 -0500 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> Message-ID: That would be ideal if you don't mind, so we can go ahead and merge it and get that out of the way (vector etc can come soon after, but we don't ship that in the GHC distributions, so it's less of a problem). On Thu, Mar 13, 2014 at 3:22 PM, Johan Tibell wrote: > Applied. Do you need a containers release ASAP so it can ship with 7.8? > > > On Thu, Mar 13, 2014 at 9:11 PM, Richard Eisenberg > wrote: >> >> Patch attached. I only needed Map and Set -- the others are inferred. I >> guess this was simpler than I thought. :) >> >> Richard >> >> >> On Mar 13, 2014, at 2:49 PM, Johan Tibell wrote: >> >> If you send a pull request for containers I'll merge it and make a >> release. It needs to be backwards compatible with the last 3 major GHC >> releases. I think we need to bump the minor version number so people can >> reliable write dependency bounds to depend on the role being there (as that >> might be the difference between code compiling or not). >> >> Here's a guess which params should be representational: >> >> Map k v -- k: nominal, v: represententional >> Set a -- k: nominal >> IntMap v -- v: represententional >> Sequence a -- a: represententional >> Tree a -- a: represententional >> >> >> On Thu, Mar 13, 2014 at 7:41 PM, Richard Eisenberg >> wrote: >>> >>> Hi libraries, Johan, Edward, >>> >>> tl;dr: We really should add role annotations to the libraries that ship >>> with GHC 7.8. >>> >>> In November, I sent this out: >>> http://www.haskell.org/pipermail/libraries/2013-November/021707.html >>> It got several good responses. Some time later, Joachim and I noticed >>> that no action was taken, so we made a bug report, #8718, with a milestone >>> of 7.8.1. I believe we both assumed that would take care of it. However, >>> Simon PJ and I were surprised earlier this week to discover that Map and Set >>> still do not have role annotations. Perhaps the GHC Trac isn't the right >>> place for libraries issues, but posting here didn't quite work, so that >>> seemed like the logical next step. >>> >>> In any case, now that we have the ability to prevent abuses of datatypes >>> like Map and Set through erroneous use of GeneralizedNewtypeDeriving (and >>> the new `coerce`), we should take advantage of this fact for 7.8. See my >>> earlier email for a full explanation. >>> >>> Possibly folks' unfamiliarity with roles are in part to blame for not >>> adding these role annotations. I am happy to help sort out what goes where. >>> But, I need to work with someone with an intimate familiarity with the >>> libraries themselves to help determine what the correct annotations are. For >>> example, Map's first parameter should be nominal (its Ord instance is very >>> relevant) but its second should be representational (there are no particular >>> invariants related to the values of a map). Map is straightforward in this >>> respect; other types probably aren't. Furthermore, I don't have anywhere >>> near a complete list of what even needs attention. (It should be any type >>> abstractly exported from a library.) >>> >>> Can someone help? I've included Johan as the most recent uploader of >>> `containers` and Edward as the head of the core libraries committee. >>> >>> Thanks! >>> Richard >> >> >> >> > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From johan.tibell at gmail.com Thu Mar 13 20:46:57 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 13 Mar 2014 21:46:57 +0100 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> Message-ID: Tagged and released containers-0.5.5.0. On Thu, Mar 13, 2014 at 9:26 PM, Austin Seipp wrote: > That would be ideal if you don't mind, so we can go ahead and merge it > and get that out of the way (vector etc can come soon after, but we > don't ship that in the GHC distributions, so it's less of a problem). > > On Thu, Mar 13, 2014 at 3:22 PM, Johan Tibell > wrote: > > Applied. Do you need a containers release ASAP so it can ship with 7.8? > > > > > > On Thu, Mar 13, 2014 at 9:11 PM, Richard Eisenberg > > wrote: > >> > >> Patch attached. I only needed Map and Set -- the others are inferred. I > >> guess this was simpler than I thought. :) > >> > >> Richard > >> > >> > >> On Mar 13, 2014, at 2:49 PM, Johan Tibell > wrote: > >> > >> If you send a pull request for containers I'll merge it and make a > >> release. It needs to be backwards compatible with the last 3 major GHC > >> releases. I think we need to bump the minor version number so people can > >> reliable write dependency bounds to depend on the role being there (as > that > >> might be the difference between code compiling or not). > >> > >> Here's a guess which params should be representational: > >> > >> Map k v -- k: nominal, v: represententional > >> Set a -- k: nominal > >> IntMap v -- v: represententional > >> Sequence a -- a: represententional > >> Tree a -- a: represententional > >> > >> > >> On Thu, Mar 13, 2014 at 7:41 PM, Richard Eisenberg > >> wrote: > >>> > >>> Hi libraries, Johan, Edward, > >>> > >>> tl;dr: We really should add role annotations to the libraries that ship > >>> with GHC 7.8. > >>> > >>> In November, I sent this out: > >>> http://www.haskell.org/pipermail/libraries/2013-November/021707.html > >>> It got several good responses. Some time later, Joachim and I noticed > >>> that no action was taken, so we made a bug report, #8718, with a > milestone > >>> of 7.8.1. I believe we both assumed that would take care of it. > However, > >>> Simon PJ and I were surprised earlier this week to discover that Map > and Set > >>> still do not have role annotations. Perhaps the GHC Trac isn't the > right > >>> place for libraries issues, but posting here didn't quite work, so that > >>> seemed like the logical next step. > >>> > >>> In any case, now that we have the ability to prevent abuses of > datatypes > >>> like Map and Set through erroneous use of GeneralizedNewtypeDeriving > (and > >>> the new `coerce`), we should take advantage of this fact for 7.8. See > my > >>> earlier email for a full explanation. > >>> > >>> Possibly folks' unfamiliarity with roles are in part to blame for not > >>> adding these role annotations. I am happy to help sort out what goes > where. > >>> But, I need to work with someone with an intimate familiarity with the > >>> libraries themselves to help determine what the correct annotations > are. For > >>> example, Map's first parameter should be nominal (its Ord instance is > very > >>> relevant) but its second should be representational (there are no > particular > >>> invariants related to the values of a map). Map is straightforward in > this > >>> respect; other types probably aren't. Furthermore, I don't have > anywhere > >>> near a complete list of what even needs attention. (It should be any > type > >>> abstractly exported from a library.) > >>> > >>> Can someone help? I've included Johan as the most recent uploader of > >>> `containers` and Edward as the head of the core libraries committee. > >>> > >>> Thanks! > >>> Richard > >> > >> > >> > >> > > > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > > > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Thu Mar 13 20:57:02 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Thu, 13 Mar 2014 16:57:02 -0400 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> Message-ID: <182A7862-C91E-445C-85B6-D9A8EE4A802F@cis.upenn.edu> Well, I'm satisfied now -- again, that was all much easier than I anticipated. Thanks, all! On Mar 13, 2014, at 4:46 PM, Johan Tibell wrote: > Tagged and released containers-0.5.5.0. > > > On Thu, Mar 13, 2014 at 9:26 PM, Austin Seipp wrote: > That would be ideal if you don't mind, so we can go ahead and merge it > and get that out of the way (vector etc can come soon after, but we > don't ship that in the GHC distributions, so it's less of a problem). > > On Thu, Mar 13, 2014 at 3:22 PM, Johan Tibell wrote: > > Applied. Do you need a containers release ASAP so it can ship with 7.8? > > > > > > On Thu, Mar 13, 2014 at 9:11 PM, Richard Eisenberg > > wrote: > >> > >> Patch attached. I only needed Map and Set -- the others are inferred. I > >> guess this was simpler than I thought. :) > >> > >> Richard > >> > >> > >> On Mar 13, 2014, at 2:49 PM, Johan Tibell wrote: > >> > >> If you send a pull request for containers I'll merge it and make a > >> release. It needs to be backwards compatible with the last 3 major GHC > >> releases. I think we need to bump the minor version number so people can > >> reliable write dependency bounds to depend on the role being there (as that > >> might be the difference between code compiling or not). > >> > >> Here's a guess which params should be representational: > >> > >> Map k v -- k: nominal, v: represententional > >> Set a -- k: nominal > >> IntMap v -- v: represententional > >> Sequence a -- a: represententional > >> Tree a -- a: represententional > >> > >> > >> On Thu, Mar 13, 2014 at 7:41 PM, Richard Eisenberg > >> wrote: > >>> > >>> Hi libraries, Johan, Edward, > >>> > >>> tl;dr: We really should add role annotations to the libraries that ship > >>> with GHC 7.8. > >>> > >>> In November, I sent this out: > >>> http://www.haskell.org/pipermail/libraries/2013-November/021707.html > >>> It got several good responses. Some time later, Joachim and I noticed > >>> that no action was taken, so we made a bug report, #8718, with a milestone > >>> of 7.8.1. I believe we both assumed that would take care of it. However, > >>> Simon PJ and I were surprised earlier this week to discover that Map and Set > >>> still do not have role annotations. Perhaps the GHC Trac isn't the right > >>> place for libraries issues, but posting here didn't quite work, so that > >>> seemed like the logical next step. > >>> > >>> In any case, now that we have the ability to prevent abuses of datatypes > >>> like Map and Set through erroneous use of GeneralizedNewtypeDeriving (and > >>> the new `coerce`), we should take advantage of this fact for 7.8. See my > >>> earlier email for a full explanation. > >>> > >>> Possibly folks' unfamiliarity with roles are in part to blame for not > >>> adding these role annotations. I am happy to help sort out what goes where. > >>> But, I need to work with someone with an intimate familiarity with the > >>> libraries themselves to help determine what the correct annotations are. For > >>> example, Map's first parameter should be nominal (its Ord instance is very > >>> relevant) but its second should be representational (there are no particular > >>> invariants related to the values of a map). Map is straightforward in this > >>> respect; other types probably aren't. Furthermore, I don't have anywhere > >>> near a complete list of what even needs attention. (It should be any type > >>> abstractly exported from a library.) > >>> > >>> Can someone help? I've included Johan as the most recent uploader of > >>> `containers` and Edward as the head of the core libraries committee. > >>> > >>> Thanks! > >>> Richard > >> > >> > >> > >> > > > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > > > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam at scientician.net Thu Mar 13 21:15:53 2014 From: spam at scientician.net (Bardur Arantsson) Date: Thu, 13 Mar 2014 22:15:53 +0100 Subject: We need to add role annotations for 7.8 In-Reply-To: <182A7862-C91E-445C-85B6-D9A8EE4A802F@cis.upenn.edu> References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <182A7862-C91E-445C-85B6-D9A8EE4A802F@cis.upenn.edu> Message-ID: On 2014-03-13 21:57, Richard Eisenberg wrote: > Well, I'm satisfied now -- again, that was all much easier than I anticipated. Thanks, all! > +1 to all of the participants in this thread. That was pretty amazing! That was, what, less than 5 hours? :) Three cheers, From andres at well-typed.com Thu Mar 13 21:56:49 2014 From: andres at well-typed.com (=?ISO-8859-1?Q?Andres_L=F6h?=) Date: Thu, 13 Mar 2014 22:56:49 +0100 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> Message-ID: Hi there. Please forgive my ignorance w.r.t. roles, but why aren't all of these representational? > Map k v -- k: nominal, v: represententional > Set a -- k: nominal AFAIK both Map and Set are "normal" datatypes. Not GADTs, no type families involved. Why would anything need to be "nominal" then? Thanks in advance for explaining. Cheers, Andres -- Andres L?h, Haskell Consultant Well-Typed LLP, http://www.well-typed.com From andres at well-typed.com Thu Mar 13 22:00:14 2014 From: andres at well-typed.com (=?ISO-8859-1?Q?Andres_L=F6h?=) Date: Thu, 13 Mar 2014 23:00:14 +0100 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> Message-ID: [Sorry for the self-reply.] Oh, perhaps I actually understand this: > Please forgive my ignorance w.r.t. roles, but why aren't all of these > representational? > >> Map k v -- k: nominal, v: represententional >> Set a -- k: nominal > > AFAIK both Map and Set are "normal" datatypes. Not GADTs, no type > families involved. Why would anything need to be "nominal" then? Is this because the integrity of these types relies on the Ord instance being sane, and a newtype could have a different Ord instance defined? Cheers, Andres From austin at well-typed.com Thu Mar 13 22:03:12 2014 From: austin at well-typed.com (Austin Seipp) Date: Thu, 13 Mar 2014 17:03:12 -0500 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> Message-ID: That's right. If you had another instance of Ord for a newtype with compare = flip compare, and were allowed to coerce the keys, you can break it. On Thu, Mar 13, 2014 at 5:00 PM, Andres L?h wrote: > [Sorry for the self-reply.] > > Oh, perhaps I actually understand this: > >> Please forgive my ignorance w.r.t. roles, but why aren't all of these >> representational? >> >>> Map k v -- k: nominal, v: represententional >>> Set a -- k: nominal >> >> AFAIK both Map and Set are "normal" datatypes. Not GADTs, no type >> families involved. Why would anything need to be "nominal" then? > > Is this because the integrity of these types relies on the Ord > instance being sane, and a newtype could have a different Ord instance > defined? > > Cheers, > Andres > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From fox at ucw.cz Fri Mar 14 08:15:21 2014 From: fox at ucw.cz (Milan Straka) Date: Fri, 14 Mar 2014 09:15:21 +0100 Subject: Proposal: improve the Data.Tree API In-Reply-To: References: <530B2A49.8030605@ibotty.net> <20140301113143.GA4558@city.ac.uk> Message-ID: <20140314081521.GA15180@auryn.cz> Hi all, > -----Original message----- > From: Jo?o Crist?v?o > Sent: 2 Mar 2014, 16:47 > > > > Consider proposal 3.0.b Milan's idea of splitting forest functions to a > different submodule. Milan, could you please elaborate on that? I didn't > quite get how they would have the same name... The idea was to provide two modules, Data.Tree and Data.Tree.Forest. The methods for Forest would be in Data.Tree.Forest. To use the modules, the users would write import qualified Data.Tree as Tree import qualified Data.Tree.Forest as Forest and then use the methods as Tree.lookupTree Tree.filter and Forest.filter The disadvantage is that the Forest type still has to be defined in Data.Tree (otherwise we have a module dependency cycle), and that some methods for both Trees and Forests (unfoldTree + unfoldForest, drawTree + drawForest) already exist in Tree. If we provide both version methods in Data.Tree, the question is whether we should always use *Tree and *Forest to disambiguate the calls (filterTree, filterForest), or just use Forest (i.e., filter for Tree, filterForest for Forest). The current API is not consistent (drawTree + drawForest, but levels only, which could be easily defined for Forest too). The current proposal is also not consistent in this regard -- lookupTree and lookupTreeInForest, versus filterPruneTree and filterPruneForest. > > > -- | Size of the (flattened) tree > size :: Tree a -> Int > size = getSum . F.foldMap (const $ Sum 1) > > -- | Maximum depth of tree > maxDepth :: Tree a -> Int > > -- | Remove all nodes past a certain depth > prune :: Int -> Tree a -> Tree a > > -- | Take the mirror-image of a tree > mirror :: Tree a -> Tree a > mirror (Node a ts) = Node a . reverse $ map mirror ts > > -- | List of subtrees (including the tree itself), in pre-order. > subTrees :: Tree a -> [Tree a] > > -- | List of subtrees at each level of the tree. > subTreesByLevel :: Tree a -> [[Tree a]] > > -- | Label each node of the tree with its full subtree. > cojoin :: :: Tree a -> Tree (Tree a) > cojoin t@(Node _ ts) = Node t (map cojoin ts) Should we provide Forest variants of all those methods? We do so for lookup and filter, so I do not see reason why not for those, except for API growth. Cheers, Milan From schlepptop at henning-thielemann.de Fri Mar 14 08:39:12 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Fri, 14 Mar 2014 09:39:12 +0100 Subject: Proposal: improve the Data.Tree API In-Reply-To: <20140314081521.GA15180@auryn.cz> References: <530B2A49.8030605@ibotty.net> <20140301113143.GA4558@city.ac.uk> <20140314081521.GA15180@auryn.cz> Message-ID: <5322C030.7070605@henning-thielemann.de> Am 14.03.2014 09:15, schrieb Milan Straka: > Hi all, > >> -----Original message----- >> From: Jo?o Crist?v?o >> Sent: 2 Mar 2014, 16:47 >> >> >> >> Consider proposal 3.0.b Milan's idea of splitting forest functions to a >> different submodule. Milan, could you please elaborate on that? I didn't >> quite get how they would have the same name... > > The idea was to provide two modules, Data.Tree and Data.Tree.Forest. The > methods for Forest would be in Data.Tree.Forest. To use the modules, the > users would write > import qualified Data.Tree as Tree > import qualified Data.Tree.Forest as Forest > and then use the methods as > Tree.lookupTree > Tree.filter > and > Forest.filter I find this naming scheme attractive. In order to break module cycles I usually define private modules. E.g. Data.Tree.Private exports Tree, but the module is hidden Data.Tree.Forest imports Tree, exports Forest, module is exposed Data.Tree imports Tree and Forest, exports Tree, module is exposed From fox at ucw.cz Fri Mar 14 08:49:40 2014 From: fox at ucw.cz (Milan Straka) Date: Fri, 14 Mar 2014 09:49:40 +0100 Subject: Proposal: improve the Data.Tree API In-Reply-To: <5322C030.7070605@henning-thielemann.de> References: <530B2A49.8030605@ibotty.net> <20140301113143.GA4558@city.ac.uk> <20140314081521.GA15180@auryn.cz> <5322C030.7070605@henning-thielemann.de> Message-ID: <20140314084940.GA15433@auryn.cz> > -----Original message----- > From: Henning Thielemann > Sent: 14 Mar 2014, 09:39 > > > > >The idea was to provide two modules, Data.Tree and Data.Tree.Forest. The > >methods for Forest would be in Data.Tree.Forest. To use the modules, the > >users would write > > import qualified Data.Tree as Tree > > import qualified Data.Tree.Forest as Forest > >and then use the methods as > > Tree.lookupTree > > Tree.filter > >and > > Forest.filter > > I find this naming scheme attractive. In order to break module > cycles I usually define private modules. E.g. > > Data.Tree.Private exports Tree, but the module is hidden > Data.Tree.Forest imports Tree, exports Forest, module is exposed > Data.Tree imports Tree and Forest, exports Tree, module is exposed You are right, no dependency cycle here. Nevertheless, we probably have to export both Tree a and Forest a from Data.Tree, as the Tree datatype uses Forest. Forest is actually only type Forest a = [Tree a] so it is not such a big issue :) We should probably reexport Tree a and Forest a from Data.Tree.Forest too, so that users can use only Data.Tree.Forest module without Data.Tree. Cheers, Milan From austin at well-typed.com Fri Mar 14 08:54:40 2014 From: austin at well-typed.com (Austin Seipp) Date: Fri, 14 Mar 2014 03:54:40 -0500 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> Message-ID: *cough* I hate to be the bearer of bad news, but something went wrong it seems in HEAD: $ git describe ghc-7.9-start-188-g337bac3 $ grep "^version\:" libraries/containers/containers.cabal version: 0.5.5.0 $ ./inplace/bin/ghc-stage2 --interactive -XSafe GHCi, version 7.9.20140313: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> import Data.Coerce Prelude Data.Coerce> import Data.Map Prelude Data.Coerce Data.Map> import Data.Set Prelude Data.Coerce Data.Map Data.Set> newtype Age = MkAge Int deriving Show Prelude Data.Coerce Data.Map Data.Set> let _ = coerce :: Map Int Int -> Map Int Age Prelude Data.Coerce Data.Map Data.Set> let _ = coerce :: Map Int Int -> Map Age Int :7:9: Could not coerce from ?Map Int Int? to ?Map Age Int? because the constructors of ?Map? are not imported as required in SafeHaskell mode because the first type argument of ?Map? has role Nominal, but the arguments ?Int? and ?Age? differ arising from a use of ?coerce? In the expression: coerce :: Map Int Int -> Map Age Int In a pattern binding: _ = coerce :: Map Int Int -> Map Age Int Prelude Data.Coerce Data.Map Data.Set> let _ = coerce :: Set Int -> Set Age Prelude Data.Coerce Data.Map Data.Set> :i Set data Set a = containers-0.5.5.0:Data.Set.Base.Bin {-# UNPACK #-} !containers-0.5.5.0:Data.Set.Base.Size !a !(Set a) !(Set a) | containers-0.5.5.0:Data.Set.Base.Tip -- Defined in ?containers-0.5.5.0:Data.Set.Base? instance Eq a => Eq (Set a) -- Defined in ?containers-0.5.5.0:Data.Set.Base? instance Ord a => Ord (Set a) -- Defined in ?containers-0.5.5.0:Data.Set.Base? instance (Read a, Ord a) => Read (Set a) -- Defined in ?containers-0.5.5.0:Data.Set.Base? instance Show a => Show (Set a) -- Defined in ?containers-0.5.5.0:Data.Set.Base? Prelude Data.Coerce Data.Map Data.Set> :i Map type role Map nominal representational data Map k a = containers-0.5.5.0:Data.Map.Base.Bin {-# UNPACK #-} !containers-0.5.5.0:Data.Map.Base.Size !k a !(Map k a) !(Map k a) | containers-0.5.5.0:Data.Map.Base.Tip -- Defined in ?containers-0.5.5.0:Data.Map.Base? instance (Eq k, Eq a) => Eq (Map k a) -- Defined in ?containers-0.5.5.0:Data.Map.Base? instance Functor (Map k) -- Defined in ?containers-0.5.5.0:Data.Map.Base? instance (Ord k, Ord v) => Ord (Map k v) -- Defined in ?containers-0.5.5.0:Data.Map.Base? instance (Ord k, Read k, Read e) => Read (Map k e) -- Defined in ?containers-0.5.5.0:Data.Map.Base? instance (Show k, Show a) => Show (Map k a) -- Defined in ?containers-0.5.5.0:Data.Map.Base? Prelude Data.Coerce Data.Map Data.Set> -------------------------------------------------------------- As you can see, Map has the proper nominal representation (:i only shows it when it's other than strictly representational), but Set, for some reason, does not. I'll look into this. We should also certainly add tests to containers (under tests-ghc/) to make sure this doesn't slip by again. On Thu, Mar 13, 2014 at 5:03 PM, Austin Seipp wrote: > That's right. If you had another instance of Ord for a newtype with > compare = flip compare, and were allowed to coerce the keys, you can > break it. > > On Thu, Mar 13, 2014 at 5:00 PM, Andres L?h wrote: >> [Sorry for the self-reply.] >> >> Oh, perhaps I actually understand this: >> >>> Please forgive my ignorance w.r.t. roles, but why aren't all of these >>> representational? >>> >>>> Map k v -- k: nominal, v: represententional >>>> Set a -- k: nominal >>> >>> AFAIK both Map and Set are "normal" datatypes. Not GADTs, no type >>> families involved. Why would anything need to be "nominal" then? >> >> Is this because the integrity of these types relies on the Ord >> instance being sane, and a newtype could have a different Ord instance >> defined? >> >> Cheers, >> Andres >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From austin at well-typed.com Fri Mar 14 08:58:51 2014 From: austin at well-typed.com (Austin Seipp) Date: Fri, 14 Mar 2014 03:58:51 -0500 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> Message-ID: Here's the bug: https://github.com/ghc/packages-containers/blob/ghc-head/Data/Set/Base.hs#L232 Note it should be __GLASGOW_HASKELL__ with two underscores at the end. That's why the annotation was missed for Set only. Richard, would you mind fixing this? Or anyone, really. We should also use the above example I showed as a test case and put it in the containers repository so GHC can pick it up. Johan, you'll also have to do another release. :( Sorry. On Fri, Mar 14, 2014 at 3:54 AM, Austin Seipp wrote: > *cough* I hate to be the bearer of bad news, but something went wrong > it seems in HEAD: > > $ git describe > ghc-7.9-start-188-g337bac3 > $ grep "^version\:" libraries/containers/containers.cabal > version: 0.5.5.0 > $ ./inplace/bin/ghc-stage2 --interactive -XSafe > GHCi, version 7.9.20140313: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > Prelude> import Data.Coerce > Prelude Data.Coerce> import Data.Map > Prelude Data.Coerce Data.Map> import Data.Set > Prelude Data.Coerce Data.Map Data.Set> newtype Age = MkAge Int deriving Show > Prelude Data.Coerce Data.Map Data.Set> let _ = coerce :: Map Int Int > -> Map Int Age > Prelude Data.Coerce Data.Map Data.Set> let _ = coerce :: Map Int Int > -> Map Age Int > > :7:9: > Could not coerce from ?Map Int Int? to ?Map Age Int? > because the constructors of ?Map? are not imported > as required in SafeHaskell mode > because the first type argument of ?Map? has role Nominal, > but the arguments ?Int? and ?Age? differ > arising from a use of ?coerce? > In the expression: coerce :: Map Int Int -> Map Age Int > In a pattern binding: _ = coerce :: Map Int Int -> Map Age Int > Prelude Data.Coerce Data.Map Data.Set> let _ = coerce :: Set Int -> Set Age > Prelude Data.Coerce Data.Map Data.Set> :i Set > data Set a > = containers-0.5.5.0:Data.Set.Base.Bin {-# UNPACK #-} > !containers-0.5.5.0:Data.Set.Base.Size > !a > !(Set a) > !(Set a) > | containers-0.5.5.0:Data.Set.Base.Tip > -- Defined in ?containers-0.5.5.0:Data.Set.Base? > instance Eq a => Eq (Set a) > -- Defined in ?containers-0.5.5.0:Data.Set.Base? > instance Ord a => Ord (Set a) > -- Defined in ?containers-0.5.5.0:Data.Set.Base? > instance (Read a, Ord a) => Read (Set a) > -- Defined in ?containers-0.5.5.0:Data.Set.Base? > instance Show a => Show (Set a) > -- Defined in ?containers-0.5.5.0:Data.Set.Base? > Prelude Data.Coerce Data.Map Data.Set> :i Map > type role Map nominal representational > data Map k a > = containers-0.5.5.0:Data.Map.Base.Bin {-# UNPACK #-} > !containers-0.5.5.0:Data.Map.Base.Size > !k > a > !(Map k a) > !(Map k a) > | containers-0.5.5.0:Data.Map.Base.Tip > -- Defined in ?containers-0.5.5.0:Data.Map.Base? > instance (Eq k, Eq a) => Eq (Map k a) > -- Defined in ?containers-0.5.5.0:Data.Map.Base? > instance Functor (Map k) > -- Defined in ?containers-0.5.5.0:Data.Map.Base? > instance (Ord k, Ord v) => Ord (Map k v) > -- Defined in ?containers-0.5.5.0:Data.Map.Base? > instance (Ord k, Read k, Read e) => Read (Map k e) > -- Defined in ?containers-0.5.5.0:Data.Map.Base? > instance (Show k, Show a) => Show (Map k a) > -- Defined in ?containers-0.5.5.0:Data.Map.Base? > Prelude Data.Coerce Data.Map Data.Set> > > > -------------------------------------------------------------- > > As you can see, Map has the proper nominal representation (:i only > shows it when it's other than strictly representational), but Set, for > some reason, does not. > > I'll look into this. We should also certainly add tests to containers > (under tests-ghc/) to make sure this doesn't slip by again. > > On Thu, Mar 13, 2014 at 5:03 PM, Austin Seipp wrote: >> That's right. If you had another instance of Ord for a newtype with >> compare = flip compare, and were allowed to coerce the keys, you can >> break it. >> >> On Thu, Mar 13, 2014 at 5:00 PM, Andres L?h wrote: >>> [Sorry for the self-reply.] >>> >>> Oh, perhaps I actually understand this: >>> >>>> Please forgive my ignorance w.r.t. roles, but why aren't all of these >>>> representational? >>>> >>>>> Map k v -- k: nominal, v: represententional >>>>> Set a -- k: nominal >>>> >>>> AFAIK both Map and Set are "normal" datatypes. Not GADTs, no type >>>> families involved. Why would anything need to be "nominal" then? >>> >>> Is this because the integrity of these types relies on the Ord >>> instance being sane, and a newtype could have a different Ord instance >>> defined? >>> >>> Cheers, >>> Andres >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://www.haskell.org/mailman/listinfo/libraries >>> >> >> >> >> -- >> Regards, >> >> Austin Seipp, Haskell Consultant >> Well-Typed LLP, http://www.well-typed.com/ > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From austin at well-typed.com Fri Mar 14 09:00:18 2014 From: austin at well-typed.com (Austin Seipp) Date: Fri, 14 Mar 2014 04:00:18 -0500 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> Message-ID: *sigh* I'll also note that, for some reason, the testsuite does not automatically pick up the containers library's tests-ghc directory as a path to look for tests. So that needs to be fixed too (hopefully it hasn't bitrotted). Ugh... At the very least we *should* have a test, but maybe just stuff it in GHC's testsuite instead for now. On Fri, Mar 14, 2014 at 3:58 AM, Austin Seipp wrote: > Here's the bug: > > https://github.com/ghc/packages-containers/blob/ghc-head/Data/Set/Base.hs#L232 > > Note it should be __GLASGOW_HASKELL__ with two underscores at the end. > That's why the annotation was missed for Set only. > > Richard, would you mind fixing this? Or anyone, really. We should also > use the above example I showed as a test case and put it in the > containers repository so GHC can pick it up. > > Johan, you'll also have to do another release. :( Sorry. > > On Fri, Mar 14, 2014 at 3:54 AM, Austin Seipp wrote: >> *cough* I hate to be the bearer of bad news, but something went wrong >> it seems in HEAD: >> >> $ git describe >> ghc-7.9-start-188-g337bac3 >> $ grep "^version\:" libraries/containers/containers.cabal >> version: 0.5.5.0 >> $ ./inplace/bin/ghc-stage2 --interactive -XSafe >> GHCi, version 7.9.20140313: http://www.haskell.org/ghc/ :? for help >> Loading package ghc-prim ... linking ... done. >> Loading package integer-gmp ... linking ... done. >> Loading package base ... linking ... done. >> Prelude> import Data.Coerce >> Prelude Data.Coerce> import Data.Map >> Prelude Data.Coerce Data.Map> import Data.Set >> Prelude Data.Coerce Data.Map Data.Set> newtype Age = MkAge Int deriving Show >> Prelude Data.Coerce Data.Map Data.Set> let _ = coerce :: Map Int Int >> -> Map Int Age >> Prelude Data.Coerce Data.Map Data.Set> let _ = coerce :: Map Int Int >> -> Map Age Int >> >> :7:9: >> Could not coerce from ?Map Int Int? to ?Map Age Int? >> because the constructors of ?Map? are not imported >> as required in SafeHaskell mode >> because the first type argument of ?Map? has role Nominal, >> but the arguments ?Int? and ?Age? differ >> arising from a use of ?coerce? >> In the expression: coerce :: Map Int Int -> Map Age Int >> In a pattern binding: _ = coerce :: Map Int Int -> Map Age Int >> Prelude Data.Coerce Data.Map Data.Set> let _ = coerce :: Set Int -> Set Age >> Prelude Data.Coerce Data.Map Data.Set> :i Set >> data Set a >> = containers-0.5.5.0:Data.Set.Base.Bin {-# UNPACK #-} >> !containers-0.5.5.0:Data.Set.Base.Size >> !a >> !(Set a) >> !(Set a) >> | containers-0.5.5.0:Data.Set.Base.Tip >> -- Defined in ?containers-0.5.5.0:Data.Set.Base? >> instance Eq a => Eq (Set a) >> -- Defined in ?containers-0.5.5.0:Data.Set.Base? >> instance Ord a => Ord (Set a) >> -- Defined in ?containers-0.5.5.0:Data.Set.Base? >> instance (Read a, Ord a) => Read (Set a) >> -- Defined in ?containers-0.5.5.0:Data.Set.Base? >> instance Show a => Show (Set a) >> -- Defined in ?containers-0.5.5.0:Data.Set.Base? >> Prelude Data.Coerce Data.Map Data.Set> :i Map >> type role Map nominal representational >> data Map k a >> = containers-0.5.5.0:Data.Map.Base.Bin {-# UNPACK #-} >> !containers-0.5.5.0:Data.Map.Base.Size >> !k >> a >> !(Map k a) >> !(Map k a) >> | containers-0.5.5.0:Data.Map.Base.Tip >> -- Defined in ?containers-0.5.5.0:Data.Map.Base? >> instance (Eq k, Eq a) => Eq (Map k a) >> -- Defined in ?containers-0.5.5.0:Data.Map.Base? >> instance Functor (Map k) >> -- Defined in ?containers-0.5.5.0:Data.Map.Base? >> instance (Ord k, Ord v) => Ord (Map k v) >> -- Defined in ?containers-0.5.5.0:Data.Map.Base? >> instance (Ord k, Read k, Read e) => Read (Map k e) >> -- Defined in ?containers-0.5.5.0:Data.Map.Base? >> instance (Show k, Show a) => Show (Map k a) >> -- Defined in ?containers-0.5.5.0:Data.Map.Base? >> Prelude Data.Coerce Data.Map Data.Set> >> >> >> -------------------------------------------------------------- >> >> As you can see, Map has the proper nominal representation (:i only >> shows it when it's other than strictly representational), but Set, for >> some reason, does not. >> >> I'll look into this. We should also certainly add tests to containers >> (under tests-ghc/) to make sure this doesn't slip by again. >> >> On Thu, Mar 13, 2014 at 5:03 PM, Austin Seipp wrote: >>> That's right. If you had another instance of Ord for a newtype with >>> compare = flip compare, and were allowed to coerce the keys, you can >>> break it. >>> >>> On Thu, Mar 13, 2014 at 5:00 PM, Andres L?h wrote: >>>> [Sorry for the self-reply.] >>>> >>>> Oh, perhaps I actually understand this: >>>> >>>>> Please forgive my ignorance w.r.t. roles, but why aren't all of these >>>>> representational? >>>>> >>>>>> Map k v -- k: nominal, v: represententional >>>>>> Set a -- k: nominal >>>>> >>>>> AFAIK both Map and Set are "normal" datatypes. Not GADTs, no type >>>>> families involved. Why would anything need to be "nominal" then? >>>> >>>> Is this because the integrity of these types relies on the Ord >>>> instance being sane, and a newtype could have a different Ord instance >>>> defined? >>>> >>>> Cheers, >>>> Andres >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries at haskell.org >>>> http://www.haskell.org/mailman/listinfo/libraries >>>> >>> >>> >>> >>> -- >>> Regards, >>> >>> Austin Seipp, Haskell Consultant >>> Well-Typed LLP, http://www.well-typed.com/ >> >> >> >> -- >> Regards, >> >> Austin Seipp, Haskell Consultant >> Well-Typed LLP, http://www.well-typed.com/ > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From johan.tibell at gmail.com Fri Mar 14 09:36:11 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri, 14 Mar 2014 10:36:11 +0100 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> Message-ID: I've released and tagged a new containers version that fixes the typo. I'm quite worried about this change though. I thought the default role for data type was nominal, as that's the safe default. If the default is representational, every package author will need to be aware of this feature and update their packages. That's quite a high cost. On Fri, Mar 14, 2014 at 10:00 AM, Austin Seipp wrote: > *sigh* I'll also note that, for some reason, the testsuite does not > automatically pick up the containers library's tests-ghc directory as > a path to look for tests. So that needs to be fixed too (hopefully it > hasn't bitrotted). Ugh... > > At the very least we *should* have a test, but maybe just stuff it in > GHC's testsuite instead for now. > > On Fri, Mar 14, 2014 at 3:58 AM, Austin Seipp > wrote: > > Here's the bug: > > > > > https://github.com/ghc/packages-containers/blob/ghc-head/Data/Set/Base.hs#L232 > > > > Note it should be __GLASGOW_HASKELL__ with two underscores at the end. > > That's why the annotation was missed for Set only. > > > > Richard, would you mind fixing this? Or anyone, really. We should also > > use the above example I showed as a test case and put it in the > > containers repository so GHC can pick it up. > > > > Johan, you'll also have to do another release. :( Sorry. > > > > On Fri, Mar 14, 2014 at 3:54 AM, Austin Seipp > wrote: > >> *cough* I hate to be the bearer of bad news, but something went wrong > >> it seems in HEAD: > >> > >> $ git describe > >> ghc-7.9-start-188-g337bac3 > >> $ grep "^version\:" libraries/containers/containers.cabal > >> version: 0.5.5.0 > >> $ ./inplace/bin/ghc-stage2 --interactive -XSafe > >> GHCi, version 7.9.20140313: http://www.haskell.org/ghc/ :? for help > >> Loading package ghc-prim ... linking ... done. > >> Loading package integer-gmp ... linking ... done. > >> Loading package base ... linking ... done. > >> Prelude> import Data.Coerce > >> Prelude Data.Coerce> import Data.Map > >> Prelude Data.Coerce Data.Map> import Data.Set > >> Prelude Data.Coerce Data.Map Data.Set> newtype Age = MkAge Int deriving > Show > >> Prelude Data.Coerce Data.Map Data.Set> let _ = coerce :: Map Int Int > >> -> Map Int Age > >> Prelude Data.Coerce Data.Map Data.Set> let _ = coerce :: Map Int Int > >> -> Map Age Int > >> > >> :7:9: > >> Could not coerce from 'Map Int Int' to 'Map Age Int' > >> because the constructors of 'Map' are not imported > >> as required in SafeHaskell mode > >> because the first type argument of 'Map' has role Nominal, > >> but the arguments 'Int' and 'Age' differ > >> arising from a use of 'coerce' > >> In the expression: coerce :: Map Int Int -> Map Age Int > >> In a pattern binding: _ = coerce :: Map Int Int -> Map Age Int > >> Prelude Data.Coerce Data.Map Data.Set> let _ = coerce :: Set Int -> Set > Age > >> Prelude Data.Coerce Data.Map Data.Set> :i Set > >> data Set a > >> = containers-0.5.5.0:Data.Set.Base.Bin {-# UNPACK #-} > >> !containers-0.5.5.0:Data.Set.Base.Size > >> !a > >> !(Set a) > >> !(Set a) > >> | containers-0.5.5.0:Data.Set.Base.Tip > >> -- Defined in 'containers-0.5.5.0:Data.Set.Base' > >> instance Eq a => Eq (Set a) > >> -- Defined in 'containers-0.5.5.0:Data.Set.Base' > >> instance Ord a => Ord (Set a) > >> -- Defined in 'containers-0.5.5.0:Data.Set.Base' > >> instance (Read a, Ord a) => Read (Set a) > >> -- Defined in 'containers-0.5.5.0:Data.Set.Base' > >> instance Show a => Show (Set a) > >> -- Defined in 'containers-0.5.5.0:Data.Set.Base' > >> Prelude Data.Coerce Data.Map Data.Set> :i Map > >> type role Map nominal representational > >> data Map k a > >> = containers-0.5.5.0:Data.Map.Base.Bin {-# UNPACK #-} > >> !containers-0.5.5.0:Data.Map.Base.Size > >> !k > >> a > >> !(Map k a) > >> !(Map k a) > >> | containers-0.5.5.0:Data.Map.Base.Tip > >> -- Defined in 'containers-0.5.5.0:Data.Map.Base' > >> instance (Eq k, Eq a) => Eq (Map k a) > >> -- Defined in 'containers-0.5.5.0:Data.Map.Base' > >> instance Functor (Map k) > >> -- Defined in 'containers-0.5.5.0:Data.Map.Base' > >> instance (Ord k, Ord v) => Ord (Map k v) > >> -- Defined in 'containers-0.5.5.0:Data.Map.Base' > >> instance (Ord k, Read k, Read e) => Read (Map k e) > >> -- Defined in 'containers-0.5.5.0:Data.Map.Base' > >> instance (Show k, Show a) => Show (Map k a) > >> -- Defined in 'containers-0.5.5.0:Data.Map.Base' > >> Prelude Data.Coerce Data.Map Data.Set> > >> > >> > >> -------------------------------------------------------------- > >> > >> As you can see, Map has the proper nominal representation (:i only > >> shows it when it's other than strictly representational), but Set, for > >> some reason, does not. > >> > >> I'll look into this. We should also certainly add tests to containers > >> (under tests-ghc/) to make sure this doesn't slip by again. > >> > >> On Thu, Mar 13, 2014 at 5:03 PM, Austin Seipp > wrote: > >>> That's right. If you had another instance of Ord for a newtype with > >>> compare = flip compare, and were allowed to coerce the keys, you can > >>> break it. > >>> > >>> On Thu, Mar 13, 2014 at 5:00 PM, Andres L?h > wrote: > >>>> [Sorry for the self-reply.] > >>>> > >>>> Oh, perhaps I actually understand this: > >>>> > >>>>> Please forgive my ignorance w.r.t. roles, but why aren't all of these > >>>>> representational? > >>>>> > >>>>>> Map k v -- k: nominal, v: represententional > >>>>>> Set a -- k: nominal > >>>>> > >>>>> AFAIK both Map and Set are "normal" datatypes. Not GADTs, no type > >>>>> families involved. Why would anything need to be "nominal" then? > >>>> > >>>> Is this because the integrity of these types relies on the Ord > >>>> instance being sane, and a newtype could have a different Ord instance > >>>> defined? > >>>> > >>>> Cheers, > >>>> Andres > >>>> _______________________________________________ > >>>> Libraries mailing list > >>>> Libraries at haskell.org > >>>> http://www.haskell.org/mailman/listinfo/libraries > >>>> > >>> > >>> > >>> > >>> -- > >>> Regards, > >>> > >>> Austin Seipp, Haskell Consultant > >>> Well-Typed LLP, http://www.well-typed.com/ > >> > >> > >> > >> -- > >> Regards, > >> > >> Austin Seipp, Haskell Consultant > >> Well-Typed LLP, http://www.well-typed.com/ > > > > > > > > -- > > Regards, > > > > Austin Seipp, Haskell Consultant > > Well-Typed LLP, http://www.well-typed.com/ > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Fri Mar 14 13:00:28 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 14 Mar 2014 09:00:28 -0400 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> Message-ID: On Fri, Mar 14, 2014 at 5:36 AM, Johan Tibell wrote: > I'm quite worried about this change though. I thought the default role for > data type was nominal, as that's the safe default. If the default is > representational, every package author will need to be aware of this > feature and update their packages. That's quite a high cost. > Nominal default breaks everything that uses newtype deriving and doesn't have role annotations, doesn't it? Representational default means things behave in 7.8 as they did in earlier GHCs. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Fri Mar 14 13:12:38 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri, 14 Mar 2014 14:12:38 +0100 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> Message-ID: On Fri, Mar 14, 2014 at 2:00 PM, Brandon Allbery wrote: > On Fri, Mar 14, 2014 at 5:36 AM, Johan Tibell wrote: > >> I'm quite worried about this change though. I thought the default role >> for data type was nominal, as that's the safe default. If the default is >> representational, every package author will need to be aware of this >> feature and update their packages. That's quite a high cost. >> > > Nominal default breaks everything that uses newtype deriving and doesn't > have role annotations, doesn't it? Representational default means things > behave in 7.8 as they did in earlier GHCs. > True, but shouldn't coerce be called unsafeCoerce then as it is, in fact, unsafe from a correctness perspective? -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Fri Mar 14 13:22:45 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 14 Mar 2014 09:22:45 -0400 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> Message-ID: On Fri, Mar 14, 2014 at 9:12 AM, Johan Tibell wrote: > On Fri, Mar 14, 2014 at 2:00 PM, Brandon Allbery wrote: > >> On Fri, Mar 14, 2014 at 5:36 AM, Johan Tibell wrote: >> >>> I'm quite worried about this change though. I thought the default role >>> for data type was nominal, as that's the safe default. If the default is >>> representational, every package author will need to be aware of this >>> feature and update their packages. That's quite a high cost. >>> >> >> Nominal default breaks everything that uses newtype deriving and doesn't >> have role annotations, doesn't it? Representational default means things >> behave in 7.8 as they did in earlier GHCs. >> > > True, but shouldn't coerce be called unsafeCoerce then as it is, in fact, > unsafe from a correctness perspective? > My expectation would be that 7.8 keeps the old behavior while enabling the new, and possibly issues a warning when newtype deriving is used with no role annotations; this gives us a release cycle to get role annotations in place before making the new safe behavior default. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Fri Mar 14 14:22:36 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 14 Mar 2014 10:22:36 -0400 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> Message-ID: <80F4D480-C520-4AD5-B9CD-C7061199C7AB@cis.upenn.edu> My expectation matches Brandon's, that making roles default to nominal would break lots of code and therefore have a higher cost than defaulting to representational (well, phantom actually, but that's a rarer case). As for issuing a warning, I've thought about this some, but I don't know the right place to detect and issue it. Do we want to warn about any parameterized datatype definition without a role annotation? (That's a lot of them!) Do we want to warn only about abstractly-exported datatypes without role annotations? (But, what about types exported concretely from an internal, hidden module and then re-exported abstractly?) Do we want to warn at use sites? (But then the warning is more about the library than the use site.) It's all quite thorny, and several of us have thought about this all for a while with no strong conclusion. So, the best thing we came up with is this: Libraries that wish to export abstract data types must do two things: 1. Manage export lists carefully. 2. Use role annotations. A better question might be how to get the word out about the above. Whether or not `coerce` is "unsafe from a correctness perspective" depends on your definition of correctness: - If you care only about type safety, then `coerce` is most certainly safe. - If you believe that a type's roles are what its author intended, then `coerce` is most certainly safe. - If you believe that authors may omit critical role annotations and are worried about breaking abstraction, then `coerce` is not safe. There has been some thought about making `coerce`'s behavior different with -XSafe than without. See, for example, tickets #8745 (https://ghc.haskell.org/trac/ghc/ticket/8745) and #8827 (https://ghc.haskell.org/trac/ghc/ticket/8827). In the end, we decided to remove this, instead believing authors' role annotations (or lack thereof). Note that 7.8 does not actually give users a new way to break abstractions -- GeneralizedNewtypeDeriving has been around for a while. What 7.8 provides is a way to break abstractions more easily (`coerce`) and a way to prevent this from happening (role annotations). Richard On Mar 14, 2014, at 9:22 AM, Brandon Allbery wrote: > On Fri, Mar 14, 2014 at 9:12 AM, Johan Tibell wrote: > On Fri, Mar 14, 2014 at 2:00 PM, Brandon Allbery wrote: > On Fri, Mar 14, 2014 at 5:36 AM, Johan Tibell wrote: > I'm quite worried about this change though. I thought the default role for data type was nominal, as that's the safe default. If the default is representational, every package author will need to be aware of this feature and update their packages. That's quite a high cost. > > Nominal default breaks everything that uses newtype deriving and doesn't have role annotations, doesn't it? Representational default means things behave in 7.8 as they did in earlier GHCs. > > True, but shouldn't coerce be called unsafeCoerce then as it is, in fact, unsafe from a correctness perspective? > > My expectation would be that 7.8 keeps the old behavior while enabling the new, and possibly issues a warning when newtype deriving is used with no role annotations; this gives us a release cycle to get role annotations in place before making the new safe behavior default. > > -- > brandon s allbery kf8nh sine nomine associates > allbery.b at gmail.com ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Fri Mar 14 14:26:17 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri, 14 Mar 2014 15:26:17 +0100 Subject: We need to add role annotations for 7.8 In-Reply-To: <80F4D480-C520-4AD5-B9CD-C7061199C7AB@cis.upenn.edu> References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <80F4D480-C520-4AD5-B9CD-C7061199C7AB@cis.upenn.edu> Message-ID: So is the goal that all library authors will add role annotations in the future? If that doesn't happen, what does that mean for users of coerce? Will they just have to be careful in what they coerce and make sure that if their library internally uses coerce that library is only used with types that have correct role annotations? On Fri, Mar 14, 2014 at 3:22 PM, Richard Eisenberg wrote: > My expectation matches Brandon's, that making roles default to nominal > would break lots of code and therefore have a higher cost than defaulting > to representational (well, phantom actually, but that's a rarer case). > > As for issuing a warning, I've thought about this some, but I don't know > the right place to detect and issue it. Do we want to warn about any > parameterized datatype definition without a role annotation? (That's a lot > of them!) Do we want to warn only about abstractly-exported datatypes > without role annotations? (But, what about types exported concretely from > an internal, hidden module and then re-exported abstractly?) Do we want to > warn at use sites? (But then the warning is more about the library than the > use site.) It's all quite thorny, and several of us have thought about this > all for a while with no strong conclusion. > > So, the best thing we came up with is this: Libraries that wish to export > abstract data types must do two things: > 1. Manage export lists carefully. > 2. Use role annotations. > > A better question might be how to get the word out about the above. > > Whether or not `coerce` is "unsafe from a correctness perspective" depends > on your definition of correctness: > - If you care only about type safety, then `coerce` is most certainly safe. > - If you believe that a type's roles are what its author intended, then > `coerce` is most certainly safe. > - If you believe that authors may omit critical role annotations and are > worried about breaking abstraction, then `coerce` is not safe. > > There has been some thought about making `coerce`'s behavior different > with -XSafe than without. See, for example, tickets #8745 ( > https://ghc.haskell.org/trac/ghc/ticket/8745) and #8827 ( > https://ghc.haskell.org/trac/ghc/ticket/8827). In the end, we decided to > remove this, instead believing authors' role annotations (or lack thereof). > > Note that 7.8 does not actually give users a new way to break abstractions > -- GeneralizedNewtypeDeriving has been around for a while. What 7.8 > provides is a way to break abstractions more easily (`coerce`) and a way to > prevent this from happening (role annotations). > > Richard > > On Mar 14, 2014, at 9:22 AM, Brandon Allbery wrote: > > On Fri, Mar 14, 2014 at 9:12 AM, Johan Tibell wrote: > >> On Fri, Mar 14, 2014 at 2:00 PM, Brandon Allbery wrote: >> >>> On Fri, Mar 14, 2014 at 5:36 AM, Johan Tibell wrote: >>> >>>> I'm quite worried about this change though. I thought the default role >>>> for data type was nominal, as that's the safe default. If the default is >>>> representational, every package author will need to be aware of this >>>> feature and update their packages. That's quite a high cost. >>>> >>> >>> Nominal default breaks everything that uses newtype deriving and doesn't >>> have role annotations, doesn't it? Representational default means things >>> behave in 7.8 as they did in earlier GHCs. >>> >> >> True, but shouldn't coerce be called unsafeCoerce then as it is, in fact, >> unsafe from a correctness perspective? >> > > My expectation would be that 7.8 keeps the old behavior while enabling the > new, and possibly issues a warning when newtype deriving is used with no > role annotations; this gives us a release cycle to get role annotations in > place before making the new safe behavior default. > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b at gmail.com > ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Fri Mar 14 14:59:43 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 14 Mar 2014 10:59:43 -0400 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <80F4D480-C520-4AD5-B9CD-C7061199C7AB@cis.upenn.edu> Message-ID: While I see where your discomfort is coming from, this same argument could be said about GeneralizedNewtypeDeriving. I suppose the answer is "yes" -- the goal is for library authors to add role annotations in the future. There is no way to infer what roles are appropriate to preserve the right level of abstraction. Note that this goal would stand regardless of the decision around default roles. Until then, we will have to use `coerce` carefully. After all, `coerce` is only an optimization -- it isn't meant to provide a feature that is otherwise impossible to implement. Richard On Mar 14, 2014, at 10:26 AM, Johan Tibell wrote: > So is the goal that all library authors will add role annotations in the future? If that doesn't happen, what does that mean for users of coerce? Will they just have to be careful in what they coerce and make sure that if their library internally uses coerce that library is only used with types that have correct role annotations? > > > On Fri, Mar 14, 2014 at 3:22 PM, Richard Eisenberg wrote: > My expectation matches Brandon's, that making roles default to nominal would break lots of code and therefore have a higher cost than defaulting to representational (well, phantom actually, but that's a rarer case). > > As for issuing a warning, I've thought about this some, but I don't know the right place to detect and issue it. Do we want to warn about any parameterized datatype definition without a role annotation? (That's a lot of them!) Do we want to warn only about abstractly-exported datatypes without role annotations? (But, what about types exported concretely from an internal, hidden module and then re-exported abstractly?) Do we want to warn at use sites? (But then the warning is more about the library than the use site.) It's all quite thorny, and several of us have thought about this all for a while with no strong conclusion. > > So, the best thing we came up with is this: Libraries that wish to export abstract data types must do two things: > 1. Manage export lists carefully. > 2. Use role annotations. > > A better question might be how to get the word out about the above. > > Whether or not `coerce` is "unsafe from a correctness perspective" depends on your definition of correctness: > - If you care only about type safety, then `coerce` is most certainly safe. > - If you believe that a type's roles are what its author intended, then `coerce` is most certainly safe. > - If you believe that authors may omit critical role annotations and are worried about breaking abstraction, then `coerce` is not safe. > > There has been some thought about making `coerce`'s behavior different with -XSafe than without. See, for example, tickets #8745 (https://ghc.haskell.org/trac/ghc/ticket/8745) and #8827 (https://ghc.haskell.org/trac/ghc/ticket/8827). In the end, we decided to remove this, instead believing authors' role annotations (or lack thereof). > > Note that 7.8 does not actually give users a new way to break abstractions -- GeneralizedNewtypeDeriving has been around for a while. What 7.8 provides is a way to break abstractions more easily (`coerce`) and a way to prevent this from happening (role annotations). > > Richard > > On Mar 14, 2014, at 9:22 AM, Brandon Allbery wrote: > >> On Fri, Mar 14, 2014 at 9:12 AM, Johan Tibell wrote: >> On Fri, Mar 14, 2014 at 2:00 PM, Brandon Allbery wrote: >> On Fri, Mar 14, 2014 at 5:36 AM, Johan Tibell wrote: >> I'm quite worried about this change though. I thought the default role for data type was nominal, as that's the safe default. If the default is representational, every package author will need to be aware of this feature and update their packages. That's quite a high cost. >> >> Nominal default breaks everything that uses newtype deriving and doesn't have role annotations, doesn't it? Representational default means things behave in 7.8 as they did in earlier GHCs. >> >> True, but shouldn't coerce be called unsafeCoerce then as it is, in fact, unsafe from a correctness perspective? >> >> My expectation would be that 7.8 keeps the old behavior while enabling the new, and possibly issues a warning when newtype deriving is used with no role annotations; this gives us a release cycle to get role annotations in place before making the new safe behavior default. >> >> -- >> brandon s allbery kf8nh sine nomine associates >> allbery.b at gmail.com ballbery at sinenomine.net >> unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From the.dead.shall.rise at gmail.com Fri Mar 14 15:41:08 2014 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Fri, 14 Mar 2014 16:41:08 +0100 Subject: We need to add role annotations for 7.8 In-Reply-To: <80F4D480-C520-4AD5-B9CD-C7061199C7AB@cis.upenn.edu> References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <80F4D480-C520-4AD5-B9CD-C7061199C7AB@cis.upenn.edu> Message-ID: Hi Richard, On 14 March 2014 15:22, Richard Eisenberg wrote: > There has been some thought about making `coerce`'s behavior different with > -XSafe than without. See, for example, tickets #8745 > (https://ghc.haskell.org/trac/ghc/ticket/8745) and #8827 > (https://ghc.haskell.org/trac/ghc/ticket/8827). In the end, we decided to > remove this, instead believing authors' role annotations (or lack thereof). Interesting, it looks like the paper hasn't yet been updated to reflect this. > Note that 7.8 does not actually give users a new way to break abstractions > -- GeneralizedNewtypeDeriving has been around for a while. What 7.8 provides > is a way to break abstractions more easily (`coerce`) and a way to prevent > this from happening (role annotations). Isn't this false in the case of -XSafe? In 7.8 one will be able to coerce 'Map Int a' to 'Map Age a' (provided that there is no role annotation for Map), which didn't work previously because SafeHaskell prohibited GND. From eir at cis.upenn.edu Fri Mar 14 16:25:16 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 14 Mar 2014 12:25:16 -0400 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <80F4D480-C520-4AD5-B9CD-C7061199C7AB@cis.upenn.edu> Message-ID: <937ECF37-CA68-468D-9569-5874100B62C0@cis.upenn.edu> On Mar 14, 2014, at 11:41 AM, Mikhail Glushenkov wrote: > Hi Richard, > > On 14 March 2014 15:22, Richard Eisenberg wrote: >> There has been some thought about making `coerce`'s behavior different with >> -XSafe than without. See, for example, tickets #8745 >> (https://ghc.haskell.org/trac/ghc/ticket/8745) and #8827 >> (https://ghc.haskell.org/trac/ghc/ticket/8827). In the end, we decided to >> remove this, instead believing authors' role annotations (or lack thereof). > > Interesting, it looks like the paper hasn't yet been updated to reflect this. That's correct. This is a late-breaking design decision. > >> Note that 7.8 does not actually give users a new way to break abstractions >> -- GeneralizedNewtypeDeriving has been around for a while. What 7.8 provides >> is a way to break abstractions more easily (`coerce`) and a way to prevent >> this from happening (role annotations). > > Isn't this false in the case of -XSafe? In 7.8 one will be able to > coerce 'Map Int a' to 'Map Age a' (provided that there is no role > annotation for Map), which didn't work previously because SafeHaskell > prohibited GND. This is an even thornier corner of a thorny design decision. As one can discover from various public sources, I have advocated for adding extra checks under -XSafe, essentially closing this hole, as described in the paper and in those tickets. However, due to trouble *inferring* safe mode with the extra checks, and the fact that there was no clear design goal to attend to, we decided to drop the checks, with Simon PJ consistently advocating against the checks. There's nothing insurmountable here, just more engineering overhead. Is it worth it? The real trouble with making this decision is that we have no real guidance. We've tried contacting David Terei (the originator of Safe Haskell) several times to no avail. If you are an actual consumer of Safe Haskell and would like to share your opinion on this front, I do encourage you to make a ticket, essentially requesting a resurrection of the extra Safe checks. Richard From the.dead.shall.rise at gmail.com Fri Mar 14 17:45:16 2014 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Fri, 14 Mar 2014 18:45:16 +0100 Subject: We need to add role annotations for 7.8 In-Reply-To: <937ECF37-CA68-468D-9569-5874100B62C0@cis.upenn.edu> References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <80F4D480-C520-4AD5-B9CD-C7061199C7AB@cis.upenn.edu> <937ECF37-CA68-468D-9569-5874100B62C0@cis.upenn.edu> Message-ID: Hi Richard, On 14 March 2014 17:25, Richard Eisenberg wrote: > > This is an even thornier corner of a thorny design decision. As one can discover from various public sources, I have advocated for adding extra checks under -XSafe, essentially closing this hole, as described in the paper and in those tickets. However, due to trouble *inferring* safe mode with the extra checks, and the fact that there was no clear design goal to attend to, we decided to drop the checks, with Simon PJ consistently advocating against the checks. There's nothing insurmountable here, just more engineering overhead. Is it worth it? I think that you were right. IIUC, omitting these checks essentially makes the MinList example from the Safe Haskell paper legal (provided that there are no role annotations), which was the reason for prohibiting GND in Safe Haskell code. I agree with Brandon that it'd be nice to have some kind of warning. > The real trouble with making this decision is that we have no real guidance. We've tried contacting David Terei (the originator of Safe Haskell) several times to no avail. If you are an actual consumer of Safe Haskell and would like to share your opinion on this front, I do encourage you to make a ticket, essentially requesting a resurrection of the extra Safe checks. Yes, it would be nice if David Terei or David Mazi?res (CC:ed) could comment. From ekmett at gmail.com Sat Mar 15 04:16:18 2014 From: ekmett at gmail.com (Edward Kmett) Date: Sat, 15 Mar 2014 00:16:18 -0400 Subject: Avoid passing unnecessary dictionaries in Data.Complex Message-ID: We removed the data type context from Data.Complex some time ago. However, when we did so, we left the rest of the API in that module intact. Many of the accessors in that module (should) work with much more general types now! e.g. realPart :: Complex a -> a instead of realPart :: RealFloat a => Complex a -> a I propose we stop passing around dictionaries we don't need to methods that don't use them. Concretely, I'm proposing we simplify the signatures of the following functions, which in the current API all unnecessarily take a RealFloatconstraint that they don't use. realPart :: Complex a -> a imagPart :: Complex a -> a conjugate :: Num a => Complex a -> Complex a mkPolar :: Floating a => a -> a -> Complex a cis :: Floating a => a -> Complex a Discussion Period: 2 weeks -Edward Kmett -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sat Mar 15 04:21:33 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 15 Mar 2014 00:21:33 -0400 Subject: Avoid passing unnecessary dictionaries in Data.Complex In-Reply-To: References: Message-ID: +7 theres other issues with Data.Complex, but i'll not raise those for this battle today :) On Sat, Mar 15, 2014 at 12:16 AM, Edward Kmett wrote: > We removed the data type context from Data.Complex some time ago. > > However, when we did so, we left the rest of the API in that module intact. > > Many of the accessors in that module (should) work with much more general > types now! > > e.g. > > realPart :: Complex a -> a > > instead of > > realPart :: RealFloat a => Complex a -> a > > I propose we stop passing around dictionaries we don't need to methods > that don't use them. > > Concretely, I'm proposing we simplify the signatures of the following > functions, which in the current API all unnecessarily take a RealFloatconstraint that they don't use. > > realPart :: Complex a -> a > imagPart :: Complex a -> a > conjugate :: Num a => Complex a -> Complex a > mkPolar :: Floating a => a -> a -> Complex a > cis :: Floating a => a -> Complex a > > Discussion Period: 2 weeks > > -Edward Kmett > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.abel at ifi.lmu.de Sat Mar 15 08:54:54 2014 From: andreas.abel at ifi.lmu.de (Andreas Abel) Date: Sat, 15 Mar 2014 09:54:54 +0100 Subject: Avoid passing unnecessary dictionaries in Data.Complex In-Reply-To: References: Message-ID: <5324155E.8040600@ifi.lmu.de> +1 of course. On 15.03.2014 05:16, Edward Kmett wrote: > We removed the data type context from Data.Complex some time ago. > > However, when we did so, we left the rest of the API in that module intact. > > Many of the accessors in that module (should) work with much more > general types now! > > e.g. > > realPart :: Complex a -> a > > instead of > > realPart :: RealFloat a => Complex a -> a > > I propose we stop passing around dictionaries we don't need to methods > that don't use them. > > Concretely, I'm proposing we simplify the signatures of the following > functions, which in the current API all unnecessarily take a RealFloat > constraint that they don't use. > > realPart :: Complex a -> a > imagPart :: Complex a -> a > conjugate :: Num a => Complex a -> Complex a > mkPolar :: Floating a => a -> a -> Complex a > cis :: Floating a => a -> Complex a > > Discussion Period: 2 weeks > > -Edward Kmett > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel at gu.se http://www2.tcs.ifi.lmu.de/~abel/ From daniel.is.fischer at googlemail.com Sat Mar 15 13:24:25 2014 From: daniel.is.fischer at googlemail.com (Daniel Fischer) Date: Sat, 15 Mar 2014 14:24:25 +0100 Subject: Avoid passing unnecessary dictionaries in Data.Complex In-Reply-To: References: Message-ID: <1805156.gozDvupE4I@linux-hpeb.site> On Saturday 15 March 2014, 00:16:18, Edward Kmett wrote: > Concretely, I'm proposing we simplify the signatures of the following > functions, which in the current API all unnecessarily take a > RealFloatconstraint that they don't use. +1, naturally From carter.schonwald at gmail.com Sat Mar 15 17:52:44 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 15 Mar 2014 13:52:44 -0400 Subject: breath of life for dataenc lib In-Reply-To: References: Message-ID: ccing Libraries (forgot) On Sat, Mar 15, 2014 at 1:36 PM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > Hey All, > Dataenc is needed for building darcs, and currently doesn't build on 7.8 > without some easy patching (i'm also trying to mod the tesing code to use > the cabal test suite support but that doesn't seem to work). I couldn't > find a repo online so i started one here > https://github.com/cartazio/dataenc > > @magnus, Are you still game for continuing to maintain it? (the hackage > docs indicate that you have uploader acls but also that theres no > maintainer per se and theres no repo online) > > thoughts? > > thanks > -Carter > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Sat Mar 15 18:11:12 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 15 Mar 2014 19:11:12 +0100 Subject: Avoid passing unnecessary dictionaries in Data.Complex In-Reply-To: References: Message-ID: <1394907072.3517.4.camel@kirk> Hi, +1 (stating the obvious) Greetings, Joachim Am Samstag, den 15.03.2014, 00:16 -0400 schrieb Edward Kmett: > We removed the data type context from Data.Complex some time ago. > > > However, when we did so, we left the rest of the API in that module > intact. > > > Many of the accessors in that module (should) work with much more > general types now! > > > e.g. > > > realPart :: Complex a -> a > > > instead of > > > realPart :: RealFloat a => Complex a -> a > > > I propose we stop passing around dictionaries we don't need to methods > that don't use them. > > > Concretely, I'm proposing we simplify the signatures of the following > functions, which in the current API all unnecessarily take a RealFloat > constraint that they don't use. > > > realPart :: Complex a -> a > imagPart :: Complex a -> a > conjugate :: Num a => Complex a -> Complex a > mkPolar :: Floating a => a -> a -> Complex a > cis :: Floating a => a -> Complex a > > > Discussion Period: 2 weeks > > > -Edward Kmett > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From merijn at inconsistent.nl Sun Mar 16 14:25:15 2014 From: merijn at inconsistent.nl (Merijn Verstraaten) Date: Sun, 16 Mar 2014 15:25:15 +0100 Subject: PROPOSAL(S): threadWaitError and threadWaitErrorSTM Message-ID: Hola! Control.Concurrent currently has: threadWaitRead :: Fd -> IO () threadWaitWrite :: Fd -> IO () threadWaitReadSTM :: Fd -> IO (STM (), IO ()) threadWaitWriteSTM :: Fd -> IO (STM (), IO ()) (btw, whoever added the STM versions, I <3 you) I would like to propose adding: threadWaitError :: Fd -> IO () threadWaitErrorSTM :: Fd -> IO (STM (), IO ()) to allow for blocking on detecting error condition on file descriptors, similar to what C's select() allows. Cheers, Merijn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From allbery.b at gmail.com Sun Mar 16 15:09:14 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 16 Mar 2014 11:09:14 -0400 Subject: PROPOSAL(S): threadWaitError and threadWaitErrorSTM In-Reply-To: References: Message-ID: On Sun, Mar 16, 2014 at 10:25 AM, Merijn Verstraaten wrote: > threadWaitError :: Fd -> IO () > threadWaitErrorSTM :: Fd -> IO (STM (), IO ()) > > to allow for blocking on detecting error condition on file descriptors, > similar to what C's select() allows. > If you mean the third bitmask, it is not for errors (notwithstanding the documentation on some systems); an "exceptional condition" is not an error, it's MSG_OOB data. Errors show as "ready" on the appropriate mask (read or write) since a read (resp. write) will return immediately with the error instead of blocking. See http://stackoverflow.com/questions/1342712/nix-select-and-exceptfds-errorfds-semanticsand http://man7.org/linux/man-pages/man2/select_tut.2.html for more information. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From tab at snarc.org Sun Mar 16 16:30:22 2014 From: tab at snarc.org (Vincent Hanquez) Date: Sun, 16 Mar 2014 16:30:22 +0000 Subject: breath of life for dataenc lib In-Reply-To: References: Message-ID: <5325D19E.7030501@snarc.org> On 2014-03-15 17:52, Carter Schonwald wrote: > ccing Libraries (forgot) > > > On Sat, Mar 15, 2014 at 1:36 PM, Carter Schonwald > > wrote: > > > Hey All, > Dataenc is needed for building darcs, and currently doesn't build > on 7.8 without some easy patching (i'm also trying to mod the > tesing code to use the cabal test suite support but that doesn't > seem to work). I couldn't find a repo online so i started one here > https://github.com/cartazio/dataenc > > @magnus, Are you still game for continuing to maintain it? (the > hackage docs indicate that you have uploader acls but also that > theres no maintainer per se and theres no repo online) > I'm pretty sure that Magnus is now only maintaining sandi: https://github.com/joeyh/git-annex/pull/15 http://hackage.haskell.org/package/sandi Looks like dataenc has not been marked as deprecated though (probably because the name change predates the hackage change where you can set deprecated yourself) -- Vincent From carter.schonwald at gmail.com Sun Mar 16 17:04:00 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 16 Mar 2014 13:04:00 -0400 Subject: breath of life for dataenc lib In-Reply-To: <5325D19E.7030501@snarc.org> References: <5325D19E.7030501@snarc.org> Message-ID: ummmm, that doesn't help darcs people :'( On Sun, Mar 16, 2014 at 12:30 PM, Vincent Hanquez wrote: > On 2014-03-15 17:52, Carter Schonwald wrote: > >> ccing Libraries (forgot) >> >> >> >> On Sat, Mar 15, 2014 at 1:36 PM, Carter Schonwald < >> carter.schonwald at gmail.com > wrote: >> >> >> Hey All, >> Dataenc is needed for building darcs, and currently doesn't build >> on 7.8 without some easy patching (i'm also trying to mod the >> tesing code to use the cabal test suite support but that doesn't >> seem to work). I couldn't find a repo online so i started one here >> https://github.com/cartazio/dataenc >> >> @magnus, Are you still game for continuing to maintain it? (the >> hackage docs indicate that you have uploader acls but also that >> theres no maintainer per se and theres no repo online) >> >> > I'm pretty sure that Magnus is now only maintaining sandi: > > https://github.com/joeyh/git-annex/pull/15 > > http://hackage.haskell.org/package/sandi > > Looks like dataenc has not been marked as deprecated though (probably > because the name change predates the hackage change where you can set > deprecated yourself) > > -- > Vincent > -------------- next part -------------- An HTML attachment was scrubbed... URL: From merijn at inconsistent.nl Sun Mar 16 17:16:08 2014 From: merijn at inconsistent.nl (Merijn Verstraaten) Date: Sun, 16 Mar 2014 18:16:08 +0100 Subject: PROPOSAL(S): threadWaitError and threadWaitErrorSTM In-Reply-To: References: Message-ID: I just went with the common documentation name, I know this includes out-of-band data, etc. If it makes you happier, feel free to consider this proposal with s/Error/Exceptional, regardless of how it's called, it'd be nice if we could use this from within Haskell. Cheers, Merijn On Mar 16, 2014, at 16:09 , Brandon Allbery wrote: > On Sun, Mar 16, 2014 at 10:25 AM, Merijn Verstraaten wrote: > threadWaitError :: Fd -> IO () > threadWaitErrorSTM :: Fd -> IO (STM (), IO ()) > > to allow for blocking on detecting error condition on file descriptors, similar to what C's select() allows. > > If you mean the third bitmask, it is not for errors (notwithstanding the documentation on some systems); an "exceptional condition" is not an error, it's MSG_OOB data. Errors show as "ready" on the appropriate mask (read or write) since a read (resp. write) will return immediately with the error instead of blocking. > > See http://stackoverflow.com/questions/1342712/nix-select-and-exceptfds-errorfds-semantics and http://man7.org/linux/man-pages/man2/select_tut.2.html for more information. > > -- > brandon s allbery kf8nh sine nomine associates > allbery.b at gmail.com ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From magnus at therning.org Sun Mar 16 17:23:06 2014 From: magnus at therning.org (Magnus Therning) Date: Sun, 16 Mar 2014 18:23:06 +0100 Subject: breath of life for dataenc lib In-Reply-To: References: Message-ID: <20140316172306.GA1100@tatooine.lan> On Sat, Mar 15, 2014 at 1:36 PM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > Hey All, > Dataenc is needed for building darcs, and currently doesn't build on 7.8 > without some easy patching (i'm also trying to mod the tesing code to use > the cabal test suite support but that doesn't seem to work). I couldn't > find a repo online so i started one here > https://github.com/cartazio/dataenc The "official" repo can be found at https://github.com/magthe/dataenc > @magnus, Are you still game for continuing to maintain it? (the hackage > docs indicate that you have uploader acls but also that theres no > maintainer per se and theres no repo online) > > thoughts? I disowned it quite a while ago and can't say I'm very interested in picking up formal maintenance again. I wouldn't mind accepting a pull request and uploading a new version to Hackage as a one-off though. As Vincent pointed out I consider sandi[1] to be the replacement of dataenc. The API is similar enough that it should be trivial to modify darcs to use sandi instead. If it turns out to not be trivial I'm very likely to look at that as a bug of sandi itself. :) /M [1]: http://hackage.haskell.org/package/sandi -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From andreas.voellmy at gmail.com Mon Mar 17 13:23:10 2014 From: andreas.voellmy at gmail.com (Andreas Voellmy) Date: Mon, 17 Mar 2014 09:23:10 -0400 Subject: PROPOSAL(S): threadWaitError and threadWaitErrorSTM In-Reply-To: References: Message-ID: Hi Merijn, I see how you'd wait for exceptional conditions using select(). Epoll is a bit different... How would you do it with epoll? Is it using the EPOLLPRI event type? Andi On Sun, Mar 16, 2014 at 1:16 PM, Merijn Verstraaten wrote: > I just went with the common documentation name, I know this includes > out-of-band data, etc. If it makes you happier, feel free to consider this > proposal with s/Error/Exceptional, regardless of how it's called, it'd be > nice if we could use this from within Haskell. > > Cheers, > Merijn > > > On Mar 16, 2014, at 16:09 , Brandon Allbery wrote: > > On Sun, Mar 16, 2014 at 10:25 AM, Merijn Verstraaten < > merijn at inconsistent.nl> wrote: > >> threadWaitError :: Fd -> IO () >> threadWaitErrorSTM :: Fd -> IO (STM (), IO ()) >> >> to allow for blocking on detecting error condition on file descriptors, >> similar to what C's select() allows. >> > > If you mean the third bitmask, it is not for errors (notwithstanding the > documentation on some systems); an "exceptional condition" is not an error, > it's MSG_OOB data. Errors show as "ready" on the appropriate mask (read or > write) since a read (resp. write) will return immediately with the error > instead of blocking. > > See > http://stackoverflow.com/questions/1342712/nix-select-and-exceptfds-errorfds-semanticsand > http://man7.org/linux/man-pages/man2/select_tut.2.html for more > information. > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b at gmail.com > ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From merijn at inconsistent.nl Tue Mar 18 10:46:01 2014 From: merijn at inconsistent.nl (Merijn Verstraaten) Date: Tue, 18 Mar 2014 11:46:01 +0100 Subject: PROPOSAL(S): threadWaitError and threadWaitErrorSTM In-Reply-To: References: Message-ID: <4B07EB51-F86A-4524-9C79-C7141FDEB1FA@inconsistent.nl> Seems rather simple, just use epoll's EPOLLERR event type. There's more types (like the EPOLLPRI type you mentioned), but I would not argue for adding those as such events may not be portable to platforms that don't support epoll (i.e. platforms that only have kqueue/select), whereas EPOLLERR should be available in some form for all platforms. Cheers, Merijn On Mar 17, 2014, at 14:23 , Andreas Voellmy wrote: > Hi Merijn, > > I see how you'd wait for exceptional conditions using select(). Epoll is a bit different... How would you do it with epoll? Is it using the EPOLLPRI event type? > > Andi > > > On Sun, Mar 16, 2014 at 1:16 PM, Merijn Verstraaten wrote: > I just went with the common documentation name, I know this includes out-of-band data, etc. If it makes you happier, feel free to consider this proposal with s/Error/Exceptional, regardless of how it's called, it'd be nice if we could use this from within Haskell. > > Cheers, > Merijn > > > On Mar 16, 2014, at 16:09 , Brandon Allbery wrote: > >> On Sun, Mar 16, 2014 at 10:25 AM, Merijn Verstraaten wrote: >> threadWaitError :: Fd -> IO () >> threadWaitErrorSTM :: Fd -> IO (STM (), IO ()) >> >> to allow for blocking on detecting error condition on file descriptors, similar to what C's select() allows. >> >> If you mean the third bitmask, it is not for errors (notwithstanding the documentation on some systems); an "exceptional condition" is not an error, it's MSG_OOB data. Errors show as "ready" on the appropriate mask (read or write) since a read (resp. write) will return immediately with the error instead of blocking. >> >> See http://stackoverflow.com/questions/1342712/nix-select-and-exceptfds-errorfds-semantics and http://man7.org/linux/man-pages/man2/select_tut.2.html for more information. >> >> -- >> brandon s allbery kf8nh sine nomine associates >> allbery.b at gmail.com ballbery at sinenomine.net >> unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From johan.tibell at gmail.com Tue Mar 18 18:18:48 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue, 18 Mar 2014 19:18:48 +0100 Subject: PVP proposal: don't require major version bump when adding non-orphan instances In-Reply-To: References: <530DE47A.8080007@henning-thielemann.de> <530E78A2.1060802@earth.li> Message-ID: The deadline have now passed. I think everyone who was against the prior proposal changed their mind as I clarified this proposal. I will make the changes to the PVP. On Thu, Feb 27, 2014 at 1:05 AM, Erik Hesselink wrote: > On Thu, Feb 27, 2014 at 12:47 AM, Ivan Lazar Miljenovic > wrote: > > On 27 February 2014 10:28, Ganesh Sittampalam wrote: > >> On 26/02/2014 14:59, Johan Tibell wrote: > >>> On Wed, Feb 26, 2014 at 1:56 PM, Henning Thielemann > >>> >>> > wrote: > >>> > >>> As far as I remember we already discussed this: > >>> > >>> > http://www.haskell.org/__pipermail/libraries/2011-__December/017337.html > >>> < > http://www.haskell.org/pipermail/libraries/2011-December/017337.html> > >>> > >>> > >>> Apparently I'm getting old and forgetful. :/ > >>> > >>> By looking at the last thread and this thread I think the following > >>> people support the proposal: > >>> > >>> Johan Tibell > >>> Michael Snoyman > >>> Christian Maeder > >>> Henning Thielemann > >>> > >>> And the following people against: > >>> > >>> Ganesh Sittampalam > >>> Ivan Lazar Miljenovic > >>> Erik Hesselink > >> > >> I think my previous opposition was based on the fact that orphan > >> instances appeared to be ruled out altogether by the proposal then. > >> > >> Given the statement in your new proposal "If a package defines an orphan > >> instance, it must depend on the minor version of the packages", I'm now > >> a +1. > > > > I think I was the same, so I'm now +1 as well. > > I've also changed my mind, depending on a minor version (or going with > a newtype) seems good enough. I guess that's all the -1's... > > Erik > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.voellmy at gmail.com Fri Mar 21 12:16:50 2014 From: andreas.voellmy at gmail.com (Andreas Voellmy) Date: Fri, 21 Mar 2014 08:16:50 -0400 Subject: PROPOSAL(S): threadWaitError and threadWaitErrorSTM In-Reply-To: <4B07EB51-F86A-4524-9C79-C7141FDEB1FA@inconsistent.nl> References: <4B07EB51-F86A-4524-9C79-C7141FDEB1FA@inconsistent.nl> Message-ID: epoll automatically always waits on EPOLLERR, and it looks like this will just lead to threadWait functions to return from the call. Can you write a small test case to check if the current behavior works (or not) with existing threadWait functions? Andi On Tue, Mar 18, 2014 at 6:46 AM, Merijn Verstraaten wrote: > Seems rather simple, just use epoll's EPOLLERR event type. There's more > types (like the EPOLLPRI type you mentioned), but I would not argue for > adding those as such events may not be portable to platforms that don't > support epoll (i.e. platforms that only have kqueue/select), whereas > EPOLLERR should be available in some form for all platforms. > > Cheers, > Merijn > > > On Mar 17, 2014, at 14:23 , Andreas Voellmy wrote: > > Hi Merijn, > > I see how you'd wait for exceptional conditions using select(). Epoll is a > bit different... How would you do it with epoll? Is it using the EPOLLPRI > event type? > > Andi > > > On Sun, Mar 16, 2014 at 1:16 PM, Merijn Verstraaten < > merijn at inconsistent.nl> wrote: > >> I just went with the common documentation name, I know this includes >> out-of-band data, etc. If it makes you happier, feel free to consider this >> proposal with s/Error/Exceptional, regardless of how it's called, it'd be >> nice if we could use this from within Haskell. >> >> Cheers, >> Merijn >> >> >> On Mar 16, 2014, at 16:09 , Brandon Allbery wrote: >> >> On Sun, Mar 16, 2014 at 10:25 AM, Merijn Verstraaten < >> merijn at inconsistent.nl> wrote: >> >>> threadWaitError :: Fd -> IO () >>> threadWaitErrorSTM :: Fd -> IO (STM (), IO ()) >>> >>> to allow for blocking on detecting error condition on file descriptors, >>> similar to what C's select() allows. >>> >> >> If you mean the third bitmask, it is not for errors (notwithstanding the >> documentation on some systems); an "exceptional condition" is not an error, >> it's MSG_OOB data. Errors show as "ready" on the appropriate mask (read or >> write) since a read (resp. write) will return immediately with the error >> instead of blocking. >> >> See >> http://stackoverflow.com/questions/1342712/nix-select-and-exceptfds-errorfds-semanticsand >> http://man7.org/linux/man-pages/man2/select_tut.2.html for more >> information. >> >> -- >> brandon s allbery kf8nh sine nomine >> associates >> allbery.b at gmail.com >> ballbery at sinenomine.net >> unix, openafs, kerberos, infrastructure, xmonad >> http://sinenomine.net >> >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coreyoconnor at gmail.com Fri Mar 21 17:08:44 2014 From: coreyoconnor at gmail.com (Corey O'Connor) Date: Fri, 21 Mar 2014 10:08:44 -0700 Subject: Burning more bridges (mostly numeric ones) In-Reply-To: <1393247600013-5744545.post@n5.nabble.com> References: <1393247600013-5744545.post@n5.nabble.com> Message-ID: On #3: The library numeric-prelude achieves many of these goals (Plus a bunch more). If the experiences of using numeric-prelude are positive then using this or a subset of this as the standard numeric prelude might resolve these goals easily. http://hackage.haskell.org/package/numeric-prelude -Corey O'Connor coreyoconnor at gmail.com http://corebotllc.com/ On Mon, Feb 24, 2014 at 5:13 AM, harry wrote: > Carter Charbonneau wrote > > 2. Move Semigroup into Prelude > > > > 2.1 Make Monoid depend on Semigroup. > > NonEmpty seems to be frequently reimplemented, particularly by beginners. > Including Semigroup in Prelude would save all this duplication. > > > > -- > View this message in context: > http://haskell.1045720.n5.nabble.com/Burning-more-bridges-mostly-numeric-ones-tp5744526p5744545.html > Sent from the Haskell - Libraries mailing list archive at Nabble.com. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri Mar 21 17:22:55 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 21 Mar 2014 13:22:55 -0400 Subject: Burning more bridges (mostly numeric ones) In-Reply-To: References: <1393247600013-5744545.post@n5.nabble.com> Message-ID: lets not talk about this while people are buried with 7.8 release engineering, please :) there are certainly good ideas in Henning's (amazing) work, HOWEVER, one thing people often forget is that theres more than one valid computational formalization of a given mathematical concept (which itself can often have a multitude of equivalent definitions). and thats even ignoring the fact that the haddocks are full of readable Qualified names like "class C a => C a where" :) On Fri, Mar 21, 2014 at 1:08 PM, Corey O'Connor wrote: > On #3: The library numeric-prelude achieves many of these goals (Plus a > bunch more). If the experiences of using numeric-prelude are positive then > using this or a subset of this as the standard numeric prelude might > resolve these goals easily. > > http://hackage.haskell.org/package/numeric-prelude > > -Corey O'Connor > coreyoconnor at gmail.com > http://corebotllc.com/ > > > On Mon, Feb 24, 2014 at 5:13 AM, harry wrote: > >> Carter Charbonneau wrote >> > 2. Move Semigroup into Prelude >> > >> > 2.1 Make Monoid depend on Semigroup. >> >> NonEmpty seems to be frequently reimplemented, particularly by beginners. >> Including Semigroup in Prelude would save all this duplication. >> >> >> >> -- >> View this message in context: >> http://haskell.1045720.n5.nabble.com/Burning-more-bridges-mostly-numeric-ones-tp5744526p5744545.html >> Sent from the Haskell - Libraries mailing list archive at Nabble.com. >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From schlepptop at henning-thielemann.de Fri Mar 21 19:10:46 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Fri, 21 Mar 2014 20:10:46 +0100 Subject: Burning more bridges (mostly numeric ones) In-Reply-To: References: <1393247600013-5744545.post@n5.nabble.com> Message-ID: <532C8EB6.4080806@henning-thielemann.de> Am 21.03.2014 18:22, schrieb Carter Schonwald: > lets not talk about this while people are buried with 7.8 release > engineering, please :) > > there are certainly good ideas in Henning's (amazing) work, > HOWEVER, one thing people often forget is that theres more than one > valid computational formalization of a given mathematical concept (which > itself can often have a multitude of equivalent definitions). > > and thats even ignoring the fact that the haddocks are full of readable > Qualified names like > "classC > a > => C a where" :) I tried three times to make Haddock show qualifications, but it is really frustrating. Last time I tried I despaired of GHC data structures. Somewhere the qualification must have been recognized by GHC but it is thrown away early and hard to restore. From tob.brandt at gmail.com Sat Mar 22 07:22:39 2014 From: tob.brandt at gmail.com (Tobias Brandt) Date: Sat, 22 Mar 2014 08:22:39 +0100 Subject: Burning more bridges (mostly numeric ones) In-Reply-To: <532C8EB6.4080806@henning-thielemann.de> References: <1393247600013-5744545.post@n5.nabble.com> <532C8EB6.4080806@henning-thielemann.de> Message-ID: On 21 March 2014 20:10, Henning Thielemann wrote: > > > I tried three times to make Haddock show qualifications, but it is really > frustrating. Last time I tried I despaired of GHC data structures. > Somewhere the qualification must have been recognized by GHC but it is > thrown away early and hard to restore. I actually implemented qualified names in haddock a long time ago ( http://projects.haskell.org/pipermail/haddock/2010-August/000649.html) exactly because of numeric-prelude. Here is a screenshot: http://projects.haskell.org/pipermail/haddock/attachments/20100828/e91f52de/attachment-0001.png However, I don't think that patch would still work, but it might give you some hints how to do it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From schlepptop at henning-thielemann.de Sat Mar 22 07:28:19 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Sat, 22 Mar 2014 08:28:19 +0100 Subject: Burning more bridges (mostly numeric ones) In-Reply-To: References: <1393247600013-5744545.post@n5.nabble.com> <532C8EB6.4080806@henning-thielemann.de> Message-ID: <532D3B93.9030406@henning-thielemann.de> Am 22.03.2014 08:22, schrieb Tobias Brandt: > On 21 March 2014 20:10, Henning Thielemann > > wrote: > > > I tried three times to make Haddock show qualifications, but it is > really frustrating. Last time I tried I despaired of GHC data > structures. Somewhere the qualification must have been recognized by > GHC but it is thrown away early and hard to restore. > > > I actually implemented qualified names in haddock a long time ago > (http://projects.haskell.org/pipermail/haddock/2010-August/000649.html) > exactly because of numeric-prelude. > Here is a screenshot: > http://projects.haskell.org/pipermail/haddock/attachments/20100828/e91f52de/attachment-0001.png > > However, I don't think that patch would still work, but it might give > you some hints how to do it. I know, but as far as I remember it was not completely satisfying. I prefered abbreviated qualifications, e.g. Field.C instead of Algebra.Field.C and there were differences between imports from modules of the same package and imports from external modules. http://trac.haskell.org/haddock/ticket/22 From tob.brandt at gmail.com Sat Mar 22 07:43:46 2014 From: tob.brandt at gmail.com (Tobias Brandt) Date: Sat, 22 Mar 2014 08:43:46 +0100 Subject: Burning more bridges (mostly numeric ones) In-Reply-To: <532D3B93.9030406@henning-thielemann.de> References: <1393247600013-5744545.post@n5.nabble.com> <532C8EB6.4080806@henning-thielemann.de> <532D3B93.9030406@henning-thielemann.de> Message-ID: On 22 March 2014 08:28, Henning Thielemann wrote: > > I know, but as far as I remember it was not completely satisfying. I > prefered abbreviated qualifications, e.g. Field.C instead of > Algebra.Field.C and there were differences between imports from modules of > the same package and imports from external modules. > > http://trac.haskell.org/haddock/ticket/22 > > There are four modes of qualification in my patch: * None: as now * Full: everything is fully qualified * Local: only imported names are fully qualified, like in the screenshot * Relative: like local, but prefixes in the same hierarchy are stripped. Algebra.Field.C would become Field.C when shown in the documentation for Algebra.VectorSpace. The last one probably comes closest to what you want. Preserving the original qualification (as written in the source code) would probably be perfect, but that's already thrown away when we get to it in haddock. -------------- next part -------------- An HTML attachment was scrubbed... URL: From winterkoninkje at gmail.com Sat Mar 22 21:09:46 2014 From: winterkoninkje at gmail.com (wren romano) Date: Sat, 22 Mar 2014 17:09:46 -0400 Subject: Burning more bridges (mostly numeric ones) In-Reply-To: References: <1393247600013-5744545.post@n5.nabble.com> Message-ID: On Fri, Mar 21, 2014 at 1:08 PM, Corey O'Connor wrote: > On #3: The library numeric-prelude achieves many of these goals (Plus a > bunch more). If the experiences of using numeric-prelude are positive then > using this or a subset of this as the standard numeric prelude might resolve > these goals easily. > > http://hackage.haskell.org/package/numeric-prelude One of my major complaints against numeric-prelude is the same as my major complaint against every other such project I've seen put forward: they completely ignore semirings and related structures. Semirings are utterly ubiquitous and this insistence that every notion of addition comes equipped with subtraction is ridiculous. In my work I deal with semirings and semimodules on a daily basis, whereas rings/modules show up far less often, let alone fields/vectorspaces. When not dealing with semirings, the other structures I work with are similarly general (e.g., semigroups, quasigroups,...). But this entire area of algebra is completely overlooked by those libraries which start at abelian groups and then run headlong for normed Euclidean vector spaces. My main complaint against the Num class is that it already assumes too much structure. So developing the hierarchy even further up than Num does little to help me. -- Live well, ~wren From carter.schonwald at gmail.com Sat Mar 22 21:28:27 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 22 Mar 2014 17:28:27 -0400 Subject: Burning more bridges (mostly numeric ones) In-Reply-To: References: <1393247600013-5744545.post@n5.nabble.com> Message-ID: agreed, hence my earlier remarks :) On Sat, Mar 22, 2014 at 5:09 PM, wren romano wrote: > On Fri, Mar 21, 2014 at 1:08 PM, Corey O'Connor > wrote: > > On #3: The library numeric-prelude achieves many of these goals (Plus a > > bunch more). If the experiences of using numeric-prelude are positive > then > > using this or a subset of this as the standard numeric prelude might > resolve > > these goals easily. > > > > http://hackage.haskell.org/package/numeric-prelude > > One of my major complaints against numeric-prelude is the same as my > major complaint against every other such project I've seen put > forward: they completely ignore semirings and related structures. > > Semirings are utterly ubiquitous and this insistence that every notion > of addition comes equipped with subtraction is ridiculous. In my work > I deal with semirings and semimodules on a daily basis, whereas > rings/modules show up far less often, let alone fields/vectorspaces. > When not dealing with semirings, the other structures I work with are > similarly general (e.g., semigroups, quasigroups,...). But this entire > area of algebra is completely overlooked by those libraries which > start at abelian groups and then run headlong for normed Euclidean > vector spaces. > > My main complaint against the Num class is that it already assumes too > much structure. So developing the hierarchy even further up than Num > does little to help me. > > -- > Live well, > ~wren > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bart at cs.pdx.edu Sun Mar 23 00:58:03 2014 From: bart at cs.pdx.edu (Bart Massey) Date: Sat, 22 Mar 2014 17:58:03 -0700 Subject: Burning more bridges (mostly numeric ones) In-Reply-To: References: <1393247600013-5744545.post@n5.nabble.com> Message-ID: My complaint with numeric-prelude is that it doesn't (and arguably can't) fix the problems that for me make Haskell borderline usable for actual engineering work involving actual "normal" numbers, and genuinely somewhat unusable for teaching: Off the top of my head: * The lack of implicit conversions (except for the weird defaulting of literals, which means that I am constantly writing `fromIntegral` and `toRealFrac` in places where there is only one reasonable choice of type conversion, and occasionally having things just malfunction because I didn't quite understand what these conversion functions would give me as a result. Prelude> 3 + 3.5 6.5 Prelude> let x = 3 Prelude> x + 3.5 :4:5: No instance for (Fractional Integer) arising from the literal `3.5' Possible fix: add an instance declaration for (Fractional Integer) In the second argument of `(+)', namely `3.5' In the expression: x + 3.5 In an equation for `it': it = x + 3.5 Prelude> I mean, seriously? We expect newbies to just roll with this kind of thing? Even worse, the same sort of thing happens when trying to add a `Data.Word.Word` to an `Integer`. This is a totally safe conversion if you just let the result be `Integer`. * The inability of Haskell to handle unary negation sanely, which means that I and newbies alike are constantly having to figure things out and parenthesize. From my observations of students, this is a huge barrier to Haskell adoption: people who can't write 3 + -5 just give up on a language. (I love the current error message here, "cannot mix `+' [infixl 6] and prefix `-' [infixl 6] in the same infix expression", which is about as self-diagnosing of a language failing as any error message I've ever seen.) * The multiplicity of exponentiation functions, one of which looks exactly like C's XOR operator, which I've watched trip up newbies a bunch of times. (Indeed, NumericPrelude seems to have added more of these, including the IMHO poorly-named (^-) which has nothing to do with numeric negation as far as I can tell. See "unary negation" above.) * The incredible awkwardness of hex/octal/binary input handling, which requires digging a function with an odd and awkward return convention (`readHex`) out of an oddly-chosen module (or rolling my own) in order to read a hex value. (Output would be just as bad except for `Text.Printf` as a safety hatch.) Lord knows what you're supposed to do if your number might have a C-style base specifier on the front, other than the obvious ugly brute-force thing? * Defaulting numeric types with "-Wall" on producing scary warnings. Prelude> 3 + 3 :2:3: Warning: Defaulting the following constraint(s) to type `Integer' (Num a0) arising from a use of `+' In the expression: 3 + 3 In an equation for `it': it = 3 + 3 :2:3: Warning: Defaulting the following constraint(s) to type `Integer' (Num a0) arising from a use of `+' at :2:3 (Show a0) arising from a use of `print' at :2:1-5 In the expression: 3 + 3 In an equation for `it': it = 3 + 3 6 and similarly for 3.0 + 3.0. If you can't even write simple addition without turning off or ignoring warnings, well, I dunno. Something. Oh, and try to get rid of those warnings. The only ways I know are `3 + 3 :: Integer` or `(3 :: Integer) + 3`, both of which make code read like a bad joke. Of course, if you write everything to take specific integral or floating types rather than `Integral` or `RealFloat` or `Num` this problem mostly goes away. So everyone does, turning potentially general code into needlessly over-specific code. Not sure I'm done, but running out of steam. But yeah, while I'm fine with fancy algebraic stuff getting fixed, I'd also like to see simple grade-school-style arithmetic work sanely. That would let me teach Haskell more easily as well as letting me write better, clearer, more correct Haskell for that majority of my real-world problems that involve grade-school numbers. --Bart From ivan.miljenovic at gmail.com Sun Mar 23 06:10:12 2014 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Sun, 23 Mar 2014 17:10:12 +1100 Subject: Burning more bridges (mostly numeric ones) In-Reply-To: References: <1393247600013-5744545.post@n5.nabble.com> Message-ID: On 23 March 2014 11:58, Bart Massey wrote: > My complaint with numeric-prelude is that it doesn't (and arguably > can't) fix the problems that for me make Haskell borderline usable for > actual engineering work involving actual "normal" numbers, and > genuinely somewhat unusable for teaching: Off the top of my head: > > * The lack of implicit conversions (except for the weird defaulting of > literals, which means that I am constantly writing `fromIntegral` and > `toRealFrac` in places where there is only one reasonable choice of > type conversion, and occasionally having things just malfunction > because I didn't quite understand what these conversion functions > would give me as a result. > > Prelude> 3 + 3.5 > 6.5 > Prelude> let x = 3 > Prelude> x + 3.5 > > :4:5: > No instance for (Fractional Integer) arising from the literal `3.5' > Possible fix: add an instance declaration for (Fractional Integer) > In the second argument of `(+)', namely `3.5' > In the expression: x + 3.5 > In an equation for `it': it = x + 3.5 > Prelude> > > I mean, seriously? We expect newbies to just roll with this kind of thing? Isn't this more of a ghci issue than a Haskell issue? I actually think it's good behaviour that - in actual code, not defaulted numerals in ghci - we need to explicitly convert between types rather than have a so-far-Integer-value automagically convert to Double. > > Even worse, the same sort of thing happens when trying to add a > `Data.Word.Word` to an `Integer`. This is a totally safe conversion if > you just let the result be `Integer`. What would be the type of such an operation be? I think we'd need some kind of new typeclass to denote the "base value", which would make the actual type signature be much more hairy. > > * The inability of Haskell to handle unary negation sanely, which > means that I and newbies alike are constantly having to figure things > out and parenthesize. From my observations of students, this is a huge > barrier to Haskell adoption: people who can't write 3 + -5 just give > up on a language. (I love the current error message here, "cannot mix > `+' [infixl 6] and prefix `-' [infixl 6] in the same infix > expression", which is about as self-diagnosing of a language failing > as any error message I've ever seen.) This is arguably the fault of mathematics for overloading the - operator :p > > * The multiplicity of exponentiation functions, one of which looks > exactly like C's XOR operator, which I've watched trip up newbies a > bunch of times. (Indeed, NumericPrelude seems to have added more of > these, including the IMHO poorly-named (^-) which has nothing to do > with numeric negation as far as I can tell. See "unary negation" > above.) > > * The incredible awkwardness of hex/octal/binary input handling, which > requires digging a function with an odd and awkward return convention > (`readHex`) out of an oddly-chosen module (or rolling my own) in order > to read a hex value. (Output would be just as bad except for > `Text.Printf` as a safety hatch.) Lord knows what you're supposed to > do if your number might have a C-style base specifier on the front, > other than the obvious ugly brute-force thing? > > * Defaulting numeric types with "-Wall" on producing scary warnings. > > Prelude> 3 + 3 > > :2:3: Warning: > Defaulting the following constraint(s) to type `Integer' > (Num a0) arising from a use of `+' > In the expression: 3 + 3 > In an equation for `it': it = 3 + 3 > > :2:3: Warning: > Defaulting the following constraint(s) to type `Integer' > (Num a0) arising from a use of `+' at :2:3 > (Show a0) arising from a use of `print' at :2:1-5 > In the expression: 3 + 3 > In an equation for `it': it = 3 + 3 > 6 > > and similarly for 3.0 + 3.0. If you can't even write simple addition > without turning off or ignoring warnings, well, I dunno. Something. > Oh, and try to get rid of those warnings. The only ways I know are `3 > + 3 :: Integer` or `(3 :: Integer) + 3`, both of which make code read > like a bad joke. So above you didn't like how ghci defaulted to types too early, now you're complaining that it's _not_ defaulting? Or just that it gives you a warning that it's doing the defaulting? > > Of course, if you write everything to take specific integral or > floating types rather than `Integral` or `RealFloat` or `Num` this > problem mostly goes away. So everyone does, turning potentially > general code into needlessly over-specific code. > > > Not sure I'm done, but running out of steam. But yeah, while I'm fine > with fancy algebraic stuff getting fixed, I'd also like to see simple > grade-school-style arithmetic work sanely. That would let me teach > Haskell more easily as well as letting me write better, clearer, more > correct Haskell for that majority of my real-world problems that > involve grade-school numbers. > > --Bart > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From ekmett at gmail.com Sun Mar 23 07:11:48 2014 From: ekmett at gmail.com (Edward Kmett) Date: Sun, 23 Mar 2014 03:11:48 -0400 Subject: Burning more bridges (mostly numeric ones) In-Reply-To: References: <1393247600013-5744545.post@n5.nabble.com> Message-ID: On Sat, Mar 22, 2014 at 8:58 PM, Bart Massey wrote: > * The lack of implicit conversions (except for the weird defaulting of > literals, which means that I am constantly writing `fromIntegral` and > `toRealFrac` in places where there is only one reasonable choice of > type conversion, and occasionally having things just malfunction > because I didn't quite understand what these conversion functions > would give me as a result. > > Prelude> 3 + 3.5 > 6.5 > Prelude> let x = 3 > Prelude> x + 3.5 > > :4:5: > No instance for (Fractional Integer) arising from the literal `3.5' > Possible fix: add an instance declaration for (Fractional Integer) > In the second argument of `(+)', namely `3.5' > In the expression: x + 3.5 > In an equation for `it': it = x + 3.5 > Prelude> > > I mean, seriously? We expect newbies to just roll with this kind of thing? > Actually, we don't expect them to roll with it any more. >>> let x = 3 >>> x + 3.5 6.5 ghci turns no NoMonomorphismRestriction on newer GHCs. To me that issue is largely independent of changes to the numeric hierarchy, though I confess I'd largely tuned out this thread and am just now skimming backwards a bit. That said, implicit conversions are something where personally I feel Haskell does take the right approach. It is the only language I have access to where I can reason about the semantics of (+) sanely and extend the set of types. > Even worse, the same sort of thing happens when trying to add a > `Data.Word.Word` to an `Integer`. This is a totally safe conversion if > you just let the result be `Integer`. > The problem arises when you allow for users to extend the set of numeric types like Haskell does. We have a richer menagerie of exotic numerical types than any other language, explicitly because of our adherence to a stricter discipline and moving the coercion down to the literal rather than up to every function application. Because of that type inference works better. It can flow both forward and backwards through (+), whereas the approach you advocate is strictly less powerful. You have to give up overloading of numeric literals, and in essence this gives up on the flexibility of the numerical tower to handle open sets of new numerical types. As someone who works with compensated arithmetic, automatic differentiaton, arbitrary precision floating point, interval arithmetic, Taylor models, and all sorts of other numerical types in Haskell, basically you're almost asking me to give up all the things that work in this language to go back to a scheme style fixed numerical tower. > * The inability of Haskell to handle unary negation sanely, which > means that I and newbies alike are constantly having to figure things > out and parenthesize. From my observations of students, this is a huge > barrier to Haskell adoption: people who can't write 3 + -5 just give > up on a language. (I love the current error message here, "cannot mix > `+' [infixl 6] and prefix `-' [infixl 6] in the same infix > expression", which is about as self-diagnosing of a language failing > as any error message I've ever seen.) > That is probably fixable by getting creative in the language grammar. I note it particularly because our Haskell like language Ermine here at work gets it right. ;) > * The multiplicity of exponentiation functions, one of which looks > exactly like C's XOR operator, which I've watched trip up newbies a > bunch of times. (Indeed, NumericPrelude seems to have added more of > these, including the IMHO poorly-named (^-) which has nothing to do > with numeric negation as far as I can tell. See "unary negation" > above.) > It is unfortunate, but there really is a distinction being made. * The incredible awkwardness of hex/octal/binary input handling, which > requires digging a function with an odd and awkward return convention > (`readHex`) out of an oddly-chosen module (or rolling my own) in order > to read a hex value. (Output would be just as bad except for > `Text.Printf` as a safety hatch.) Lord knows what you're supposed to > do if your number might have a C-style base specifier on the front, > other than the obvious ugly brute-force thing? > A lot of people these days turn to lens for that: >>> :m + Numeric.Lens Control.Lens >>> "7b" ^? hex Just 123 >>> hex # 123 "7b" > * Defaulting numeric types with "-Wall" on producing scary warnings. > > Prelude> 3 + 3 > > :2:3: Warning: > Defaulting the following constraint(s) to type `Integer' > (Num a0) arising from a use of `+' > In the expression: 3 + 3 > In an equation for `it': it = 3 + 3 > > :2:3: Warning: > Defaulting the following constraint(s) to type `Integer' > (Num a0) arising from a use of `+' at :2:3 > (Show a0) arising from a use of `print' at :2:1-5 > In the expression: 3 + 3 > In an equation for `it': it = 3 + 3 > 6 > > and similarly for 3.0 + 3.0. If you can't even write simple addition > without turning off or ignoring warnings, well, I dunno. Something. > Oh, and try to get rid of those warnings. The only ways I know are `3 > + 3 :: Integer` or `(3 :: Integer) + 3`, both of which make code read > like a bad joke. > This is no longer a problem at ghci due to NMR: >>> 3 + 3 6 You can of course use >>> :set -Wall -fno-warn-type-defaults instead of -Wall for cases like >>> 3 == 3 where the type doesn't get picked. -Edward -------------- next part -------------- An HTML attachment was scrubbed... URL: From bart at cs.pdx.edu Sun Mar 23 08:50:43 2014 From: bart at cs.pdx.edu (Bart Massey) Date: Sun, 23 Mar 2014 01:50:43 -0700 Subject: Burning more bridges (mostly numeric ones) In-Reply-To: References: <1393247600013-5744545.post@n5.nabble.com> Message-ID: On Sun, Mar 23, 2014 at 12:11 AM, Edward Kmett wrote: > On Sat, Mar 22, 2014 at 8:58 PM, Bart Massey wrote: >>>> let x = 3 >>>> x + 3.5 > 6.5 > > ghci turns no NoMonomorphismRestriction on newer GHCs. Nice. AFAICT newer means 7.8, which I haven't tried yet. Major improvement. >> Even worse, the same sort of thing happens when trying to add a >> `Data.Word.Word` to an `Integer`. This is a totally safe conversion if >> you just let the result be `Integer`. > > Because of that type inference works better. It can flow both forward and > backwards through (+), whereas the approach you advocate is strictly less > powerful. You have to give up overloading of numeric literals, and in > essence this gives up on the flexibility of the numerical tower to handle > open sets of new numerical types. You obviously know far more about this than me, but I'm not seeing it? AFAICT all I am asking for is numeric subtyping using the normal typeclass mechanism, but with some kind of preference rules that get the subtyping right in "normal" cases? I can certainly agree that I don't want to go toward C's morass of "widening to unsigned" (???) or explicitly-typed numeric literals. I just want a set of type rules that agrees with grade-school mathematics most of the time. I'm sure I'm missing something, and it really is that hard, but if so it makes me sad. >> * The inability of Haskell to handle unary negation sanely, which >> means that I and newbies alike are constantly having to figure things >> out and parenthesize. From my observations of students, this is a huge >> barrier to Haskell adoption: people who can't write 3 + -5 just give >> up on a language. (I love the current error message here, "cannot mix >> `+' [infixl 6] and prefix `-' [infixl 6] in the same infix >> expression", which is about as self-diagnosing of a language failing >> as any error message I've ever seen.) > > > That is probably fixable by getting creative in the language grammar. I note > it particularly because our Haskell like language Ermine here at work gets > it right. ;) Almost every PL I've seen with infix arithmetic gets it right. It's trivial for any operator-precedence parser, and not too hard for other common kinds. In general it would be nice if Haskell allowed arbitrary prefix and postfix unary operators, but I'd settle for a special case for unary minus. >> * The multiplicity of exponentiation functions, one of which looks >> exactly like C's XOR operator, which I've watched trip up newbies a >> bunch of times. (Indeed, NumericPrelude seems to have added more of >> these, including the IMHO poorly-named (^-) which has nothing to do >> with numeric negation as far as I can tell. See "unary negation" >> above.) > > > It is unfortunate, but there really is a distinction being made. I get that. I even get that static-typing exponentiation is hard. (You should see how we did it in Nickle (http://nickle.org) --not because it's good but because it calls out a lot of the problems.) What I don't get is why the names seem so terrible to me, nor why the typechecker can't do more to help reduce the number of needed operators, ideally to one. It might mean extra conversion operators around exponentiation once in a while, I guess? >> * The incredible awkwardness of hex/octal/binary input handling, which >> requires digging a function with an odd and awkward return convention >> (`readHex`) out of an oddly-chosen module (or rolling my own) in order >> to read a hex value. (Output would be just as bad except for >> `Text.Printf` as a safety hatch.) Lord knows what you're supposed to >> do if your number might have a C-style base specifier on the front, >> other than the obvious ugly brute-force thing? > > > A lot of people these days turn to lens for that: > >>>> :m + Numeric.Lens Control.Lens >>>> "7b" ^? hex > Just 123 >>>> hex # 123 > "7b" Nice. Once this really becomes standard, I guess we'll be somewhere. >> * Defaulting numeric types with "-Wall" on producing scary warnings. > This is no longer a problem at ghci due to NMR: > >>>> 3 + 3 > 6 Nice. I'm not sure what to make of something like this (with ghci -Wall -XNoMonomorphismRestriction) >> let discard :: Integral a => a -> (); discard _ = () >> discard 3 :5:1: Warning: Defaulting the following constraint(s) to type `Integer' (Integral a0) arising from a use of `discard' at :5:1-7 (Num a0) arising from the literal `3' at :5:9 In the expression: discard 3 In an equation for `it': it = discard 3 :5:1: Warning: Defaulting the following constraint(s) to type `Integer' (Integral a0) arising from a use of `discard' at :5:1-7 (Num a0) arising from the literal `3' at :5:9 In the expression: discard 3 In an equation for `it': it = discard 3 () I get the feeling I just shouldn't worry about it: there's not much to be done, as this is just a limitation of the static type system and not really Haskell's fault. (Although I wonder why the conversion is warned twice? :-) > You can of course use > >>>> :set -Wall -fno-warn-type-defaults > > instead of -Wall for cases like > >>>> 3 == 3 > > where the type doesn't get picked. Of course. I have no idea what warnings I might be turning off that would actually be useful? Anyway, thanks much for the response! --Bart From ekmett at gmail.com Sun Mar 23 10:13:29 2014 From: ekmett at gmail.com (Edward Kmett) Date: Sun, 23 Mar 2014 06:13:29 -0400 Subject: Burning more bridges (mostly numeric ones) In-Reply-To: References: <1393247600013-5744545.post@n5.nabble.com> Message-ID: On Sun, Mar 23, 2014 at 4:50 AM, Bart Massey wrote: > >> Even worse, the same sort of thing happens when trying to add a > >> `Data.Word.Word` to an `Integer`. This is a totally safe conversion if > >> you just let the result be `Integer`. > > > > Because of that type inference works better. It can flow both forward and > > backwards through (+), whereas the approach you advocate is strictly less > > powerful. You have to give up overloading of numeric literals, and in > > essence this gives up on the flexibility of the numerical tower to handle > > open sets of new numerical types. > > You obviously know far more about this than me, but I'm not seeing it? > AFAICT > all I am asking for is numeric subtyping using the normal typeclass > mechanism, > but with some kind of preference rules that get the subtyping right in > "normal" cases? > I can certainly agree that I don't want to go toward C's morass of > "widening to unsigned" (???) or > explicitly-typed numeric literals. I just want a set of type rules > that agrees with grade-school > mathematics most of the time. I'm sure I'm missing something, and it > really is that hard, but > if so it makes me sad. Let's consider what directions type information flows though (+) class Foo a where (+) :: a -> a -> a Given that kind of class you get (+) :: Foo a => a -> a -> a Now given the result type of an expression you can know the types of both of its argument types. If either argument is determined you can know the type of the other argument and the result as well. Given any one of the arguments or the result type you can know the type of the other two. Consider now the kind of constraint you'd need for widening. class Foo a b c | a b -> c where (+) :: a -> b -> c Now, given both a and b you can know the type of c. But given just the type of c, you know nothing about the type of either of its arguments. a + b :: Int used to tell you that a and b both had to be Int, but now you'd get nothing! Worse, given the type of one argument, you don't get to know the type of the other argument or the result. We went from getting 2 other types from 1 in all directions to getting 1 type from 2 others, in only 1 of 3 cases. The very cases you complained about, where you needed defaulting now happen virtually everywhere! > >> * The multiplicity of exponentiation functions, one of which looks > >> exactly like C's XOR operator, which I've watched trip up newbies a > >> bunch of times. (Indeed, NumericPrelude seems to have added more of > >> these, including the IMHO poorly-named (^-) which has nothing to do > >> with numeric negation as far as I can tell. See "unary negation" > >> above.) > > It is unfortunate, but there really is a distinction being made. > > I get that. I even get that static-typing exponentiation is hard. (You > should see how > we did it in Nickle (http://nickle.org) --not because it's good but > because > it calls out a lot of the problems.) What I don't get is why the names seem > so terrible to me, nor why the typechecker can't do more to help reduce the > number of needed operators, ideally to one. It might mean extra conversion > operators around exponentiation once in a while, I guess? I do think there were at least two genuinely bad ideas in the design of (^) (^^) and (**) originally. Notably the choice in (^) an (^^) to overload on the power's Integral type. More often than not this simply leads to an ambiguous choice for simple cases like x^2. Even if that had that been monomorphized and MPTCs existed when they were defined AND we wanted to use fundeps in the numerical tower, you'd still need at least two operators. You can't overload cleanly between (^) and (**) because instance selection would overlap. Both of their right sides unify: (^) :: ... => a -> Int -> a (**) :: ... => a -> a -> a > > You can of course use > >>>> :set -Wall -fno-warn-type-defaults > Of course. I have no idea what warnings > I might be turning off that would actually be useful? > The warnings that turns off are just the ones like your discard and the 3 == 3 where it had to turn to defaulting for an under-determined type. -Edward -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Sun Mar 23 18:16:17 2014 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 23 Mar 2014 18:16:17 +0000 Subject: Burning more bridges (mostly numeric ones) In-Reply-To: References: <1393247600013-5744545.post@n5.nabble.com> Message-ID: <20140323181617.GB20741@weber> On Sun, Mar 23, 2014 at 01:50:43AM -0700, Bart Massey wrote: > >>>> :m + Numeric.Lens Control.Lens > >>>> "7b" ^? hex > > Just 123 > >>>> hex # 123 > > "7b" > > Nice. Once this really becomes standard, I guess we'll be somewhere. Unless there's some way I'm unaware of to statically verify that the string indeed represents a valid hex encoding, then this is still not a complete solution. Tom From schlepptop at henning-thielemann.de Sun Mar 23 18:25:54 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Sun, 23 Mar 2014 19:25:54 +0100 Subject: Burning more bridges (mostly numeric ones) In-Reply-To: References: <1393247600013-5744545.post@n5.nabble.com> Message-ID: <532F2732.8050406@henning-thielemann.de> Am 23.03.2014 09:50, schrieb Bart Massey: >>> * The multiplicity of exponentiation functions, one of which looks >>> exactly like C's XOR operator, which I've watched trip up newbies a >>> bunch of times. (Indeed, NumericPrelude seems to have added more of >>> these, including the IMHO poorly-named (^-) which has nothing to do >>> with numeric negation as far as I can tell. See "unary negation" >>> above.) >> >> It is unfortunate, but there really is a distinction being made. > > I get that. I even get that static-typing exponentiation is hard. (You > should see how > we did it in Nickle (http://nickle.org) --not because it's good but because > it calls out a lot of the problems.) What I don't get is why the names seem > so terrible to me, nor why the typechecker can't do more to help reduce the > number of needed operators, ideally to one. It might mean extra conversion > operators around exponentiation once in a while, I guess? I think the power functions of Haskell are the best we can do, and mathematics is to blame for having only one notation for different power functions. http://www.haskell.org/haskellwiki/Power_function I like to compare it to division. In school we first learnt natural numbers and that division cannot always be performed with natural numbers. Instead we have division with remainder. In contrast to that we can always divide rational numbers (except division by zero). In Haskell this is nicely captured by two different functions div and (/). The same way I find it sensible to distinguish power functions. I found the infix operator names (^^) and (**) not very intuitive and defined (^-) and (^/) in NumericPrelude, in order to show, that the first one allows negative exponents and the second one allows fractional exponents. Unfortunately the first one looks like power function with negated exponent and I had no better idea for an identifier so far. From schlepptop at henning-thielemann.de Sun Mar 23 18:30:07 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Sun, 23 Mar 2014 19:30:07 +0100 Subject: Burning more bridges (mostly numeric ones) In-Reply-To: <20140323181617.GB20741@weber> References: <1393247600013-5744545.post@n5.nabble.com> <20140323181617.GB20741@weber> Message-ID: <532F282F.6090300@henning-thielemann.de> Am 23.03.2014 19:16, schrieb Tom Ellis: > On Sun, Mar 23, 2014 at 01:50:43AM -0700, Bart Massey wrote: >>>>>> :m + Numeric.Lens Control.Lens >>>>>> "7b" ^? hex >>> Just 123 >>>>>> hex # 123 >>> "7b" >> >> Nice. Once this really becomes standard, I guess we'll be somewhere. > > Unless there's some way I'm unaware of to statically verify that the string > indeed represents a valid hex encoding, then this is still not a complete > solution. Since the original complaint was about parsing, there must be a way to fail. The first line ("7b" ^? hex) seems to allow failure. For literal hex input we have 0x7b. However I don't see a problem with readHex. Prelude> case Numeric.readHex "7b" of [(n,"")] -> print n; _ -> putStrLn "could not parse hex number" 123 From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Sun Mar 23 18:46:35 2014 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 23 Mar 2014 18:46:35 +0000 Subject: Burning more bridges (mostly numeric ones) In-Reply-To: <532F282F.6090300@henning-thielemann.de> References: <1393247600013-5744545.post@n5.nabble.com> <20140323181617.GB20741@weber> <532F282F.6090300@henning-thielemann.de> Message-ID: <20140323184635.GD20741@weber> On Sun, Mar 23, 2014 at 07:30:07PM +0100, Henning Thielemann wrote: > Am 23.03.2014 19:16, schrieb Tom Ellis: > >Unless there's some way I'm unaware of to statically verify that the string > >indeed represents a valid hex encoding, then this is still not a complete > >solution. > > Since the original complaint was about parsing, there must be a way > to fail. The first line ("7b" ^? hex) seems to allow failure. > > For literal hex input we have 0x7b. Oh, I wasn't reading carefully enough! From andreas.abel at ifi.lmu.de Mon Mar 24 09:58:49 2014 From: andreas.abel at ifi.lmu.de (Andreas Abel) Date: Mon, 24 Mar 2014 10:58:49 +0100 Subject: Burning more bridges (mostly numeric ones) In-Reply-To: <532F2732.8050406@henning-thielemann.de> References: <1393247600013-5744545.post@n5.nabble.com> <532F2732.8050406@henning-thielemann.de> Message-ID: <533001D9.3040607@ifi.lmu.de> On 23.03.2014 19:25, Henning Thielemann wrote: > I found the infix operator names (^^) and (**) not very intuitive and > defined (^-) and (^/) in NumericPrelude, in order to show, that the > first one allows negative exponents and the second one allows fractional > exponents. Unfortunately the first one looks like power function with > negated exponent and I had no better idea for an identifier so far. Ah, so x ^- 2 (or is it x ^- 2.0) is not the square root of x? Maybe you should change this identifier indeed! Maybe use ^+- instead. This looks a bit confusing, but ^- is outright misleading. Cheers, Andreas -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel at gu.se http://www2.tcs.ifi.lmu.de/~abel/ From schlepptop at henning-thielemann.de Mon Mar 24 10:06:23 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Mon, 24 Mar 2014 11:06:23 +0100 Subject: Burning more bridges (mostly numeric ones) In-Reply-To: <533001D9.3040607@ifi.lmu.de> References: <1393247600013-5744545.post@n5.nabble.com> <532F2732.8050406@henning-thielemann.de> <533001D9.3040607@ifi.lmu.de> Message-ID: <5330039F.5010704@henning-thielemann.de> Am 24.03.2014 10:58, schrieb Andreas Abel: > On 23.03.2014 19:25, Henning Thielemann wrote: >> I found the infix operator names (^^) and (**) not very intuitive and >> defined (^-) and (^/) in NumericPrelude, in order to show, that the >> first one allows negative exponents and the second one allows fractional >> exponents. Unfortunately the first one looks like power function with >> negated exponent and I had no better idea for an identifier so far. > > Ah, so x ^- 2 (or is it x ^- 2.0) is not the square root of x? Maybe > you should change this identifier indeed! If at all, it could be misinterpreted as 1/x^2. Square root would be x^/0.5. > Maybe use ^+- instead. Nice idea! Analogously I could define (^*/). From mark.lentczner at gmail.com Mon Mar 24 14:14:23 2014 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Mon, 24 Mar 2014 07:14:23 -0700 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> Message-ID: Speaking from the vantage point of platform.... This pair of comments (emphasis mine) have my alarm index on high: On Fri, Mar 14, 2014 at 2:36 AM, Johan Tibell wrote: > I'm quite worried about this change though. I thought the default rolefor data type was nominal, as that's the safe default. *If > the default is representational, every package author will need to be aware > of this feature and update their packages.* That's quite a high cost. > On Fri, Mar 14, 2014 at 6:00 AM, Brandon Allbery wrote: > *Nominal default breaks everything that uses newtype deriving and doesn't > have role annotations, doesn't it?* Representational default means things > behave in 7.8 as they did in earlier GHCs. > Am I reading these pair of statements correctly? It seems to imply to me that *every* parameterized type that uses a type constraint on a parameter *must* be reviewed and possibly annotated to work correctly, one way or the other! Seems so: On Fri, Mar 14, 2014 at 7:22 AM, Richard Eisenberg wrote: > So, the best thing we came up with is this: Libraries that wish to export > abstract data types must do two things: > 1. Manage export lists carefully. > *2. Use role annotations.* > This is huge order, and one that will produce significant strain on the ecosystem. For one, this will set back Haskell Platform months: We have 250k lines of Haskell by 30+ authors that will need to be reviewed and updated. And all of this is so that data types can be coerced more safely? While I'm all for safely, the number of places where coercion is that important seems very small... and this addition to the language and burden on the libraries very high. If this feature cannot be added safely without reviewing 1/4 million lines of library code (not to mention all of hackage)... Then I think it isn't ready and shouldn't be released in 7.8. - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Mon Mar 24 14:25:23 2014 From: svenpanne at gmail.com (Sven Panne) Date: Mon, 24 Mar 2014 15:25:23 +0100 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> Message-ID: 2014-03-24 15:14 GMT+01:00 Mark Lentczner : > Speaking from the vantage point of platform.... This pair of comments > (emphasis mine) have my alarm index on high: > > On Fri, Mar 14, 2014 at 2:36 AM, Johan Tibell > wrote: [...] >> So, the best thing we came up with is this: Libraries that wish to export >> abstract data types must do two things: >> 1. Manage export lists carefully. >> 2. Use role annotations. > > This is huge order, and one that will produce significant strain on the > ecosystem. For one, this will set back Haskell Platform months: We have 250k > lines of Haskell by 30+ authors that will need to be reviewed and updated. [...] Hmmm, I didn't follow role annotations at all so far, because I assumed it was of no concern to me as a library author *unless* I use some shiny new machinery in my library. Did I misunderstand that? How can I find out if I have to do something? What happens if I don't do something? What about Haskell systems which are not GHC? Do I have to #ifdef around those annotations? :-P I'm a bit clueless, and I'm guess I'm not alone... :-/ If this new feature really implies that massive amount of library code review, we should discuss first if it's really worth the trouble. The GHC release and the HP are already late... Cheers, S. From allbery.b at gmail.com Mon Mar 24 14:28:06 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 24 Mar 2014 10:28:06 -0400 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> Message-ID: On Mon, Mar 24, 2014 at 10:14 AM, Mark Lentczner wrote: > On Fri, Mar 14, 2014 at 2:36 AM, Johan Tibell wrote: > >> I'm quite worried about this change though. I thought the default rolefor data type was nominal, as that's the safe default. *If >> the default is representational, every package author will need to be aware >> of this feature and update their packages.* That's quite a high cost. >> > > On Fri, Mar 14, 2014 at 6:00 AM, Brandon Allbery > wrote: > > *Nominal default breaks everything that uses newtype deriving and doesn't >> have role annotations, doesn't it?* Representational default means >> things behave in 7.8 as they did in earlier GHCs. >> > > Am I reading these pair of statements correctly? It seems to imply to me > that *every* parameterized type that uses a type constraint on a > parameter *must* be reviewed and possibly annotated to work correctly, > one way or the other! > No; if the default is representational, everything works as it did in earlier versions, potential bugs/unsafety and all. If the default is immediately switched to nominal, *then* every affected type must be reviewed immediately. My counter-proposal was to have 7.8 default to representational to give library maintainers a release cycle to add the necessary annotations, then switch the default to nominal in 7.10 to get the additional safety. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Mon Mar 24 14:32:40 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 24 Mar 2014 10:32:40 -0400 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> Message-ID: On Mon, Mar 24, 2014 at 10:28 AM, Brandon Allbery wrote: > On Mon, Mar 24, 2014 at 10:14 AM, Mark Lentczner > wrote: > >> On Fri, Mar 14, 2014 at 2:36 AM, Johan Tibell wrote: >> >>> I'm quite worried about this change though. I thought the default rolefor data type was nominal, as that's the safe default. *If >>> the default is representational, every package author will need to be aware >>> of this feature and update their packages.* That's quite a high cost. >>> >> >> On Fri, Mar 14, 2014 at 6:00 AM, Brandon Allbery >> wrote: >> >> *Nominal default breaks everything that uses newtype deriving and doesn't >>> have role annotations, doesn't it?* Representational default means >>> things behave in 7.8 as they did in earlier GHCs. >>> >> >> Am I reading these pair of statements correctly? It seems to imply to me >> that *every* parameterized type that uses a type constraint on a >> parameter *must* be reviewed and possibly annotated to work correctly, >> one way or the other! >> > > No; if the default is representational, everything works as it did in > earlier versions, potential bugs/unsafety and all. If the default is > immediately switched to nominal, *then* every affected type must be > reviewed immediately. My counter-proposal was to have 7.8 default to > representational to give library maintainers a release cycle to add the > necessary annotations, then switch the default to nominal in 7.10 to get > the additional safety. > By the way, since I suspected (and was subsequently proved out) that appropriate warnings are difficult, perhaps there should be some mechanism to specify to ghc 7.8 whether a compile should default to representational or nominal so that authors have a way to test their code / look for problems. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Mon Mar 24 14:44:07 2014 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Mon, 24 Mar 2014 07:44:07 -0700 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> Message-ID: On Mon, Mar 24, 2014 at 7:28 AM, Brandon Allbery wrote: > No; if the default is representational, everything works as it did in > earlier versions, potential bugs/unsafety and all. If the default is > immediately switched to nominal, *then* every affected type must be > reviewed immediately. > Now I'm confused about the current state of the default.... But it doesn't matter either way: The Platform is expected to work cohesively with the GHC release, and either of these defaults spells a huge amount of work for the Platform. > My counter-proposal was to have 7.8 default to representational to give > library maintainers a release cycle to add the necessary annotations, then > switch the default to nominal in 7.10 to get the additional safety. > This is unworkable. How much conditional code do you want library writers to have to have? Library writers strive to have code which works with n prior releases where n is commonly 3. Having code that works with 7.6, 7.8, and 7.10 would be a nighmare! On Mon, Mar 24, 2014 at 7:32 AM, Brandon Allbery wrote: > perhaps there should be some mechanism to specify to ghc 7.8 whether a > compile should default to representational or nominal so that authors have > a way to test their code / look for problems. > Also unworkable... now we need a conditional flag for the state of the default so the code can be written to work with either based on a GHC flag? And how is that supposed to work with already compiled dependencies (sandboxed or not)? Is cabal now to take this flag into account? the Package manager signatures too? The major problem with this feature is that it is massively global in scope. This is extremely rare for GHC extensions (Safe comes to mind)... and with good reason: It is very very expensive. The motivating case here, a compiler checked safe zero-cost coerce, seems way out of proportion to the cost: Careful review of every library abstract type, and addition of *three+* lines of source (remember, this must be CPP guarded, so you have to add CPP extension on to every file, too). -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Mar 24 14:46:22 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 24 Mar 2014 14:46:22 +0000 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> Message-ID: <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com> When Brandon says ?potential bugs/unsafety and all? he means GeneralisedNewtypeDeriving (GND). That already exists, and already allows you to do bad things (Trac #1496 among others). See the thread on https://ghc.haskell.org/trac/ghc/ticket/8827, starting especially at comment 17 for more discussion and some insightful comments. As Edward (on the ticket) and Brandon (here) point out, going to ?nominal by default? will be very safe but it?ll break many Haskell packages which use GND. This is really a library/user question, not a GHC one. We can implement whatever default you want. But GHC 7.8 is about to be released and this debate has been going on for some weeks, at high intensity on ghc-devs, plus Richard specifically advertised it to the libraries list back in November, and again a couple of weeks ago. I think the status quo is not unreasonable. One question you might want to debate is whether, as Brandon suggests, you want to move to ?nominal by default? in due course. Simon From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Brandon Allbery Sent: 24 March 2014 14:28 To: Mark Lentczner Cc: GHC Development Mailing List; libraries at haskell.org Libraries Subject: Re: We need to add role annotations for 7.8 On Mon, Mar 24, 2014 at 10:14 AM, Mark Lentczner > wrote: On Fri, Mar 14, 2014 at 2:36 AM, Johan Tibell > wrote: I'm quite worried about this change though. I thought the default role for data type was nominal, as that's the safe default. If the default is representational, every package author will need to be aware of this feature and update their packages. That's quite a high cost. On Fri, Mar 14, 2014 at 6:00 AM, Brandon Allbery > wrote: Nominal default breaks everything that uses newtype deriving and doesn't have role annotations, doesn't it? Representational default means things behave in 7.8 as they did in earlier GHCs. Am I reading these pair of statements correctly? It seems to imply to me that every parameterized type that uses a type constraint on a parameter must be reviewed and possibly annotated to work correctly, one way or the other! No; if the default is representational, everything works as it did in earlier versions, potential bugs/unsafety and all. If the default is immediately switched to nominal, *then* every affected type must be reviewed immediately. My counter-proposal was to have 7.8 default to representational to give library maintainers a release cycle to add the necessary annotations, then switch the default to nominal in 7.10 to get the additional safety. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Mon Mar 24 14:57:27 2014 From: gershomb at gmail.com (Gershom Bazerman) Date: Mon, 24 Mar 2014 10:57:27 -0400 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> Message-ID: <533047D7.70402@gmail.com> Apols if I'm overstating the case, but let me try to clear things up. Roles are not in place to provide a "safe" cheap coerce. Roles are in place to _prevent_ an unsoundness with newtype deriving in the presence of type families. They also happen to _allow_ a cheaper coerce. The unsoundness is fixed by roles, with or without specific role annotations, because the necessary roles for type-safety (preventing segfault) are inferred/enforced regardless. With or without roles, in the past, it has been possible to circumvent certain mechanisms of abstraction by using newtype deriving. Explicit roles now _allow_ library writers to, for the first time, to enforce these abstraction mechanisms more strongly than in the past. We also happen to have a new "coerce" that will not segfault, and _if_ role annotations are correct, will respect representation-hiding. If libraries do _not_ get updated with roles, the "worst" that can happen is that their abstractions are precisely as deliberately circumventable as in the past, although there is now an "easy" function provided that makes this circumvention more straightforward. So I feel it is "better" to enforce representation-hiding through proper usage of roles. However, it is also no great sin to _not_ enforce it for some span of time, since all that doing so prevents is a rather (at the moment) esoteric mechanism for developers to shoot themselves in the foot -- a mechanism that in a slightly different form has existed all along. -g On 3/24/14, 10:44 AM, Mark Lentczner wrote: > > The major problem with this feature is that it is massively global in > scope. This is extremely rare for GHC extensions (Safe comes to > mind)... and with good reason: It is very very expensive. The > motivating case here, a compiler checked safe zero-cost coerce, seems > way out of proportion to the cost: Careful review of every library > abstract type, and addition of *three+* lines of source (remember, > this must be CPP guarded, so you have to add CPP extension on to every > file, too). > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Mon Mar 24 14:57:17 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 24 Mar 2014 10:57:17 -0400 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> Message-ID: On Mon, Mar 24, 2014 at 10:44 AM, Mark Lentczner wrote: > On Mon, Mar 24, 2014 at 7:28 AM, Brandon Allbery wrote: > >> My counter-proposal was to have 7.8 default to representational to give >> library maintainers a release cycle to add the necessary annotations, then >> switch the default to nominal in 7.10 to get the additional safety. >> > > This is unworkable. How much conditional code do you want library writers > to have to have? Library writers strive to have code which works with n > prior releases where n is commonly 3. Having code that works with 7.6, 7.8, > and 7.10 would be a nighmare! > No? Immediately switching to nominal requires those annotations immediately. No immediate change is needed if we keep the current default; if you have problems with conditional code, you will have them no matter what with roles --- the only question is when. Also see SPJ's response. > On Mon, Mar 24, 2014 at 7:32 AM, Brandon Allbery > wrote: > > perhaps there should be some mechanism to specify to ghc 7.8 whether a >> compile should default to representational or nominal so that authors have >> a way to test their code / look for problems. >> > > Also unworkable... now we need a conditional flag for the state of the > default so the code can > be written to work with either based on a GHC flag? And how is that > supposed to work with > Nope; in fact, code containing this flag should be rejected by hackage the same way some other options are rejected. It exists ONLY to help library authors with the transition, and should never be used with released code, only for maintainer debugging/testing. It would be nice if it could be forced to only work in sandboxes, but that would require a rather unhealthy level of ghc / cabal-install interaction. I expect such testing will end up requiring hsenv. There's just no good way of handling this whole role annotations thing; it's a massive sledgehammer. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Mon Mar 24 15:26:14 2014 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Mon, 24 Mar 2014 08:26:14 -0700 Subject: We need to add role annotations for 7.8 In-Reply-To: <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com> References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: Thanks for the pointers, Simon. I appologize for coming to this quite so late... I didn't realize the global impact of this feature. >From a "meaning" perspective, I'm agnostic on the default. >From a "engineering" perspective, I want a default that "does a good enough, reasonably safe thing" if programmers ignore the feature. The later is subtle as there are different vantage points for different developers. In the Platform, we have many libraries that we are encouraging both end-programmers, and other library authors to make use of and depend on extensively. This means those libraries have to work for both programmers that are ignoring the feature, and those that use it. In that later case, there is the even more subtle distinction of those that use the feature for their own code, and those that use it in libraries they make available. The later case is issue: It seems a real mess if a library author who wanted to use the new feature, had to circumvent a HP library because it didn't annotate. Similar thought experiment: What would be the downside if containers didn't annotate? Would that just make the feature unusable because everything uses containers? To put it more directly: with the satus-quo default of representations, what is the down side if a library, a widely used library, doesn't bother to annotate? What would be the loss if containers didn't annotate? (I know it did, this is the thought experiment... because I've got 30+ libraries in HP that are in this boat.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Mon Mar 24 15:36:35 2014 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Mon, 24 Mar 2014 08:36:35 -0700 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: Again, sorry for the 11:59 meddling.... The syntax of role annotations is very heavy weight, and requires lots of CPP where there wasn't need before. Two thoughts: 1) Couldn't we do something like use "cue" type constraints? For example, assuming the default is representational, and that phantom can just be inferred, all we need is a way to indicate nominal: data (Nominal k) => Map k v = ... This could then probably be easily made to compile in other compilers with some null library implementation of Nominal 2) An alternative to the above. We generally frown on constraints in a data / newtype declaration, but perhaps this is exactly the case for them, whereby we can now do away with the type role syntax: We can infer nominal if there are *any* constraints on a type parameter, *representational* if there are none, and *phantom *if there are no mentions in the right hand side: data (Eq k) => Map k v = ... This seems even nicer and just works with all compilers... but perhaps I'm missing something. (Yes, I imagine there are type constraints that shouldn't force nominal, but perhaps not worth worrying about?) Mind you, this all just about syntax... the issue of what is the implication for libraries of the default being representational is still at hand. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.doel at gmail.com Mon Mar 24 15:48:31 2014 From: dan.doel at gmail.com (Dan Doel) Date: Mon, 24 Mar 2014 11:48:31 -0400 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> Message-ID: On Mon, Mar 24, 2014 at 10:57 AM, Brandon Allbery wrote: > No? Immediately switching to nominal requires those annotations > immediately. No immediate change is needed if we keep the current default; > if you have problems with conditional code, you will have them no matter > what with roles --- the only question is when. Also see SPJ's response. > I don't think this is true. If nominal-by-default is not on the road map, then most people never have to do anything. If I can generalize about myself at least, most data types that are defined do not have (additional, role-enforceable) invariants. They are mainly simple combinations of other types in ways that allow me to structure my code well. So the vast majority of types defined by people like me should have representational parameters, unless one of the constituent types is a Set or Map or what have you, in which case nominal can be inferred, assuming Set and Map are appropriately annotated. Nominal-by-default would require annotations for every minor definition like this in order to correctly specify the type. By contrast, representational-by-default imposes some work/diligence on authors of data structures with invariants, which tend (in my experience) to be the minority of definitions, and typically come as libraries. I feel a little bad suggesting 'unsafety' as the default, but the safe default imposes a significant, perpetual cost on everyone using the language in return for defense against occasional oversights by library authors. That doesn't seem like a good trade off. -- Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at gregweber.info Mon Mar 24 18:59:46 2014 From: greg at gregweber.info (Greg Weber) Date: Mon, 24 Mar 2014 11:59:46 -0700 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: It was suggested on reddit and seemed to be thought a good idea that it would be better for the syntax to be a comment like {-# INLINE -#}, etc. That allows backward compatibility with older versions without CPP, and also doesn't use up syntax. I think the problem is that we are on the doorstep of a release now and the existing syntax has already been under use. On Mon, Mar 24, 2014 at 8:36 AM, Mark Lentczner wrote: > Again, sorry for the 11:59 meddling.... > > The syntax of role annotations is very heavy weight, and requires lots of > CPP where there wasn't need before. Two thoughts: > > 1) Couldn't we do something like use "cue" type constraints? For example, > assuming the default is representational, and that phantom can just be > inferred, all we need is a way to indicate nominal: > > data (Nominal k) => Map k v = ... > > > This could then probably be easily made to compile in other compilers with > some null library implementation of Nominal > > 2) An alternative to the above. We generally frown on constraints in a > data / newtype declaration, but perhaps this is exactly the case for them, > whereby we can now do away with the type role syntax: We can infer nominal > if there are *any* constraints on a type parameter, *representational* if > there are none, and *phantom *if there are no mentions in the right hand > side: > > data (Eq k) => Map k v = ... > > > This seems even nicer and just works with all compilers... but perhaps I'm > missing something. (Yes, I imagine there are type constraints that > shouldn't force nominal, but perhaps not worth worrying about?) > > > Mind you, this all just about syntax... the issue of what is the > implication for libraries of the default being representational is still at > hand. > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Mon Mar 24 19:10:47 2014 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 24 Mar 2014 15:10:47 -0400 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: Mark, We're currently planning to retain the existing behavior of GeneralizedNewtypeDeriving with regards to Safe Haskell. That is, Safe Haskell and GND still won't mix in 7.8 due to these same security concerns. I think a key observation with regards to GeneralizedNewtypeDeriving is with representational roles as default the new roles machinery with the representational default lets you write nothing you couldn't write before. No new security vulnerabilities are introduced. They were there all along! We're also disabling the Safe flag on Data.Coerce. In that light, `coerce` then can be viewed as a more friendly but still evil version of unsafeCoerce. It lets you write nothing you couldn't write before with `unsafeCoerce`. I view it as merely an occasional situational improvement over the existing unsafeCoerce in that it at least enforces representational equality. Making the default role annotation nominal comes at a very very real cost. Namely, *all* of generalized newtype deriving anywhere breaks, and everyone forever will have to put annotations in to fix it. The 'backwards' representational default puts the burden on a small minority of library authors. I'm not a huge fan of the representational machinery, in that it hoists us upon this dilemma, but given the choice between everyone paying in perpetuity and a small minority of skilled library authors adding a handful of annotations that for the most part have already been added, and which expose them to no more risk than they'd had before if they forget, I'm definitely in favor of the current solution. -Edward On Mon, Mar 24, 2014 at 11:26 AM, Mark Lentczner wrote: > Thanks for the pointers, Simon. I appologize for coming to this quite so > late... I didn't realize the global impact of this feature. > > From a "meaning" perspective, I'm agnostic on the default. > From a "engineering" perspective, I want a default that "does a good > enough, reasonably safe thing" if programmers ignore the feature. > > The later is subtle as there are different vantage points for different > developers. In the Platform, we have many libraries that we are encouraging > both end-programmers, and other library authors to make use of and depend > on extensively. This means those libraries have to work for both > programmers that are ignoring the feature, and those that use it. In that > later case, there is the even more subtle distinction of those that use the > feature for their own code, and those that use it in libraries they make > available. > > The later case is issue: It seems a real mess if a library author who > wanted to use the new feature, had to circumvent a HP library because it > didn't annotate. Similar thought experiment: What would be the downside if > containers didn't annotate? Would that just make the feature unusable > because everything uses containers? > > To put it more directly: with the satus-quo default of representations, > what is the down side if a library, a widely used library, doesn't bother > to annotate? What would be the loss if containers didn't annotate? (I know > it did, this is the thought experiment... because I've got 30+ libraries in > HP that are in this boat.) > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Mon Mar 24 19:21:05 2014 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 24 Mar 2014 15:21:05 -0400 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: This puts the constraint on the wrong thing. I did argue for a pragma-like syntax for the annotations when they were first proposed, as the need for library authors to hide these behind CPP pragmas bothers me a great deal, but I think for better or worse that syntax decision is largely behind us. A type-class driven approach does have some promise, but that said, it can't look like what you've written. What you've written: data Nominal k => Map k a is saying something about the argument k, not about if you can turn Map kinto Map k', which is actually about Map, k is just along for the ride. Really what we're talking about is that the next argument is representational as applied. Also, the right 'open world' version would be to talk about it as classes would be: class Representational t where rep :: Coercion a b -> Coercion (t a) (t b) class Representational t => Phantom t where phantom :: Coercion (t a) (t b) With "Nominal" simply being the absence of either of those instances. data Map k a would need instance Representational (Map k) since the 'a' can be coerced as it has a representational role. instance Representational (->) instance Representational ((->) a) But there are actually still open issues I don't know how to solve, even with this approach. -Edward On Mon, Mar 24, 2014 at 11:36 AM, Mark Lentczner wrote: > Again, sorry for the 11:59 meddling.... > > The syntax of role annotations is very heavy weight, and requires lots of > CPP where there wasn't need before. Two thoughts: > > 1) Couldn't we do something like use "cue" type constraints? For example, > assuming the default is representational, and that phantom can just be > inferred, all we need is a way to indicate nominal: > > data (Nominal k) => Map k v = ... > > > This could then probably be easily made to compile in other compilers with > some null library implementation of Nominal > > 2) An alternative to the above. We generally frown on constraints in a > data / newtype declaration, but perhaps this is exactly the case for them, > whereby we can now do away with the type role syntax: We can infer nominal > if there are *any* constraints on a type parameter, *representational* if > there are none, and *phantom *if there are no mentions in the right hand > side: > > data (Eq k) => Map k v = ... > > > This seems even nicer and just works with all compilers... but perhaps I'm > missing something. (Yes, I imagine there are type constraints that > shouldn't force nominal, but perhaps not worth worrying about?) > > > Mind you, this all just about syntax... the issue of what is the > implication for libraries of the default being representational is still at > hand. > ? > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Mar 24 22:57:03 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 24 Mar 2014 22:57:03 +0000 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: <59543203684B2244980D7E4057D5FBC1488BB740@DB3EX14MBXC308.europe.corp.microsoft.com> In that light, `coerce` then can be viewed as a more friendly but still evil version of unsafeCoerce Coerce embodies one rather compelling improvement: it is type-sound. unsafeCoerce can cause arbitrary seg-faults etc. ?coerce? cannot. Call me an old-fashioned ?well-typed programs don?t go wrong? man, but I think that?s a big plus. Much more than ?an occasional situation improvement?. Granted, ?type-sound? doesn?t guarantee ?correct?, but then it never did. The role machinery doesn?t exactly hoist us on a dilemma ? it merely exposes the dilemma that was there all the time. Simon From: Edward Kmett [mailto:ekmett at gmail.com] Sent: 24 March 2014 19:11 To: Mark Lentczner Cc: Simon Peyton Jones; libraries at haskell.org Libraries; ghc-devs at haskell.org Subject: Re: We need to add role annotations for 7.8 Mark, We're currently planning to retain the existing behavior of GeneralizedNewtypeDeriving with regards to Safe Haskell. That is, Safe Haskell and GND still won't mix in 7.8 due to these same security concerns. I think a key observation with regards to GeneralizedNewtypeDeriving is with representational roles as default the new roles machinery with the representational default lets you write nothing you couldn't write before. No new security vulnerabilities are introduced. They were there all along! We're also disabling the Safe flag on Data.Coerce. In that light, `coerce` then can be viewed as a more friendly but still evil version of unsafeCoerce. It lets you write nothing you couldn't write before with `unsafeCoerce`. I view it as merely an occasional situational improvement over the existing unsafeCoerce in that it at least enforces representational equality. Making the default role annotation nominal comes at a very very real cost. Namely, all of generalized newtype deriving anywhere breaks, and everyone forever will have to put annotations in to fix it. The 'backwards' representational default puts the burden on a small minority of library authors. I'm not a huge fan of the representational machinery, in that it hoists us upon this dilemma, but given the choice between everyone paying in perpetuity and a small minority of skilled library authors adding a handful of annotations that for the most part have already been added, and which expose them to no more risk than they'd had before if they forget, I'm definitely in favor of the current solution. -Edward On Mon, Mar 24, 2014 at 11:26 AM, Mark Lentczner > wrote: Thanks for the pointers, Simon. I appologize for coming to this quite so late... I didn't realize the global impact of this feature. From a "meaning" perspective, I'm agnostic on the default. From a "engineering" perspective, I want a default that "does a good enough, reasonably safe thing" if programmers ignore the feature. The later is subtle as there are different vantage points for different developers. In the Platform, we have many libraries that we are encouraging both end-programmers, and other library authors to make use of and depend on extensively. This means those libraries have to work for both programmers that are ignoring the feature, and those that use it. In that later case, there is the even more subtle distinction of those that use the feature for their own code, and those that use it in libraries they make available. The later case is issue: It seems a real mess if a library author who wanted to use the new feature, had to circumvent a HP library because it didn't annotate. Similar thought experiment: What would be the downside if containers didn't annotate? Would that just make the feature unusable because everything uses containers? To put it more directly: with the satus-quo default of representations, what is the down side if a library, a widely used library, doesn't bother to annotate? What would be the loss if containers didn't annotate? (I know it did, this is the thought experiment... because I've got 30+ libraries in HP that are in this boat.) _______________________________________________ Libraries mailing list Libraries at haskell.org http://www.haskell.org/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Tue Mar 25 01:32:59 2014 From: ekmett at gmail.com (Edward A Kmett) Date: Mon, 24 Mar 2014 21:32:59 -0400 Subject: We need to add role annotations for 7.8 In-Reply-To: <59543203684B2244980D7E4057D5FBC1488BB740@DB3EX14MBXC308.europe.corp.microsoft.com> References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com> <59543203684B2244980D7E4057D5FBC1488BB740@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com> Fair enough. I did try to convey that in the following sentence about how it at least enforces representational equality, but I can see how my statement might be taken as understating the importance of that property. Sent from my iPhone > On Mar 24, 2014, at 6:57 PM, Simon Peyton Jones wrote: > > In that light, `coerce` then can be viewed as a more friendly but still evil version of unsafeCoerce > > Coerce embodies one rather compelling improvement: it is type-sound. unsafeCoerce can cause arbitrary seg-faults etc. ?coerce? cannot. Call me an old-fashioned ?well-typed programs don?t go wrong? man, but I think that?s a big plus. Much more than ?an occasional situation improvement?. > > Granted, ?type-sound? doesn?t guarantee ?correct?, but then it never did. > > The role machinery doesn?t exactly hoist us on a dilemma ? it merely exposes the dilemma that was there all the time. > > Simon > > From: Edward Kmett [mailto:ekmett at gmail.com] > Sent: 24 March 2014 19:11 > To: Mark Lentczner > Cc: Simon Peyton Jones; libraries at haskell.org Libraries; ghc-devs at haskell.org > Subject: Re: We need to add role annotations for 7.8 > > Mark, > > > > We're currently planning to retain the existing behavior of GeneralizedNewtypeDeriving with regards to Safe Haskell. That is, Safe Haskell and GND still won't mix in 7.8 due to these same security concerns. > > > > I think a key observation with regards to GeneralizedNewtypeDeriving is with representational roles as default the new roles machinery with the representational default lets you write nothing you couldn't write before. No new security vulnerabilities are introduced. They were there all along! > > > > We're also disabling the Safe flag on Data.Coerce. In that light, `coerce` then can be viewed as a more friendly but still evil version of unsafeCoerce. It lets you write nothing you couldn't write before with `unsafeCoerce`. I view it as merely an occasional situational improvement over the existing unsafeCoerce in that it at least enforces representational equality. > > > > Making the default role annotation nominal comes at a very very real cost. Namely, all of generalized newtype deriving anywhere breaks, and everyone forever will have to put annotations in to fix it. > > > > The 'backwards' representational default puts the burden on a small minority of library authors. > > > > I'm not a huge fan of the representational machinery, in that it hoists us upon this dilemma, but given the choice between everyone paying in perpetuity and a small minority of skilled library authors adding a handful of annotations that for the most part have already been added, and which expose them to no more risk than they'd had before if they forget, I'm definitely in favor of the current solution. > > > > -Edward > > > > On Mon, Mar 24, 2014 at 11:26 AM, Mark Lentczner wrote: > > Thanks for the pointers, Simon. I appologize for coming to this quite so late... I didn't realize the global impact of this feature. > > > > From a "meaning" perspective, I'm agnostic on the default. > > From a "engineering" perspective, I want a default that "does a good enough, reasonably safe thing" if programmers ignore the feature. > > > > The later is subtle as there are different vantage points for different developers. In the Platform, we have many libraries that we are encouraging both end-programmers, and other library authors to make use of and depend on extensively. This means those libraries have to work for both programmers that are ignoring the feature, and those that use it. In that later case, there is the even more subtle distinction of those that use the feature for their own code, and those that use it in libraries they make available. > > > > The later case is issue: It seems a real mess if a library author who wanted to use the new feature, had to circumvent a HP library because it didn't annotate. Similar thought experiment: What would be the downside if containers didn't annotate? Would that just make the feature unusable because everything uses containers? > > > > To put it more directly: with the satus-quo default of representations, what is the down side if a library, a widely used library, doesn't bother to annotate? What would be the loss if containers didn't annotate? (I know it did, this is the thought experiment... because I've got 30+ libraries in HP that are in this boat.) > > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Tue Mar 25 03:26:36 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 24 Mar 2014 23:26:36 -0400 Subject: We need to add role annotations for 7.8 In-Reply-To: <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com> References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com> <59543203684! B2244980D7E4057D5FBC1488BB740@DB3EX14MBXC308.europe.corp.microsoft.com> <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com> Message-ID: <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu> I have a few responses to various themes in this thread, but nothing terribly unexpected: - The introduction of roles is the end of the story that began with the discovery of bug #1496. The alternative would be to do away with GND. `coerce` is just a convenient application of roles, not the reason they were introduced. - The concrete syntax for role ascriptions was debated in public, in bug #8185. There is further discussion of the design choice in the appendix of the extended version of our recent draft paper on the subject: www.cis.upenn.edu/~eir/papers/2014/coercible/coercible-ext.pdf I'm afraid it's too late now to make changes. I don't love what we ended up with, but I believe it's the best syntax that was proposed. - I agree with Simon that `coerce` is quite a bit safer than `unsafeCoerce`. Under the assumption that all libraries are written correctly (that is, with proper role annotations), `coerce` is in fact fully safe. - I surely recognize why and how this causes a Major Pain for Mark, and for other library maintainers. I wish there were an easier solution. However, I will perhaps repeat others in saying that a library that doesn't add role annotations is no more wrong in 7.8 than it was since GND was introduced. The only difference with 7.8 is that, now, there is a way to be right. Richard On Mar 24, 2014, at 9:32 PM, Edward A Kmett wrote: > Fair enough. I did try to convey that in the following sentence about how it at least enforces representational equality, but I can see how my statement might be taken as understating the importance of that property. > > Sent from my iPhone > > On Mar 24, 2014, at 6:57 PM, Simon Peyton Jones wrote: > >> In that light, `coerce` then can be viewed as a more friendly but still evil version of unsafeCoerce >> >> Coerce embodies one rather compelling improvement: it is type-sound. unsafeCoerce can cause arbitrary seg-faults etc. ?coerce? cannot. Call me an old-fashioned ?well-typed programs don?t go wrong? man, but I think that?s a big plus. Much more than ?an occasional situation improvement?. >> >> Granted, ?type-sound? doesn?t guarantee ?correct?, but then it never did. >> >> The role machinery doesn?t exactly hoist us on a dilemma ? it merely exposes the dilemma that was there all the time. >> >> Simon >> >> From: Edward Kmett [mailto:ekmett at gmail.com] >> Sent: 24 March 2014 19:11 >> To: Mark Lentczner >> Cc: Simon Peyton Jones; libraries at haskell.org Libraries; ghc-devs at haskell.org >> Subject: Re: We need to add role annotations for 7.8 >> >> Mark, >> >> >> >> We're currently planning to retain the existing behavior of GeneralizedNewtypeDeriving with regards to Safe Haskell. That is, Safe Haskell and GND still won't mix in 7.8 due to these same security concerns. >> >> >> >> I think a key observation with regards to GeneralizedNewtypeDeriving is with representational roles as default the new roles machinery with the representational default lets you write nothing you couldn't write before. No new security vulnerabilities are introduced. They were there all along! >> >> >> >> We're also disabling the Safe flag on Data.Coerce. In that light, `coerce` then can be viewed as a more friendly but still evil version of unsafeCoerce. It lets you write nothing you couldn't write before with `unsafeCoerce`. I view it as merely an occasional situational improvement over the existing unsafeCoerce in that it at least enforces representational equality. >> >> >> >> Making the default role annotation nominal comes at a very very real cost. Namely, all of generalized newtype deriving anywhere breaks, and everyone forever will have to put annotations in to fix it. >> >> >> >> The 'backwards' representational default puts the burden on a small minority of library authors. >> >> >> >> I'm not a huge fan of the representational machinery, in that it hoists us upon this dilemma, but given the choice between everyone paying in perpetuity and a small minority of skilled library authors adding a handful of annotations that for the most part have already been added, and which expose them to no more risk than they'd had before if they forget, I'm definitely in favor of the current solution. >> >> >> >> -Edward >> >> >> >> On Mon, Mar 24, 2014 at 11:26 AM, Mark Lentczner wrote: >> >> Thanks for the pointers, Simon. I appologize for coming to this quite so late... I didn't realize the global impact of this feature. >> >> >> >> From a "meaning" perspective, I'm agnostic on the default. >> >> From a "engineering" perspective, I want a default that "does a good enough, reasonably safe thing" if programmers ignore the feature. >> >> >> >> The later is subtle as there are different vantage points for different developers. In the Platform, we have many libraries that we are encouraging both end-programmers, and other library authors to make use of and depend on extensively. This means those libraries have to work for both programmers that are ignoring the feature, and those that use it. In that later case, there is the even more subtle distinction of those that use the feature for their own code, and those that use it in libraries they make available. >> >> >> >> The later case is issue: It seems a real mess if a library author who wanted to use the new feature, had to circumvent a HP library because it didn't annotate. Similar thought experiment: What would be the downside if containers didn't annotate? Would that just make the feature unusable because everything uses containers? >> >> >> >> To put it more directly: with the satus-quo default of representations, what is the down side if a library, a widely used library, doesn't bother to annotate? What would be the loss if containers didn't annotate? (I know it did, this is the thought experiment... because I've got 30+ libraries in HP that are in this boat.) >> >> >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> >> >> > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.abel at ifi.lmu.de Tue Mar 25 08:28:57 2014 From: andreas.abel at ifi.lmu.de (Andreas Abel) Date: Tue, 25 Mar 2014 09:28:57 +0100 Subject: We need to add role annotations for 7.8 In-Reply-To: <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu> References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com> <59543203684! B2244980D7E4057D5FBC1488BB740@DB3EX14MBXC308.europe.corp.microsoft.com> <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com> <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu> Message-ID: <53313E49.1040405@ifi.lmu.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As someone completely oblivious on this development in Haskell until now, but researching myself in the same direction (on the distinction of computational, irrelevant, and parametric arguments in Agda), I am allowing myself some comments on the process, and the syntax discussion given in the paper http://www.cis.upenn.edu/~eir/papers/2014/coercible/coercible-ext.pdf 1. The alternative of using a pragma as syntax is dismissed with the argument: "We felt that, in several years, we would regret this decision. Backwards-compatibility would no longer be an issue, and we would be stuck with a pragma syntax for a core language feature." I strongly disagree. One can introduce a pragma syntax first, for smooth backward compatibility, and after the feature has passed the test of time, still introduce a proper, "first-class" syntax. If role annotations become standard, introduction of a proper syntax instead of ugly pragmas will be received with applause, unlike now, where you burden ugly CPP-ifs onto the library developers. You could do for now with a pragma-like declaration {-# TYPEROLE identifier role ... role #-} or {-# TYPE_ROLE identifier role ... role #-} instead of the declaration type role identifier role ... role 2. The chosen role names mean nothing to me. It feels a bit like the term "delegate" used in C# instead of just speaking of a higher-order function. Looking at the semantics, I find the following translation nominal = computational That is, the choice of type expression has a computational effect (like a different implementation of Ord). representational = parametric The choice of type expression is parametric, i.e., does not lead to other choices, but is purely propagated through. Further, "representational" is a bit long for a keyword. 'nominal' invokes the exact opposite association for me than it means. In nominal calculi (Pitts et al), everything is *parametric* in the choice of names. For introducing a non-backwards compatible language feature, this process feels rushed, imho. You might wanna pull the break before the release. Cheers, Andreas On 25.03.2014 04:26, Richard Eisenberg wrote: > I have a few responses to various themes in this thread, but > nothing terribly unexpected: > > - The introduction of roles is the end of the story that began with > the discovery of bug #1496. The alternative would be to do away > with GND. `coerce` is just a convenient application of roles, not > the reason they were introduced. > > - The concrete syntax for role ascriptions was debated in public, > in bug #8185. There is further discussion of the design choice in > the appendix of the extended version of our recent draft paper on > the subject: > www.cis.upenn.edu/~eir/papers/2014/coercible/coercible-ext.pdf > > > I'm afraid it's too late now to make changes. I don't love what we > ended up with, but I believe it's the best syntax that was > proposed. > > - I agree with Simon that `coerce` is quite a bit safer than > `unsafeCoerce`. Under the assumption that all libraries are > written correctly (that is, with proper role annotations), `coerce` > is in fact fully safe. > > - I surely recognize why and how this causes a Major Pain for Mark, > and for other library maintainers. I wish there were an easier > solution. However, I will perhaps repeat others in saying that a > library that doesn't add role annotations is no more wrong in 7.8 > than it was since GND was introduced. The only difference with 7.8 > is that, now, there is a way to be right. > > Richard > > On Mar 24, 2014, at 9:32 PM, Edward A Kmett wrote: > >> Fair enough. I did try to convey that in the following sentence >> about how it at least enforces representational equality, but I >> can see how my statement might be taken as understating the >> importance of that property. >> >> Sent from my iPhone >> >> On Mar 24, 2014, at 6:57 PM, Simon Peyton Jones >> > wrote: >> >>> In that light, `coerce` then can be viewed as a more friendly >>> but still evil version of unsafeCoerce >>> >>> >>> >>> Coerce embodies one rather compelling improvement: *it is >>> type-sound.* unsafeCoerce can cause arbitrary seg-faults etc. >>> ?coerce? cannot. Call me an old-fashioned ?well-typed >>> programs don?t go wrong? man, but I think that?s a big plus. >>> Much more than ?an occasional situation improvement?. >>> >>> >>> >>> Granted, ?type-sound? doesn?t guarantee ?correct?, but then it >>> never did. >>> >>> >>> >>> The role machinery doesn?t exactly hoist us on a dilemma ? it >>> merely exposes the dilemma that was there all the time. >>> >>> >>> >>> Simon >>> >>> >>> >>> *From:*Edward Kmett [mailto:ekmett at gmail.com] *Sent:* 24 March >>> 2014 19:11 *To:* Mark Lentczner *Cc:* Simon Peyton Jones; >>> libraries at haskell.org Libraries; >>> ghc-devs at haskell.org *Subject:* >>> Re: We need to add role annotations for 7.8 >>> >>> >>> >>> Mark, >>> >>> >>> >>> We're currently planning to retain the existing behavior of >>> GeneralizedNewtypeDeriving with regards to Safe Haskell. That >>> is, Safe Haskell and GND still won't mix in 7.8 due to these >>> same security concerns. >>> >>> >>> >>> I think a key observation with regards to >>> GeneralizedNewtypeDeriving is with representational roles as >>> default the new roles machinery with the representational >>> default lets you write nothing you couldn't write before. No >>> new security vulnerabilities are introduced. They were there >>> all along! >>> >>> >>> >>> We're also disabling the Safe flag on Data.Coerce. In that >>> light, `coerce` then can be viewed as a more friendly but still >>> evil version of unsafeCoerce. It lets you write nothing you >>> couldn't write before with `unsafeCoerce`. I view it as merely >>> an occasional situational improvement over the existing >>> unsafeCoerce in that it at least enforces representational >>> equality. >>> >>> >>> >>> Making the default role annotation nominal comes at a very very >>> real cost. Namely, *all* of generalized newtype deriving >>> anywhere breaks, and everyone forever will have to put >>> annotations in to fix it. >>> >>> >>> >>> The 'backwards' representational default puts the burden on a >>> small minority of library authors. >>> >>> >>> >>> I'm not a huge fan of the representational machinery, in that >>> it hoists us upon this dilemma, but given the choice between >>> everyone paying in perpetuity and a small minority of skilled >>> library authors adding a handful of annotations that for the >>> most part have already been added, and which expose them to no >>> more risk than they'd had before if they forget, I'm definitely >>> in favor of the current solution. >>> >>> >>> >>> -Edward >>> >>> >>> >>> On Mon, Mar 24, 2014 at 11:26 AM, Mark Lentczner >>> > >>> wrote: >>> >>> Thanks for the pointers, Simon. I appologize for coming to >>> this quite so late... I didn't realize the global impact of >>> this feature. >>> >>> >>> >>> From a "meaning" perspective, I'm agnostic on the default. >>> >>> From a "engineering" perspective, I want a default that "does >>> a good enough, reasonably safe thing" if programmers ignore >>> the feature. >>> >>> >>> >>> The later is subtle as there are different vantage points for >>> different developers. In the Platform, we have many libraries >>> that we are encouraging both end-programmers, and other >>> library authors to make use of and depend on extensively. This >>> means those libraries have to work for both programmers that >>> are ignoring the feature, and those that use it. In that later >>> case, there is the even more subtle distinction of those that >>> use the feature for their own code, and those that use it in >>> libraries they make available. >>> >>> >>> >>> The later case is issue: It seems a real mess if a library >>> author who wanted to use the new feature, had to circumvent a >>> HP library because it didn't annotate. Similar thought >>> experiment: What would be the downside if containers didn't >>> annotate? Would that just make the feature unusable because >>> everything uses containers? >>> >>> >>> >>> To put it more directly: with the satus-quo default of >>> representations, what is the down side if a library, a widely >>> used library, doesn't bother to annotate? What would be the >>> loss if containers didn't annotate? (I know it did, this is >>> the thought experiment... because I've got 30+ libraries in HP >>> that are in this boat.) >>> >>> >>> >>> >>> _______________________________________________ Libraries >>> mailing list Libraries at haskell.org >>> >>> http://www.haskell.org/mailman/listinfo/libraries >>> >>> >>> >> _______________________________________________ Libraries mailing >> list Libraries at haskell.org >> http://www.haskell.org/mailman/listinfo/libraries > > > > _______________________________________________ Libraries mailing > list Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > - -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel at gu.se http://www2.tcs.ifi.lmu.de/~abel/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMxPkkACgkQPMHaDxpUpLNc6QCeLSqyQE/huMc0cBMIL4oJbLQ1 pOgAn3cW4YmP2hrQoMwMtRcmJ6t6jML3 =DnVb -----END PGP SIGNATURE----- From hvr at gnu.org Tue Mar 25 09:56:00 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Tue, 25 Mar 2014 10:56:00 +0100 Subject: We need to add role annotations for 7.8 In-Reply-To: <53313E49.1040405@ifi.lmu.de> (Andreas Abel's message of "Tue, 25 Mar 2014 09:28:57 +0100") References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com> <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com> <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu> <53313E49.1040405@ifi.lmu.de> Message-ID: <8761n2ob4f.fsf@gnu.org> On 2014-03-25 at 09:28:57 +0100, Andreas Abel wrote: [...] > You might wanna pull the break before the release. Fwiw, reverting the new syntax at this point also has an effect on already officially released libraries such as http://hackage.haskell.org/package/containers-0.5.5.1 which started using the new non-pragma annotation[1]; so this would require new hackage uploads (and maybe hackage-deprecations)... just saying... [1]: http://hdiff.luite.com/cgit/containers/commit?id=0.5.5.0 From andreas.abel at ifi.lmu.de Tue Mar 25 11:17:51 2014 From: andreas.abel at ifi.lmu.de (Andreas Abel) Date: Tue, 25 Mar 2014 12:17:51 +0100 Subject: We need to add role annotations for 7.8 In-Reply-To: <8761n2ob4f.fsf@gnu.org> References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com> <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com> <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu> <53313E49.1040405@ifi.lmu.de> <8761n2ob4f.fsf@gnu.org> Message-ID: <533165DF.5030206@ifi.lmu.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 25.03.2014 10:56, Herbert Valerio Riedel wrote: > On 2014-03-25 at 09:28:57 +0100, Andreas Abel wrote: >> You might wanna pull the break before the release. > > Fwiw, reverting the new syntax at this point also has an effect on > already officially released libraries such as > http://hackage.haskell.org/package/containers-0.5.5.1 which > started using the new non-pragma annotation[1]; so this would > require new hackage uploads (and maybe hackage-deprecations)... > just saying... > > [1]: http://hdiff.luite.com/cgit/containers/commit?id=0.5.5.0 Probably it is too late to row back. Even a pragma syntax {-# TYPE_ROLE id role ... role #-} generates a warning on older ghcs: file:1:1: Warning: Unrecognised pragma So that is not a fully smooth alternative to a new syntax---it also has an effect on old instances of the compiler. Though it is only a warning, which can be ignored like a deprecation warning. - -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel at gu.se http://www2.tcs.ifi.lmu.de/~abel/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMxZd8ACgkQPMHaDxpUpLNoQQCg2JWsVkskUfGS4WiSE9zycXrH rqMAnjJ5lg2UgFaYRiWmu9y6SqUs2e2E =jT79 -----END PGP SIGNATURE----- From dan.doel at gmail.com Tue Mar 25 14:29:10 2014 From: dan.doel at gmail.com (Dan Doel) Date: Tue, 25 Mar 2014 10:29:10 -0400 Subject: We need to add role annotations for 7.8 In-Reply-To: <53313E49.1040405@ifi.lmu.de> References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com> <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com> <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu> <53313E49.1040405@ifi.lmu.de> Message-ID: On Tue, Mar 25, 2014 at 4:28 AM, Andreas Abel wrote: > 2. The chosen role names mean nothing to me. It feels a bit like the > term "delegate" used in C# instead of just speaking of a higher-order > function. Looking at the semantics, I find the following translation > > nominal = computational > > That is, the choice of type expression has a computational effect > (like a different implementation of Ord). > > representational = parametric > > The choice of type expression is parametric, i.e., does not lead > to other choices, but is purely propagated through. > > Further, "representational" is a bit long for a keyword. 'nominal' > invokes the exact opposite association for me than it means. In > nominal calculi (Pitts et al), everything is *parametric* in the > choice of names. > Nominal refers to nominal typing, where types are distinguished based on their names. So a type with a nominal argument may do different things based on the name of a type. The opposite of this is typically called "structural." Representational is (for the purposes here, at least) a synonym of that, though. I'd be surprised if this usage of the words wasn't quite a bit more common than knowledge of nominal logic. -- Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Tue Mar 25 15:09:57 2014 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Tue, 25 Mar 2014 08:09:57 -0700 Subject: We need to add role annotations for 7.8 In-Reply-To: <533165DF.5030206@ifi.lmu.de> References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com> <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com> <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu> <53313E49.1040405@ifi.lmu.de> <8761n2ob4f.fsf@gnu.org> <533165DF.5030206@ifi.lmu.de> Message-ID: Thank you to everyone who has been helping me understand this issue in greater depth. *tl;dr: As long as we don't expect any libraries beyond to core to annotate, I'm cool. This presumes that the extra safety isn't, in practice, dependent on transitive adoption by libraries. It also implies that representational is the only possible default, and that there can be no migration from it.* My approach to thinking about this is guided by thinking about supporting an eco-system with 1000s of libraries (hackage), a few dozen of which are heavily promoted (the platform), and a small set that are closely tied to the compiler (the core). The availability, speed of release, motivation, and even skill of the the developers varies widely over that range. I also think about the various "stances" of different developers: - *End developer*: makes use of libraries, but just builds apps - *Internal developer*: makes libraries for internal use in a project - *Casual library writer*: makes libraries, primarily for their own needs, but distributed on hackage - *Popular library writer:* actively maintains libraries which are widely used - *Core library writer: *maintainer of a core package that stays in lock step with the compiler Then, I think about, for each of these, what is the effect on a new feature on them, their existing code, and future code? Does it affect them only if they are using the feature? If they aren't using the feature? For library writers, how does the feature affect clients? If a client wants to use a feature, under what conditions does the library need to do something? This last issue of the "transitivity" the feature is often the biggest concern. *Given that... onto type roles:* The default of *representational* is the only option, because a default of *nominal* would require far too many developers to have to update their code. I don't believe that we can ever migrate to *nominal* as default. The feature implies that any abstract data type that uses a type parameter in certain ways needs annotate to get the full safety afforded now afforded. However, without annotation, the data type is still no worse off than it was before (there is added safety, but not perhaps relevant to the stand point of the library writer). Further, this (pre-existing) non-safety isn't likely a huge concern. Making sure the docs take the tone that most developers need to nothing, and when developers need to be concerned seems like an important way to ensure the right outcome. A key question here is transitivity: Is it possible for module A to not annotate a type, and then have module B by a different author use the type in A in another abstract type, that *is* annotated, and get the benefit. Seems the answer is "partially". If the answer were "no", then use of the feature would be dependent on transitive adoption, and that is where the big burden on developers comes from. The degree to which we believe this "partially" is important: If we are willing to believe that the only library writers we care about doing this are those in the core, then fine. In this case we shouldn't feel compelled to suggest to library writers that they annotate, ever. I'm good with this. If the team here thinks otherwise, that we need to start a campaign to get every library writer to eventually annotate, then I have deep objections. I read the paper, and understand how the authors felt the syntax options were all less than perfect, and choose what they did. But that choice, perhaps unwittingly, the implication that it forces -XCPP on all libraries except perhaps some of the core. This is because they all need to support previous compilers. So, a one line annotation has turned into an ugly beast, and perhaps added -XCPP where there was none, which is really unfortunate. (I, like many, consider it a defeat when one has to resort to -XCPP.) It seems to me that the paper didn't really consider less-perfect, heuristic solutions. It might have had significantly less impact on library writers were some heuristic (no constructors exported? has any type constraint on the parameter? etc..) might have allowed most data types to go without annotation at the cost of a few (where *nominal* was incorrectly inferred) requiring immediate action. In this situation, a non-language feature (pragma or other device) might have been more palatable. Finally, on the choice of terms, *nominal*, *representational*, and *phantom* all seem like clear, self-explanatory choices to me. - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Mar 25 15:47:29 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 25 Mar 2014 15:47:29 +0000 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com> <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com> <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu> <53313E49.1040405@ifi.lmu.de> <8761n2ob4f.fsf@gnu.org> <533165DF.5030206@ifi.lmu.de> Message-ID: <59543203684B2244980D7E4057D5FBC1488BD709@DB3EX14MBXC308.europe.corp.microsoft.com> The degree to which we believe this "partially" is important: If we are willing to believe that the only library writers we care about doing this are those in the core, then fine. In this case we shouldn't feel compelled to suggest to library writers that they annotate, ever. I'm good with this. If the team here thinks otherwise, that we need to start a campaign to get every library writer to eventually annotate, then I have deep objections. The situation today is that ? A client of a library can use GND to do bad things to the library (e.g. change the ?key? type of (Map key value)). ? Role annotations allow the library author to prevent that happening. Would you say that means that we are ?compelled to suggest to library writers that they annotate?? I would have thought that it would indeed be good to suggest to them that a new opportunity exists for them to make their library more robust to clients. They are free to do nothing, or to take advantage of the suggestion. It?s an upside-only situation. Looking further ahead, when you say that ?there can be no migration from representational-by-default?, do you have data to support that? Notably, any client not using GND could not observe a change. So simply seeing how many library modules use GND would be an upper bound on how many libraries would fail to compile you were to ask us to change the default. Is that 1% of Hackage modules? 10%? 0.1%? I don?t know. The awkward bit is that if a client is using GND, which fails after a change to nominal-by-default, the fix is to change the library, not the client, and I can see that is awkward. Simon From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Mark Lentczner Sent: 25 March 2014 15:10 To: libraries at haskell.org Libraries; ghc-devs at haskell.org Subject: Re: We need to add role annotations for 7.8 Thank you to everyone who has been helping me understand this issue in greater depth. tl;dr: As long as we don't expect any libraries beyond to core to annotate, I'm cool. This presumes that the extra safety isn't, in practice, dependent on transitive adoption by libraries. It also implies that representational is the only possible default, and that there can be no migration from it. My approach to thinking about this is guided by thinking about supporting an eco-system with 1000s of libraries (hackage), a few dozen of which are heavily promoted (the platform), and a small set that are closely tied to the compiler (the core). The availability, speed of release, motivation, and even skill of the the developers varies widely over that range. I also think about the various "stances" of different developers: * End developer: makes use of libraries, but just builds apps * Internal developer: makes libraries for internal use in a project * Casual library writer: makes libraries, primarily for their own needs, but distributed on hackage * Popular library writer: actively maintains libraries which are widely used * Core library writer: maintainer of a core package that stays in lock step with the compiler Then, I think about, for each of these, what is the effect on a new feature on them, their existing code, and future code? Does it affect them only if they are using the feature? If they aren't using the feature? For library writers, how does the feature affect clients? If a client wants to use a feature, under what conditions does the library need to do something? This last issue of the "transitivity" the feature is often the biggest concern. Given that... onto type roles: The default of representational is the only option, because a default of nominal would require far too many developers to have to update their code. I don't believe that we can ever migrate to nominal as default. The feature implies that any abstract data type that uses a type parameter in certain ways needs annotate to get the full safety afforded now afforded. However, without annotation, the data type is still no worse off than it was before (there is added safety, but not perhaps relevant to the stand point of the library writer). Further, this (pre-existing) non-safety isn't likely a huge concern. Making sure the docs take the tone that most developers need to nothing, and when developers need to be concerned seems like an important way to ensure the right outcome. A key question here is transitivity: Is it possible for module A to not annotate a type, and then have module B by a different author use the type in A in another abstract type, that is annotated, and get the benefit. Seems the answer is "partially". If the answer were "no", then use of the feature would be dependent on transitive adoption, and that is where the big burden on developers comes from. The degree to which we believe this "partially" is important: If we are willing to believe that the only library writers we care about doing this are those in the core, then fine. In this case we shouldn't feel compelled to suggest to library writers that they annotate, ever. I'm good with this. If the team here thinks otherwise, that we need to start a campaign to get every library writer to eventually annotate, then I have deep objections. I read the paper, and understand how the authors felt the syntax options were all less than perfect, and choose what they did. But that choice, perhaps unwittingly, the implication that it forces -XCPP on all libraries except perhaps some of the core. This is because they all need to support previous compilers. So, a one line annotation has turned into an ugly beast, and perhaps added -XCPP where there was none, which is really unfortunate. (I, like many, consider it a defeat when one has to resort to -XCPP.) It seems to me that the paper didn't really consider less-perfect, heuristic solutions. It might have had significantly less impact on library writers were some heuristic (no constructors exported? has any type constraint on the parameter? etc..) might have allowed most data types to go without annotation at the cost of a few (where nominal was incorrectly inferred) requiring immediate action. In this situation, a non-language feature (pragma or other device) might have been more palatable. Finally, on the choice of terms, nominal, representational, and phantom all seem like clear, self-explanatory choices to me. - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From winterkoninkje at gmail.com Tue Mar 25 22:54:46 2014 From: winterkoninkje at gmail.com (wren romano) Date: Tue, 25 Mar 2014 18:54:46 -0400 Subject: Burning more bridges (mostly numeric ones) In-Reply-To: References: <1393247600013-5744545.post@n5.nabble.com> Message-ID: On Sun, Mar 23, 2014 at 3:11 AM, Edward Kmett wrote: > That said, implicit conversions are something where personally I feel > Haskell does take the right approach. It is the only language I have access > to where I can reason about the semantics of (+) sanely and extend the set > of types. Ditto. It can sometimes be unfortunate that we don't get the subset inclusions for free, but in my experience the few extra annotations required are a small price to pay for all the bugs caught by not doing so-- when doing numerical work! Not to mention that Int does not really have a subset inclusion into Double, and so this implicit coercion should be forbidden even if we did allow implicitly coercing Int to Integer, etc. >> * The multiplicity of exponentiation functions, one of which looks >> exactly like C's XOR operator, which I've watched trip up newbies a >> bunch of times. (Indeed, NumericPrelude seems to have added more of >> these, including the IMHO poorly-named (^-) which has nothing to do >> with numeric negation as far as I can tell. See "unary negation" >> above.) > > It is unfortunate, but there really is a distinction being made. I'd go even farther and say that this is another case where Haskell is doing the right thing. There's a fundamental distinction going on here. The only complaints I have here are: 1) Because the type of the second argument to (^) and (^^) is polymorphic, numeric literals introduce warnings about defaulting. This is the one place where needing to make coercions explicit really does get on my nerves. 2) (^) does not restrict the second argument to non-negative values and thus can throw runtime errors, when it really should be a type error. 3) (**) should probably be split to distinguish exponentials and rational/real-valued powers. To see a clear example of how (^) and (^^) are fundamentally different operators, consider their instantiation for square matrices. We can use (^) whenever the scalars of the matrix form a semiring; whereas using (^^) requires that we be able to invert the matrix, which means the scalars must form a field[1]. [1] I'm not sure off hand if we can weaken the requirements to just be a division ring or (strongly) von Neuman regular ring; but certainly my implementation assumes it's a field. -- Live well, ~wren From eir at cis.upenn.edu Tue Mar 25 23:23:58 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Tue, 25 Mar 2014 19:23:58 -0400 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com> <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com> <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu> <53313E49.1040405@ifi.lmu.de> <8761n2ob4f.fsf@gnu.org> <533165DF.5030206@ifi.lmu.de> Message-ID: <2F0B89D5-0FF1-4107-805D-60B4F7F6FC0D@cis.upenn.edu> Hi Mark, I appreciate your analysis in terms of classes of users -- I think that is helpful for framing the discussion. About transitivity: I think we're in the clear here. Let's say package A exports types missing role annotations. If package B imports package A and wants to have the full safety afforded by roles, that is no problem whatsoever. Package B has annotations on its types (which may use package A's types) that may restrict certain parameters to be nominal, as appropriate. If package A had role annotations, it's quite possible that package B could omit some annotations (as role inference propagates nominal roles), but there is no problem inherent in this. (Indeed, if package A adds annotations in the future, package B would have redundant, but harmless, annotations.) So, I disagree with Mark's "partially" below -- I think we're fully OK in this regard. About heuristics: we briefly considered some, though there's no documentation of this anywhere. Specifically, we thought about giving nominal roles to parameters used in class constraints. The problem is, in the actual datatype definition, the constraints tend not to appear? Should we look around for other functions with constraints? That seems likely to be more confusing than helpful. Furthermore, I strongly don't like the idea of using heuristics to infer a feature such as this -- it can cause strange behavior and is hard to specify. Richard On Mar 25, 2014, at 11:09 AM, Mark Lentczner wrote: > Thank you to everyone who has been helping me understand this issue in greater depth. > > tl;dr: As long as we don't expect any libraries beyond to core to annotate, I'm cool. This presumes that the extra safety isn't, in practice, dependent on transitive adoption by libraries. It also implies that representational is the only possible default, and that there can be no migration from it. > > My approach to thinking about this is guided by thinking about supporting an eco-system with 1000s of libraries (hackage), a few dozen of which are heavily promoted (the platform), and a small set that are closely tied to the compiler (the core). The availability, speed of release, motivation, and even skill of the the developers varies widely over that range. > > I also think about the various "stances" of different developers: > End developer: makes use of libraries, but just builds apps > Internal developer: makes libraries for internal use in a project > Casual library writer: makes libraries, primarily for their own needs, but distributed on hackage > Popular library writer: actively maintains libraries which are widely used > Core library writer: maintainer of a core package that stays in lock step with the compiler > Then, I think about, for each of these, what is the effect on a new feature on them, their existing code, and future code? Does it affect them only if they are using the feature? If they aren't using the feature? For library writers, how does the feature affect clients? If a client wants to use a feature, under what conditions does the library need to do something? This last issue of the "transitivity" the feature is often the biggest concern. > > Given that... onto type roles: > > The default of representational is the only option, because a default of nominal would require far too many developers to have to update their code. I don't believe that we can ever migrate to nominal as default. > > The feature implies that any abstract data type that uses a type parameter in certain ways needs annotate to get the full safety afforded now afforded. However, without annotation, the data type is still no worse off than it was before (there is added safety, but not perhaps relevant to the stand point of the library writer). Further, this (pre-existing) non-safety isn't likely a huge concern. Making sure the docs take the tone that most developers need to nothing, and when developers need to be concerned seems like an important way to ensure the right outcome. > > A key question here is transitivity: Is it possible for module A to not annotate a type, and then have module B by a different author use the type in A in another abstract type, that is annotated, and get the benefit. Seems the answer is "partially". If the answer were "no", then use of the feature would be dependent on transitive adoption, and that is where the big burden on developers comes from. > > The degree to which we believe this "partially" is important: If we are willing to believe that the only library writers we care about doing this are those in the core, then fine. In this case we shouldn't feel compelled to suggest to library writers that they annotate, ever. I'm good with this. If the team here thinks otherwise, that we need to start a campaign to get every library writer to eventually annotate, then I have deep objections. > > I read the paper, and understand how the authors felt the syntax options were all less than perfect, and choose what they did. But that choice, perhaps unwittingly, the implication that it forces -XCPP on all libraries except perhaps some of the core. This is because they all need to support previous compilers. So, a one line annotation has turned into an ugly beast, and perhaps added -XCPP where there was none, which is really unfortunate. (I, like many, consider it a defeat when one has to resort to -XCPP.) > > It seems to me that the paper didn't really consider less-perfect, heuristic solutions. It might have had significantly less impact on library writers were some heuristic (no constructors exported? has any type constraint on the parameter? etc..) might have allowed most data types to go without annotation at the cost of a few (where nominal was incorrectly inferred) requiring immediate action. In this situation, a non-language feature (pragma or other device) might have been more palatable. > > Finally, on the choice of terms, nominal, representational, and phantom all seem like clear, self-explanatory choices to me. > > - Mark > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From cam at uptoisomorphism.net Wed Mar 26 15:10:19 2014 From: cam at uptoisomorphism.net (Casey McCann) Date: Wed, 26 Mar 2014 11:10:19 -0400 Subject: Burning more bridges (mostly numeric ones) In-Reply-To: References: <1393247600013-5744545.post@n5.nabble.com> Message-ID: On Tue, Mar 25, 2014 at 6:54 PM, wren romano wrote: >>> * The multiplicity of exponentiation functions, one of which looks >>> exactly like C's XOR operator, which I've watched trip up newbies a >>> bunch of times. (Indeed, NumericPrelude seems to have added more of >>> these, including the IMHO poorly-named (^-) which has nothing to do >>> with numeric negation as far as I can tell. See "unary negation" >>> above.) >> >> It is unfortunate, but there really is a distinction being made. > > I'd go even farther and say that this is another case where Haskell is > doing the right thing. There's a fundamental distinction going on > here. The only complaints I have here are: > > 1) Because the type of the second argument to (^) and (^^) is > polymorphic, numeric literals introduce warnings about defaulting. > This is the one place where needing to make coercions explicit really > does get on my nerves. This situation really should not be a warning. It's an Integral constraint on a type in contravariant position, which by itself can only be ambiguous if it's given something built from numeric literals and basic arithmetic. Having an Integral instance means a type supports conversions to and from Integer, and I would be very dubious about a type where (fromInteger . toInteger) was not equivalent to id. I really can't see how defaulting an Integral constraint alone to Integer is anything other than safe and sensible. Unfortunately the same type may have other class constraints for which defaulting to Integer would be ridiculous, and if memory serves me the way defaults work doesn't distinguish between the clearly sensible-to-default "6 ^ 12" and the equally not sensible "3 ^ read userInput". In fact, I'd prefer that any type with a Read constraint not default at all, ever. That's just asking for trouble. On the other hand, a warning probably makes sense when defaulting a type with e.g. a Show constraint, or Num (without Integral as well). I'm not sure what exact rules would make the most sense here, but I don't think the current defaulting mechanism would support anything more sophisticated anyhow, so it's not a library issue. > 2) (^) does not restrict the second argument to non-negative values > and thus can throw runtime errors, when it really should be a type > error. ...which would require a Natural type similar to Integer, and probably the corresponding type classes as well, which among other things entails adding a superclass to Num containing fromNatural (and, ideally, containing (+) and (*) as well). That's a pretty big bridge to burn, albeit a very temptingly flammable one. - C. From cam at uptoisomorphism.net Wed Mar 26 15:40:52 2014 From: cam at uptoisomorphism.net (Casey McCann) Date: Wed, 26 Mar 2014 11:40:52 -0400 Subject: We need to add role annotations for 7.8 In-Reply-To: <2F0B89D5-0FF1-4107-805D-60B4F7F6FC0D@cis.upenn.edu> References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com> <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com> <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu> <53313E49.1040405@ifi.lmu.de> <8761n2ob4f.fsf@gnu.org> <533165DF.5030206@ifi.lmu.de> <2F0B89D5-0FF1-4107-805D-60B4F7F6FC0D@cis.upenn.edu> Message-ID: Were any rules considered along the lines of "Representational by default if all the type's constructors are exported by a module not named 'Internal', nominal by default otherwise"? Better would probably include "exported by a module the package exposes" but that's disgustingly non-local if it's even possible at all. The module name thing is hacky to the extreme but at least it's a simple rule rather than some obscure and opaque heuristics. Anyway, the goal of something like that would be not so much "figure out what it should be", since that's impossible, but more "default to nominal if and only if there's clear indication the user is already thinking about restricting how the type is used". Not that I'm really even suggesting such a rule, just wondering if it was discussed. - C. On Tue, Mar 25, 2014 at 7:23 PM, Richard Eisenberg wrote: > Hi Mark, > > I appreciate your analysis in terms of classes of users -- I think that is > helpful for framing the discussion. > > About transitivity: I think we're in the clear here. Let's say package A > exports types missing role annotations. If package B imports package A and > wants to have the full safety afforded by roles, that is no problem > whatsoever. Package B has annotations on its types (which may use package > A's types) that may restrict certain parameters to be nominal, as > appropriate. If package A had role annotations, it's quite possible that > package B could omit some annotations (as role inference propagates nominal > roles), but there is no problem inherent in this. (Indeed, if package A adds > annotations in the future, package B would have redundant, but harmless, > annotations.) So, I disagree with Mark's "partially" below -- I think we're > fully OK in this regard. > > About heuristics: we briefly considered some, though there's no > documentation of this anywhere. Specifically, we thought about giving > nominal roles to parameters used in class constraints. The problem is, in > the actual datatype definition, the constraints tend not to appear? Should > we look around for other functions with constraints? That seems likely to be > more confusing than helpful. Furthermore, I strongly don't like the idea of > using heuristics to infer a feature such as this -- it can cause strange > behavior and is hard to specify. > > Richard > > On Mar 25, 2014, at 11:09 AM, Mark Lentczner wrote: > > Thank you to everyone who has been helping me understand this issue in > greater depth. > > tl;dr: As long as we don't expect any libraries beyond to core to annotate, > I'm cool. This presumes that the extra safety isn't, in practice, dependent > on transitive adoption by libraries. It also implies that representational > is the only possible default, and that there can be no migration from it. > > My approach to thinking about this is guided by thinking about supporting an > eco-system with 1000s of libraries (hackage), a few dozen of which are > heavily promoted (the platform), and a small set that are closely tied to > the compiler (the core). The availability, speed of release, motivation, and > even skill of the the developers varies widely over that range. > > I also think about the various "stances" of different developers: > > End developer: makes use of libraries, but just builds apps > Internal developer: makes libraries for internal use in a project > Casual library writer: makes libraries, primarily for their own needs, but > distributed on hackage > Popular library writer: actively maintains libraries which are widely used > Core library writer: maintainer of a core package that stays in lock step > with the compiler > > Then, I think about, for each of these, what is the effect on a new feature > on them, their existing code, and future code? Does it affect them only if > they are using the feature? If they aren't using the feature? For library > writers, how does the feature affect clients? If a client wants to use a > feature, under what conditions does the library need to do something? This > last issue of the "transitivity" the feature is often the biggest concern. > > Given that... onto type roles: > > The default of representational is the only option, because a default of > nominal would require far too many developers to have to update their code. > I don't believe that we can ever migrate to nominal as default. > > The feature implies that any abstract data type that uses a type parameter > in certain ways needs annotate to get the full safety afforded now afforded. > However, without annotation, the data type is still no worse off than it was > before (there is added safety, but not perhaps relevant to the stand point > of the library writer). Further, this (pre-existing) non-safety isn't likely > a huge concern. Making sure the docs take the tone that most developers need > to nothing, and when developers need to be concerned seems like an important > way to ensure the right outcome. > > A key question here is transitivity: Is it possible for module A to not > annotate a type, and then have module B by a different author use the type > in A in another abstract type, that is annotated, and get the benefit. Seems > the answer is "partially". If the answer were "no", then use of the feature > would be dependent on transitive adoption, and that is where the big burden > on developers comes from. > > The degree to which we believe this "partially" is important: If we are > willing to believe that the only library writers we care about doing this > are those in the core, then fine. In this case we shouldn't feel compelled > to suggest to library writers that they annotate, ever. I'm good with this. > If the team here thinks otherwise, that we need to start a campaign to get > every library writer to eventually annotate, then I have deep objections. > > I read the paper, and understand how the authors felt the syntax options > were all less than perfect, and choose what they did. But that choice, > perhaps unwittingly, the implication that it forces -XCPP on all libraries > except perhaps some of the core. This is because they all need to support > previous compilers. So, a one line annotation has turned into an ugly beast, > and perhaps added -XCPP where there was none, which is really unfortunate. > (I, like many, consider it a defeat when one has to resort to -XCPP.) > > It seems to me that the paper didn't really consider less-perfect, heuristic > solutions. It might have had significantly less impact on library writers > were some heuristic (no constructors exported? has any type constraint on > the parameter? etc..) might have allowed most data types to go without > annotation at the cost of a few (where nominal was incorrectly inferred) > requiring immediate action. In this situation, a non-language feature > (pragma or other device) might have been more palatable. > > Finally, on the choice of terms, nominal, representational, and phantom all > seem like clear, self-explanatory choices to me. > > - Mark > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From carter.schonwald at gmail.com Wed Mar 26 15:42:53 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 26 Mar 2014 11:42:53 -0400 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com> <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com> <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu> <53313E49.1040405@ifi.lmu.de> <8761n2ob4f.fsf@gnu.org> <533165DF.5030206@ifi.lmu.de> <2F0B89D5-0FF1-4107-805D-60B4F7F6FC0D@cis.upenn.edu> Message-ID: I think something like that is on the table, at least for a future ghc release. I'm not sure if it made it into the patches for 7.8.1. But this was actually suggested on the relevant ticket last week. (I'm Afk otherwise id dig up the link) On Wednesday, March 26, 2014, Casey McCann wrote: > Were any rules considered along the lines of "Representational by > default if all the type's constructors are exported by a module not > named 'Internal', nominal by default otherwise"? Better would probably > include "exported by a module the package exposes" but that's > disgustingly non-local if it's even possible at all. The module name > thing is hacky to the extreme but at least it's a simple rule rather > than some obscure and opaque heuristics. > > Anyway, the goal of something like that would be not so much "figure > out what it should be", since that's impossible, but more "default to > nominal if and only if there's clear indication the user is already > thinking about restricting how the type is used". > > Not that I'm really even suggesting such a rule, just wondering if it > was discussed. > > - C. > > > On Tue, Mar 25, 2014 at 7:23 PM, Richard Eisenberg > wrote: > > Hi Mark, > > > > I appreciate your analysis in terms of classes of users -- I think that > is > > helpful for framing the discussion. > > > > About transitivity: I think we're in the clear here. Let's say package A > > exports types missing role annotations. If package B imports package A > and > > wants to have the full safety afforded by roles, that is no problem > > whatsoever. Package B has annotations on its types (which may use package > > A's types) that may restrict certain parameters to be nominal, as > > appropriate. If package A had role annotations, it's quite possible that > > package B could omit some annotations (as role inference propagates > nominal > > roles), but there is no problem inherent in this. (Indeed, if package A > adds > > annotations in the future, package B would have redundant, but harmless, > > annotations.) So, I disagree with Mark's "partially" below -- I think > we're > > fully OK in this regard. > > > > About heuristics: we briefly considered some, though there's no > > documentation of this anywhere. Specifically, we thought about giving > > nominal roles to parameters used in class constraints. The problem is, in > > the actual datatype definition, the constraints tend not to appear? > Should > > we look around for other functions with constraints? That seems likely > to be > > more confusing than helpful. Furthermore, I strongly don't like the idea > of > > using heuristics to infer a feature such as this -- it can cause strange > > behavior and is hard to specify. > > > > Richard > > > > On Mar 25, 2014, at 11:09 AM, Mark Lentczner wrote: > > > > Thank you to everyone who has been helping me understand this issue in > > greater depth. > > > > tl;dr: As long as we don't expect any libraries beyond to core to > annotate, > > I'm cool. This presumes that the extra safety isn't, in practice, > dependent > > on transitive adoption by libraries. It also implies that > representational > > is the only possible default, and that there can be no migration from it. > > > > My approach to thinking about this is guided by thinking about > supporting an > > eco-system with 1000s of libraries (hackage), a few dozen of which are > > heavily promoted (the platform), and a small set that are closely tied to > > the compiler (the core). The availability, speed of release, motivation, > and > > even skill of the the developers varies widely over that range. > > > > I also think about the various "stances" of different developers: > > > > End developer: makes use of libraries, but just builds apps > > Internal developer: makes libraries for internal use in a project > > Casual library writer: makes libraries, primarily for their own needs, > but > > distributed on hackage > > Popular library writer: actively maintains libraries which are widely > used > > Core library writer: maintainer of a core package that stays in lock step > > with the compiler > > > > Then, I think about, for each of these, what is the effect on a new > feature > > on them, their existing code, and future code? Does it affect them only > if > > they are using the feature? If they aren't using the feature? For library > > writers, how does the feature affect clients? If a client wants to use a > > feature, under what conditions does the library need to do something? > This > > last issue of the "transitivity" the feature is often the biggest > concern. > > > > Given that... onto type roles: > > > > The default of representational is the only option, because a default of > > nominal would require far too many developers to have to update their > code. > > I don't believe that we can ever migrate to nominal as default. > > > > The feature implies that any abstract data type that uses a type > parameter > > in certain ways needs annotate to get the full safety afforded now > afforded. > > However, without annotation, the data type is still no worse off than it > was > > before (there is added safety, but not perhaps relevant to the stand > point > > of the library writer). Further, this (pre-existing) non-safety isn't > likely > > a huge concern. Making sure the docs take the tone that most developers > need > > to nothing, and when developers need to be concerned seems like an > important > > way to ensure the right outcome. > > > > A key question here is transitivity: Is it possible for module A to not > > annotate a type, and then have module B b> > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From schlepptop at henning-thielemann.de Wed Mar 26 20:19:06 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Wed, 26 Mar 2014 21:19:06 +0100 Subject: Burning more bridges (mostly numeric ones) In-Reply-To: References: <1393247600013-5744545.post@n5.nabble.com> Message-ID: <5333363A.8080900@henning-thielemann.de> Am 26.03.2014 16:10, schrieb Casey McCann: > This situation really should not be a warning. It's an Integral > constraint on a type in contravariant position, which by itself can > only be ambiguous if it's given something built from numeric literals > and basic arithmetic. Having an Integral instance means a type > supports conversions to and from Integer, and I would be very dubious > about a type where (fromInteger . toInteger) was not equivalent to id. > I really can't see how defaulting an Integral constraint alone to > Integer is anything other than safe and sensible. In NumericPrelude I decided to fix the exponent type to Integer. 1. This solves the defaulting problem. 2. Most of the time in my code the exponent is constant and is 2. 3. It broke a dependency cycle between the numeric classes. From eir at cis.upenn.edu Thu Mar 27 02:50:21 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 26 Mar 2014 22:50:21 -0400 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com> <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com> <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu> <53313E49.1040405@ifi.lmu.de> <8761n2ob4f.fsf@gnu.org> <533165DF.5030206@ifi.lmu.de> <2F0B89D5-0FF1-4107-805D-60B4F7F6FC0D@cis.upenn.edu> Message-ID: Not for more than a passing mention. Using the name of the module to control the default makes me unhappy (should choice of name be relevant in the correctness / interpretation of a program?). Other heuristics (presence of constrained functions) seem quite fragile. Of everything said so far, I think the closest suggestion is to use constrained datatypes (like `data Ord a => Set a = ...`), but that mis-appropriates datatype contexts (which are silly) into something new and different, and so I personally don't think it's really viable. Following Mark's idea of breaking this problem up into more manageable chunks, I would want us to think about two separate (and conflicting, often) users: 1. Users of today's Haskell who have to update their code. 2. Users of Haskell in 10 years. Would users in group (2) like these heuristics? I doubt it. I think users in group (2) would probably most like a default of nominal with role annotations (in some concrete syntax). But, users in group (1) would hate a nominal default, so we have a compromise. Richard On Mar 26, 2014, at 11:40 AM, Casey McCann wrote: > Were any rules considered along the lines of "Representational by > default if all the type's constructors are exported by a module not > named 'Internal', nominal by default otherwise"? Better would probably > include "exported by a module the package exposes" but that's > disgustingly non-local if it's even possible at all. The module name > thing is hacky to the extreme but at least it's a simple rule rather > than some obscure and opaque heuristics. > > Anyway, the goal of something like that would be not so much "figure > out what it should be", since that's impossible, but more "default to > nominal if and only if there's clear indication the user is already > thinking about restricting how the type is used". > > Not that I'm really even suggesting such a rule, just wondering if it > was discussed. > > - C. > > > On Tue, Mar 25, 2014 at 7:23 PM, Richard Eisenberg wrote: >> Hi Mark, >> >> I appreciate your analysis in terms of classes of users -- I think that is >> helpful for framing the discussion. >> >> About transitivity: I think we're in the clear here. Let's say package A >> exports types missing role annotations. If package B imports package A and >> wants to have the full safety afforded by roles, that is no problem >> whatsoever. Package B has annotations on its types (which may use package >> A's types) that may restrict certain parameters to be nominal, as >> appropriate. If package A had role annotations, it's quite possible that >> package B could omit some annotations (as role inference propagates nominal >> roles), but there is no problem inherent in this. (Indeed, if package A adds >> annotations in the future, package B would have redundant, but harmless, >> annotations.) So, I disagree with Mark's "partially" below -- I think we're >> fully OK in this regard. >> >> About heuristics: we briefly considered some, though there's no >> documentation of this anywhere. Specifically, we thought about giving >> nominal roles to parameters used in class constraints. The problem is, in >> the actual datatype definition, the constraints tend not to appear? Should >> we look around for other functions with constraints? That seems likely to be >> more confusing than helpful. Furthermore, I strongly don't like the idea of >> using heuristics to infer a feature such as this -- it can cause strange >> behavior and is hard to specify. >> >> Richard >> >> On Mar 25, 2014, at 11:09 AM, Mark Lentczner wrote: >> >> Thank you to everyone who has been helping me understand this issue in >> greater depth. >> >> tl;dr: As long as we don't expect any libraries beyond to core to annotate, >> I'm cool. This presumes that the extra safety isn't, in practice, dependent >> on transitive adoption by libraries. It also implies that representational >> is the only possible default, and that there can be no migration from it. >> >> My approach to thinking about this is guided by thinking about supporting an >> eco-system with 1000s of libraries (hackage), a few dozen of which are >> heavily promoted (the platform), and a small set that are closely tied to >> the compiler (the core). The availability, speed of release, motivation, and >> even skill of the the developers varies widely over that range. >> >> I also think about the various "stances" of different developers: >> >> End developer: makes use of libraries, but just builds apps >> Internal developer: makes libraries for internal use in a project >> Casual library writer: makes libraries, primarily for their own needs, but >> distributed on hackage >> Popular library writer: actively maintains libraries which are widely used >> Core library writer: maintainer of a core package that stays in lock step >> with the compiler >> >> Then, I think about, for each of these, what is the effect on a new feature >> on them, their existing code, and future code? Does it affect them only if >> they are using the feature? If they aren't using the feature? For library >> writers, how does the feature affect clients? If a client wants to use a >> feature, under what conditions does the library need to do something? This >> last issue of the "transitivity" the feature is often the biggest concern. >> >> Given that... onto type roles: >> >> The default of representational is the only option, because a default of >> nominal would require far too many developers to have to update their code. >> I don't believe that we can ever migrate to nominal as default. >> >> The feature implies that any abstract data type that uses a type parameter >> in certain ways needs annotate to get the full safety afforded now afforded. >> However, without annotation, the data type is still no worse off than it was >> before (there is added safety, but not perhaps relevant to the stand point >> of the library writer). Further, this (pre-existing) non-safety isn't likely >> a huge concern. Making sure the docs take the tone that most developers need >> to nothing, and when developers need to be concerned seems like an important >> way to ensure the right outcome. >> >> A key question here is transitivity: Is it possible for module A to not >> annotate a type, and then have module B by a different author use the type >> in A in another abstract type, that is annotated, and get the benefit. Seems >> the answer is "partially". If the answer were "no", then use of the feature >> would be dependent on transitive adoption, and that is where the big burden >> on developers comes from. >> >> The degree to which we believe this "partially" is important: If we are >> willing to believe that the only library writers we care about doing this >> are those in the core, then fine. In this case we shouldn't feel compelled >> to suggest to library writers that they annotate, ever. I'm good with this. >> If the team here thinks otherwise, that we need to start a campaign to get >> every library writer to eventually annotate, then I have deep objections. >> >> I read the paper, and understand how the authors felt the syntax options >> were all less than perfect, and choose what they did. But that choice, >> perhaps unwittingly, the implication that it forces -XCPP on all libraries >> except perhaps some of the core. This is because they all need to support >> previous compilers. So, a one line annotation has turned into an ugly beast, >> and perhaps added -XCPP where there was none, which is really unfortunate. >> (I, like many, consider it a defeat when one has to resort to -XCPP.) >> >> It seems to me that the paper didn't really consider less-perfect, heuristic >> solutions. It might have had significantly less impact on library writers >> were some heuristic (no constructors exported? has any type constraint on >> the parameter? etc..) might have allowed most data types to go without >> annotation at the cost of a few (where nominal was incorrectly inferred) >> requiring immediate action. In this situation, a non-language feature >> (pragma or other device) might have been more palatable. >> >> Finally, on the choice of terms, nominal, representational, and phantom all >> seem like clear, self-explanatory choices to me. >> >> - Mark >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> From ekmett at gmail.com Thu Mar 27 03:46:29 2014 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 26 Mar 2014 23:46:29 -0400 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com> <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com> <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu> <53313E49.1040405@ifi.lmu.de> <8761n2ob4f.fsf@gnu.org> <533165DF.5030206@ifi.lmu.de> <2F0B89D5-0FF1-4107-805D-60B4F7F6FC0D@cis.upenn.edu> Message-ID: Personally, looking at it 10 years on, having a nominal default would look pretty terrible to me. I'd be stuck annotating everything I write. Nothing easy could just be easy. The 10 years on crowd is a reasonable argument for a "real" type role syntax, and it was indeed that argument that won me over, but if anything the 10 year argument goes the other way for me on a nominal vs representational default. -Edward On Wed, Mar 26, 2014 at 10:50 PM, Richard Eisenberg wrote: > Not for more than a passing mention. Using the name of the module to > control the default makes me unhappy (should choice of name be relevant in > the correctness / interpretation of a program?). Other heuristics (presence > of constrained functions) seem quite fragile. Of everything said so far, I > think the closest suggestion is to use constrained datatypes (like `data > Ord a => Set a = ...`), but that mis-appropriates datatype contexts (which > are silly) into something new and different, and so I personally don't > think it's really viable. > > Following Mark's idea of breaking this problem up into more manageable > chunks, I would want us to think about two separate (and conflicting, > often) users: > > 1. Users of today's Haskell who have to update their code. > 2. Users of Haskell in 10 years. > > Would users in group (2) like these heuristics? I doubt it. I think users > in group (2) would probably most like a default of nominal with role > annotations (in some concrete syntax). But, users in group (1) would hate a > nominal default, so we have a compromise. > > Richard > > On Mar 26, 2014, at 11:40 AM, Casey McCann > wrote: > > > Were any rules considered along the lines of "Representational by > > default if all the type's constructors are exported by a module not > > named 'Internal', nominal by default otherwise"? Better would probably > > include "exported by a module the package exposes" but that's > > disgustingly non-local if it's even possible at all. The module name > > thing is hacky to the extreme but at least it's a simple rule rather > > than some obscure and opaque heuristics. > > > > Anyway, the goal of something like that would be not so much "figure > > out what it should be", since that's impossible, but more "default to > > nominal if and only if there's clear indication the user is already > > thinking about restricting how the type is used". > > > > Not that I'm really even suggesting such a rule, just wondering if it > > was discussed. > > > > - C. > > > > > > On Tue, Mar 25, 2014 at 7:23 PM, Richard Eisenberg > wrote: > >> Hi Mark, > >> > >> I appreciate your analysis in terms of classes of users -- I think that > is > >> helpful for framing the discussion. > >> > >> About transitivity: I think we're in the clear here. Let's say package A > >> exports types missing role annotations. If package B imports package A > and > >> wants to have the full safety afforded by roles, that is no problem > >> whatsoever. Package B has annotations on its types (which may use > package > >> A's types) that may restrict certain parameters to be nominal, as > >> appropriate. If package A had role annotations, it's quite possible that > >> package B could omit some annotations (as role inference propagates > nominal > >> roles), but there is no problem inherent in this. (Indeed, if package A > adds > >> annotations in the future, package B would have redundant, but harmless, > >> annotations.) So, I disagree with Mark's "partially" below -- I think > we're > >> fully OK in this regard. > >> > >> About heuristics: we briefly considered some, though there's no > >> documentation of this anywhere. Specifically, we thought about giving > >> nominal roles to parameters used in class constraints. The problem is, > in > >> the actual datatype definition, the constraints tend not to appear? > Should > >> we look around for other functions with constraints? That seems likely > to be > >> more confusing than helpful. Furthermore, I strongly don't like the > idea of > >> using heuristics to infer a feature such as this -- it can cause strange > >> behavior and is hard to specify. > >> > >> Richard > >> > >> On Mar 25, 2014, at 11:09 AM, Mark Lentczner wrote: > >> > >> Thank you to everyone who has been helping me understand this issue in > >> greater depth. > >> > >> tl;dr: As long as we don't expect any libraries beyond to core to > annotate, > >> I'm cool. This presumes that the extra safety isn't, in practice, > dependent > >> on transitive adoption by libraries. It also implies that > representational > >> is the only possible default, and that there can be no migration from > it. > >> > >> My approach to thinking about this is guided by thinking about > supporting an > >> eco-system with 1000s of libraries (hackage), a few dozen of which are > >> heavily promoted (the platform), and a small set that are closely tied > to > >> the compiler (the core). The availability, speed of release, > motivation, and > >> even skill of the the developers varies widely over that range. > >> > >> I also think about the various "stances" of different developers: > >> > >> End developer: makes use of libraries, but just builds apps > >> Internal developer: makes libraries for internal use in a project > >> Casual library writer: makes libraries, primarily for their own needs, > but > >> distributed on hackage > >> Popular library writer: actively maintains libraries which are widely > used > >> Core library writer: maintainer of a core package that stays in lock > step > >> with the compiler > >> > >> Then, I think about, for each of these, what is the effect on a new > feature > >> on them, their existing code, and future code? Does it affect them only > if > >> they are using the feature? If they aren't using the feature? For > library > >> writers, how does the feature affect clients? If a client wants to use a > >> feature, under what conditions does the library need to do something? > This > >> last issue of the "transitivity" the feature is often the biggest > concern. > >> > >> Given that... onto type roles: > >> > >> The default of representational is the only option, because a default of > >> nominal would require far too many developers to have to update their > code. > >> I don't believe that we can ever migrate to nominal as default. > >> > >> The feature implies that any abstract data type that uses a type > parameter > >> in certain ways needs annotate to get the full safety afforded now > afforded. > >> However, without annotation, the data type is still no worse off than > it was > >> before (there is added safety, but not perhaps relevant to the stand > point > >> of the library writer). Further, this (pre-existing) non-safety isn't > likely > >> a huge concern. Making sure the docs take the tone that most developers > need > >> to nothing, and when developers need to be concerned seems like an > important > >> way to ensure the right outcome. > >> > >> A key question here is transitivity: Is it possible for module A to not > >> annotate a type, and then have module B by a different author use the > type > >> in A in another abstract type, that is annotated, and get the benefit. > Seems > >> the answer is "partially". If the answer were "no", then use of the > feature > >> would be dependent on transitive adoption, and that is where the big > burden > >> on developers comes from. > >> > >> The degree to which we believe this "partially" is important: If we are > >> willing to believe that the only library writers we care about doing > this > >> are those in the core, then fine. In this case we shouldn't feel > compelled > >> to suggest to library writers that they annotate, ever. I'm good with > this. > >> If the team here thinks otherwise, that we need to start a campaign to > get > >> every library writer to eventually annotate, then I have deep > objections. > >> > >> I read the paper, and understand how the authors felt the syntax options > >> were all less than perfect, and choose what they did. But that choice, > >> perhaps unwittingly, the implication that it forces -XCPP on all > libraries > >> except perhaps some of the core. This is because they all need to > support > >> previous compilers. So, a one line annotation has turned into an ugly > beast, > >> and perhaps added -XCPP where there was none, which is really > unfortunate. > >> (I, like many, consider it a defeat when one has to resort to -XCPP.) > >> > >> It seems to me that the paper didn't really consider less-perfect, > heuristic > >> solutions. It might have had significantly less impact on library > writers > >> were some heuristic (no constructors exported? has any type constraint > on > >> the parameter? etc..) might have allowed most data types to go without > >> annotation at the cost of a few (where nominal was incorrectly inferred) > >> requiring immediate action. In this situation, a non-language feature > >> (pragma or other device) might have been more palatable. > >> > >> Finally, on the choice of terms, nominal, representational, and phantom > all > >> seem like clear, self-explanatory choices to me. > >> > >> - Mark > >> > >> _______________________________________________ > >> ghc-devs mailing list > >> ghc-devs at haskell.org > >> http://www.haskell.org/mailman/listinfo/ghc-devs > >> > >> > >> > >> _______________________________________________ > >> Libraries mailing list > >> Libraries at haskell.org > >> http://www.haskell.org/mailman/listinfo/libraries > >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ganesh at earth.li Thu Mar 27 06:44:21 2014 From: ganesh at earth.li (Ganesh Sittampalam) Date: Thu, 27 Mar 2014 06:44:21 +0000 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com> <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com> <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu> <53313E49.1040405@ifi.lmu.de> <8761n2ob4f.fsf@gnu.org> <533165DF.5030206@ifi.lmu.de> <2F0B89D5-0FF1-4107-805D-60B4F7F6FC0D@cis.upenn.edu> Message-ID: <5333C8C5.4060802@earth.li> I think that in theory the basic principle should be that by default you can only write a GND if you could have written it by hand in the same scope - i.e. you can only do it if you have access to the relevant methods and datatype constructors etc. Alternatively the library author might have made an explicit choice to override that default in either direction. I'm not sure how easy it would be to achieve that exact solution in practice, but it might guide the 10-year vision for point (2) below. On 27/03/2014 02:50, Richard Eisenberg wrote: > Not for more than a passing mention. Using the name of the module to control the default makes me unhappy (should choice of name be relevant in the correctness / interpretation of a program?). Other heuristics (presence of constrained functions) seem quite fragile. Of everything said so far, I think the closest suggestion is to use constrained datatypes (like `data Ord a => Set a = ...`), but that mis-appropriates datatype contexts (which are silly) into something new and different, and so I personally don't think it's really viable. > > Following Mark's idea of breaking this problem up into more manageable chunks, I would want us to think about two separate (and conflicting, often) users: > > 1. Users of today's Haskell who have to update their code. > 2. Users of Haskell in 10 years. > > Would users in group (2) like these heuristics? I doubt it. I think users in group (2) would probably most like a default of nominal with role annotations (in some concrete syntax). But, users in group (1) would hate a nominal default, so we have a compromise. > > Richard > > On Mar 26, 2014, at 11:40 AM, Casey McCann wrote: > >> Were any rules considered along the lines of "Representational by >> default if all the type's constructors are exported by a module not >> named 'Internal', nominal by default otherwise"? Better would probably >> include "exported by a module the package exposes" but that's >> disgustingly non-local if it's even possible at all. The module name >> thing is hacky to the extreme but at least it's a simple rule rather >> than some obscure and opaque heuristics. >> >> Anyway, the goal of something like that would be not so much "figure >> out what it should be", since that's impossible, but more "default to >> nominal if and only if there's clear indication the user is already >> thinking about restricting how the type is used". >> >> Not that I'm really even suggesting such a rule, just wondering if it >> was discussed. >> >> - C. >> >> >> On Tue, Mar 25, 2014 at 7:23 PM, Richard Eisenberg wrote: >>> Hi Mark, >>> >>> I appreciate your analysis in terms of classes of users -- I think that is >>> helpful for framing the discussion. >>> >>> About transitivity: I think we're in the clear here. Let's say package A >>> exports types missing role annotations. If package B imports package A and >>> wants to have the full safety afforded by roles, that is no problem >>> whatsoever. Package B has annotations on its types (which may use package >>> A's types) that may restrict certain parameters to be nominal, as >>> appropriate. If package A had role annotations, it's quite possible that >>> package B could omit some annotations (as role inference propagates nominal >>> roles), but there is no problem inherent in this. (Indeed, if package A adds >>> annotations in the future, package B would have redundant, but harmless, >>> annotations.) So, I disagree with Mark's "partially" below -- I think we're >>> fully OK in this regard. >>> >>> About heuristics: we briefly considered some, though there's no >>> documentation of this anywhere. Specifically, we thought about giving >>> nominal roles to parameters used in class constraints. The problem is, in >>> the actual datatype definition, the constraints tend not to appear? Should >>> we look around for other functions with constraints? That seems likely to be >>> more confusing than helpful. Furthermore, I strongly don't like the idea of >>> using heuristics to infer a feature such as this -- it can cause strange >>> behavior and is hard to specify. >>> >>> Richard >>> >>> On Mar 25, 2014, at 11:09 AM, Mark Lentczner wrote: >>> >>> Thank you to everyone who has been helping me understand this issue in >>> greater depth. >>> >>> tl;dr: As long as we don't expect any libraries beyond to core to annotate, >>> I'm cool. This presumes that the extra safety isn't, in practice, dependent >>> on transitive adoption by libraries. It also implies that representational >>> is the only possible default, and that there can be no migration from it. >>> >>> My approach to thinking about this is guided by thinking about supporting an >>> eco-system with 1000s of libraries (hackage), a few dozen of which are >>> heavily promoted (the platform), and a small set that are closely tied to >>> the compiler (the core). The availability, speed of release, motivation, and >>> even skill of the the developers varies widely over that range. >>> >>> I also think about the various "stances" of different developers: >>> >>> End developer: makes use of libraries, but just builds apps >>> Internal developer: makes libraries for internal use in a project >>> Casual library writer: makes libraries, primarily for their own needs, but >>> distributed on hackage >>> Popular library writer: actively maintains libraries which are widely used >>> Core library writer: maintainer of a core package that stays in lock step >>> with the compiler >>> >>> Then, I think about, for each of these, what is the effect on a new feature >>> on them, their existing code, and future code? Does it affect them only if >>> they are using the feature? If they aren't using the feature? For library >>> writers, how does the feature affect clients? If a client wants to use a >>> feature, under what conditions does the library need to do something? This >>> last issue of the "transitivity" the feature is often the biggest concern. >>> >>> Given that... onto type roles: >>> >>> The default of representational is the only option, because a default of >>> nominal would require far too many developers to have to update their code. >>> I don't believe that we can ever migrate to nominal as default. >>> >>> The feature implies that any abstract data type that uses a type parameter >>> in certain ways needs annotate to get the full safety afforded now afforded. >>> However, without annotation, the data type is still no worse off than it was >>> before (there is added safety, but not perhaps relevant to the stand point >>> of the library writer). Further, this (pre-existing) non-safety isn't likely >>> a huge concern. Making sure the docs take the tone that most developers need >>> to nothing, and when developers need to be concerned seems like an important >>> way to ensure the right outcome. >>> >>> A key question here is transitivity: Is it possible for module A to not >>> annotate a type, and then have module B by a different author use the type >>> in A in another abstract type, that is annotated, and get the benefit. Seems >>> the answer is "partially". If the answer were "no", then use of the feature >>> would be dependent on transitive adoption, and that is where the big burden >>> on developers comes from. >>> >>> The degree to which we believe this "partially" is important: If we are >>> willing to believe that the only library writers we care about doing this >>> are those in the core, then fine. In this case we shouldn't feel compelled >>> to suggest to library writers that they annotate, ever. I'm good with this. >>> If the team here thinks otherwise, that we need to start a campaign to get >>> every library writer to eventually annotate, then I have deep objections. >>> >>> I read the paper, and understand how the authors felt the syntax options >>> were all less than perfect, and choose what they did. But that choice, >>> perhaps unwittingly, the implication that it forces -XCPP on all libraries >>> except perhaps some of the core. This is because they all need to support >>> previous compilers. So, a one line annotation has turned into an ugly beast, >>> and perhaps added -XCPP where there was none, which is really unfortunate. >>> (I, like many, consider it a defeat when one has to resort to -XCPP.) >>> >>> It seems to me that the paper didn't really consider less-perfect, heuristic >>> solutions. It might have had significantly less impact on library writers >>> were some heuristic (no constructors exported? has any type constraint on >>> the parameter? etc..) might have allowed most data types to go without >>> annotation at the cost of a few (where nominal was incorrectly inferred) >>> requiring immediate action. In this situation, a non-language feature >>> (pragma or other device) might have been more palatable. >>> >>> Finally, on the choice of terms, nominal, representational, and phantom all >>> seem like clear, self-explanatory choices to me. >>> >>> - Mark >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >>> >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://www.haskell.org/mailman/listinfo/libraries >>> > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From mark.lentczner at gmail.com Fri Mar 28 16:17:18 2014 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Fri, 28 Mar 2014 09:17:18 -0700 Subject: We need to add role annotations for 7.8 In-Reply-To: <59543203684B2244980D7E4057D5FBC1488BD709@DB3EX14MBXC308.europe.corp.microsoft.com> References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com> <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com> <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu> <53313E49.1040405@ifi.lmu.de> <8761n2ob4f.fsf@gnu.org> <533165DF.5030206@ifi.lmu.de> <59543203684B2244980D7E4057D5FBC1488BD709@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: *Apologies* On Tue, Mar 25, 2014 at 8:47 AM, Simon Peyton Jones wrote: > The situation today is that > ? A client of a library can use GND to do bad things to the > library (e.g. change the ?key? type of (Map key value)). > ? Role annotations allow the library author to prevent that > happening. > Would you say that means that we are ?compelled to suggest to library > writers that they annotate?? > Well... I don't think we should. The reason is that this situation is very sad for it puts the burden upon the library writer, for potential abuse of an extension to Haskell she might not even be aware of! She writes a perfectly safe, reasonable abstracted type, and bam, now has to worry about a very hard to understand situation involving the interaction to two separate Haskell extensions. And furthermore, adding that protection requires yet a third (CPP), and makes the "protection" often as long as the abstract type itself. Looking further ahead, when you say that ?there can be no migration from > representational-by-default?, do you have data to support that? Notably, > any client not using GND could not observe a change. So simply seeing how > many library modules use GND would be an upper bound on how many libraries > would fail to compile you were to ask us to change the default. Is that 1% > of Hackage modules? 10%? 0.1%? I don?t know. You are wrong that use of GND is the upper bound: The burden is on the type author, not the GND user. And so, while only a small percent of Hackage uses GND (though I note that more and more literature promotes GND (very handy in Shake, for example)...) in order to keep them from breaking, a potentially much larger percentage of Hackage has to get fixed. What's more, the ability to remedy the situation is in the wrong place: If the default changes, and my GND library breaks, all my users are broken, and worse, I can't do anything about it until I compel the libraries I depend on to annotate. This is why we can't ever change the default. On Tue, Mar 25, 2014 at 4:23 PM, Richard Eisenberg wrote: > The problem is, in the actual datatype definition, the constraints tend > not to appear? Should we look around for other functions with constraints? Right - we've been advocating removing them for years, and only placing the constraints on the functions that need them, since they really present no constraint on the data type itself. Of course, the presence of GND and roles means that they now *would be* saying something about the type - as they are indicating that the integrity of the type requires the constraint. So yes, a shift to using this as the marker for nominal would require a change in developer habit. But so does annotation. I agree that other heuristics are pretty fragile: names of modules, presence of constraints in functions, and even status of constructor export are all a) far too removed from the code site in question, and b) things that are much more fluid during development. I would be against any of these. On Wed, Mar 26, 2014 at 8:46 PM, Edward Kmett wrote: > Personally, looking at it 10 years on, having a nominal default would look > pretty terrible to me. > I'd be stuck annotating everything I write. Nothing easy could just be > easy. > Agree whole-heartedly. Worth reiterating: Easy things should not need annotation. On Wed, Mar 26, 2014 at 11:44 PM, Ganesh Sittampalam wrote: > I think that in theory the basic principle should be that by default you > can only write a GND if you could have written it by hand in the same > scope - i.e. you can only do it if you have access to the relevant > methods and datatype constructors etc > This is much closer to the approach I wish had been taken: The burden is on the correct party. The client of the lib, wishing to use it in a new way, unbeknownst to the library author. I don't know enough about the type theory, but could we have disallowed GND in the presence of type families anywhere in the class being derived? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Fri Mar 28 16:52:48 2014 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Fri, 28 Mar 2014 09:52:48 -0700 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com> <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com> <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu> <53313E49.1040405@ifi.lmu.de> <8761n2ob4f.fsf@gnu.org> <533165DF.5030206@ifi.lmu.de> <59543203684B2244980D7E4057D5FBC1488BD709@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: The first line was supposed to say: *Apologies for the delayed and multi-message response.* -------------- next part -------------- An HTML attachment was scrubbed... URL: From schlepptop at henning-thielemann.de Fri Mar 28 16:55:25 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Fri, 28 Mar 2014 17:55:25 +0100 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com> <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com> <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu> <53313E49.1040405@ifi.lmu.de> <8761n2ob4f.fsf@gnu.org> <533165DF.5030206@ifi.lmu.de> <59543203684B2244980D7E4057D5FBC1488BD709@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: <5335A97D.2080602@henning-thielemann.de> Am 28.03.2014 17:17, schrieb Mark Lentczner: > /Apologies/ > On Tue, Mar 25, 2014 at 8:47 AM, Simon Peyton Jones > > wrote: > > The situation today is that > ? A client of a library can use GND to do bad things to the > library (e.g. change the ?key? type of (Map key value)). > ? Role annotations allow the library author to prevent that > happening. > Would you say that means that we are ?compelled to suggest to > library writers that they annotate?? > > > Well... I don't think we should. > > The reason is that this situation is very sad for it puts the burden > upon the library writer, for potential abuse of an extension to Haskell > she might not even be aware of! She writes a perfectly safe, reasonable > abstracted type, and bam, now has to worry about a very hard to > understand situation involving the interaction to two separate Haskell > extensions. And furthermore, adding that protection requires yet a third > (CPP), and makes the "protection" often as long as the abstract type itself. Well put! Before GHC-7.8 release candidates appeared I already thought about removing all GeneralizedNewtypeDerivings from my packages in order to earn the Safe-Haskell seal. Now GHC-7.8 refuses to derive some of the instances that former GHC versions automatically derived. As far as I understand I can use role annotation to let the generation of even more Newtype instances fail, but I cannot persuade GHC to generate more instance using role annoations, right? That is, I have to write these instances manually in any case. That is, up to now, GeneralizedNewtypeDeriving was Unsafe and it seems it becomes Safe with the new role inference. Is this right? However, it is still possible to generate instances that I could not generate manually, as demonstrated in the Data.Map example. Would it solve the problem to respect type roles only if Safe Haskell is enabled and ignore them otherwise? Then all existing code could be compiled unchanged but you can make use of the increased safety of roles by enabling Safe Haskell. From eir at cis.upenn.edu Fri Mar 28 19:56:21 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 28 Mar 2014 15:56:21 -0400 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com> <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com> <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu> <53313E49.1040405@ifi.lmu.de> <8761n2ob4f.fsf@gnu.org> <533165DF.5030206@ifi.lmu.de> <59543203684B2244980D7E4057D5FBC1488BD709@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: <7B4344AC-7EB2-4892-8C07-969456EC6602@cis.upenn.edu> I think a few clarifications might help: - Roles, as originally conceived, were not an attempt to make Unsafe code Safe. Instead, they make unsafe things safe. Before roles, it was quite possible to write Haskell code that would cause a seg fault at runtime. Now, this is (short of unsafeCoerce & friends) impossible, as far as we know. This is independent of any concern with Safe Haskell. That is why certain code that used to work with GND can no longer do so, and why there is no easy fix -- the old code is unsafe, not just Unsafe. - Role annotations are never necessary to ensure type safety. To reiterate: all Haskell code, with or without type annotations, is now safe from the interaction between GND and TypeFamilies. - The whole debate here is about *abstraction* -- whether or not a user outside of a library can fiddle with that library's expected invariants. - Edward and Mark have said that with a default of a nominal role "Nothing easy could just be easy." Yet, we accept the need for deriving Eq and Show without question. I think, if we ignore its current alienness, a role annotation is on a similar order -- a role annotation (in a world with a nominal default) would be granting new capabilities to users of a type, just like adding instances of classes. - If you could use GND only where the constructors are available, then some valid current use of GND would break, I believe. It would mean that GND would be unable to coerce a (Map String Int) to a (Map String Age), because the constructor of Set is (rightly) not exported. This would have a direct runtime significance for some users -- their code would run slower. Richard On Mar 28, 2014, at 12:17 PM, Mark Lentczner wrote: > Apologies > On Tue, Mar 25, 2014 at 8:47 AM, Simon Peyton Jones wrote: > The situation today is that > ? A client of a library can use GND to do bad things to the library (e.g. change the ?key? type of (Map key value)). > ? Role annotations allow the library author to prevent that happening. > Would you say that means that we are ?compelled to suggest to library writers that they annotate?? > > Well... I don't think we should. > > The reason is that this situation is very sad for it puts the burden upon the library writer, for potential abuse of an extension to Haskell she might not even be aware of! She writes a perfectly safe, reasonable abstracted type, and bam, now has to worry about a very hard to understand situation involving the interaction to two separate Haskell extensions. And furthermore, adding that protection requires yet a third (CPP), and makes the "protection" often as long as the abstract type itself. > > Looking further ahead, when you say that ?there can be no migration from representational-by-default?, do you have data to support that? Notably, any client not using GND could not observe a change. So simply seeing how many library modules use GND would be an upper bound on how many libraries would fail to compile you were to ask us to change the default. Is that 1% of Hackage modules? 10%? 0.1%? I don?t know. > > You are wrong that use of GND is the upper bound: The burden is on the type author, not the GND user. And so, while only a small percent of Hackage uses GND (though I note that more and more literature promotes GND (very handy in Shake, for example)...) in order to keep them from breaking, a potentially much larger percentage of Hackage has to get fixed. > > What's more, the ability to remedy the situation is in the wrong place: If the default changes, and my GND library breaks, all my users are broken, and worse, I can't do anything about it until I compel the libraries I depend on to annotate. > > This is why we can't ever change the default. > > > On Tue, Mar 25, 2014 at 4:23 PM, Richard Eisenberg wrote: > The problem is, in the actual datatype definition, the constraints tend not to appear? Should we look around for other functions with constraints? > > Right - we've been advocating removing them for years, and only placing the constraints on the functions that need them, since they really present no constraint on the data type itself. Of course, the presence of GND and roles means that they now would be saying something about the type - as they are indicating that the integrity of the type requires the constraint. So yes, a shift to using this as the marker for nominal would require a change in developer habit. But so does annotation. > > I agree that other heuristics are pretty fragile: names of modules, presence of constraints in functions, and even status of constructor export are all a) far too removed from the code site in question, and b) things that are much more fluid during development. I would be against any of these. > > > On Wed, Mar 26, 2014 at 8:46 PM, Edward Kmett wrote: > Personally, looking at it 10 years on, having a nominal default would look pretty terrible to me. > I'd be stuck annotating everything I write. Nothing easy could just be easy. > > Agree whole-heartedly. > Worth reiterating: Easy things should not need annotation. > > > On Wed, Mar 26, 2014 at 11:44 PM, Ganesh Sittampalam wrote: > I think that in theory the basic principle should be that by default you > can only write a GND if you could have written it by hand in the same > scope - i.e. you can only do it if you have access to the relevant > methods and datatype constructors etc > > This is much closer to the approach I wish had been taken: The burden is on the correct party. The client of the lib, wishing to use it in a new way, unbeknownst to the library author. I don't know enough about the type theory, but could we have disallowed GND in the presence of type families anywhere in the class being derived? > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at zednenem.com Fri Mar 28 20:27:00 2014 From: dave at zednenem.com (David Menendez) Date: Fri, 28 Mar 2014 16:27:00 -0400 Subject: We need to add role annotations for 7.8 In-Reply-To: <7B4344AC-7EB2-4892-8C07-969456EC6602@cis.upenn.edu> References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com> <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com> <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu> <53313E49.1040405@ifi.lmu.de> <8761n2ob4f.fsf@gnu.org> <533165DF.5030206@ifi.lmu.de> <59543203684B2244980D7E4057D5FBC1488BD709@DB3EX14MBXC308.europe.corp.microsoft.com> <7B4344AC-7EB2-4892-8C07-969456EC6602@cis.upenn.edu> Message-ID: On Fri, Mar 28, 2014 at 3:56 PM, Richard Eisenberg wrote: > - Edward and Mark have said that with a default of a nominal role "Nothing > easy could just be easy." Yet, we accept the need for deriving Eq and Show > without question. I think, if we ignore its current alienness, a role > annotation is on a similar order -- a role annotation (in a world with a > nominal default) would be granting new capabilities to users of a type, > just like adding instances of classes. > Well, "deriving (Eq, Show)" is a bit less wordy than "type role Foo representational representational". Although I guess you could just do "type role Foo _ _ _". On the other hand, telling people to add "type role Map nominal _" where it matters is analogous to telling them to have an explicit export list when they want to hide a type's constructors. > - If you could use GND only where the constructors are available, then > some valid current use of GND would break, I believe. It would mean that > GND would be unable to coerce a (Map String Int) to a (Map String Age), > because the constructor of Set is (rightly) not exported. This would have a > direct runtime significance for some users -- their code would run slower. > One might attempt a compromise: - types with explicit annotations always have the specified roles - types with no explicit annotations but visible constructors have the inferred roles - types with no explicit annotations and no visible constructors have nominal roles -- Dave Menendez -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.doel at gmail.com Fri Mar 28 21:10:27 2014 From: dan.doel at gmail.com (Dan Doel) Date: Fri, 28 Mar 2014 17:10:27 -0400 Subject: We need to add role annotations for 7.8 In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com> <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com> <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu> <53313E49.1040405@ifi.lmu.de> <8761n2ob4f.fsf@gnu.org> <533165DF.5030206@ifi.lmu.de> <59543203684B2244980D7E4057D5FBC1488BD709@DB3EX14MBXC308.europe.corp.microsoft.com> <7B4344AC-7EB2-4892-8C07-969456EC6602@cis.upenn.edu> Message-ID: On Fri, Mar 28, 2014 at 4:27 PM, David Menendez wrote: > Well, "deriving (Eq, Show)" is a bit less wordy than "type role Foo > representational representational". Although I guess you could just do > "type role Foo _ _ _". > You forgot some stuff. #ifdef __GLASGOW_HASKELL__ #if __GLASGOW_HASKELL__ >= 708 && __GLASGOW_HASKELL__ < ??? type role Foo representational nominal representational #elif __GLASGOW_HASKELL >= ??? -- insert whatever the future solution is to actually -- handle higher-order types; it will, without question, -- be different from the above role annotation. #endif #endif data Foo f x y = Foo (f x) y deriving (Eq, Ord, Show, Read) Please add that to every type definition in your code. :) -- Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Sun Mar 30 14:45:52 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Sun, 30 Mar 2014 16:45:52 +0200 Subject: Proposal: add createPipe to base In-Reply-To: References: <20140310124746.GA11171@matrix.chaos.earth.li> Message-ID: Since everyone is in favor, I will add createPipe to the process package, as most people seemed to prefer that to base. On Tue, Mar 11, 2014 at 6:08 AM, Stefan Holdermans wrote: > >>> I propose we add it to System.IO. Note that we'd have to copy the 5 > lines > >>> in System.Posix.IO.createPipe into base as the above implementation > would > >>> otherwise depend on the unix package. > >>> > >> +1. I've needed this in the past when working with process, and ended up > >> writing POSIX-only code as a result. > > +1 one from me, with a preference for process over base. > > Cheers, > > Stefan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Sun Mar 30 20:06:26 2014 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sun, 30 Mar 2014 13:06:26 -0700 Subject: Gearing up (again) for the next release: 2014.2.0.0 Message-ID: SO, In anticipation of releasing a HP shortly (1 month?) after GHC 7.8... I'd like to get going on nailing down package versions. I've been working intently on the new Haskell Platform build process (see the new-build branch), and have been building platforms against the release. Here is the description of versions I'm working with: [ incGHC "7.8" , incGHCLib "array" "0.5.0.0" , incGHCLib "base" "4.7.0.0" , incGHCLib "bytestring" "0.10.4.0" , incGHCLib "Cabal" "1.18.1.3" , incGHCLib "containers" "0.5.4.0" , incGHCLib "deepseq" "1.3.0.2" , incGHCLib "directory" "1.2.0.2" , incGHCLib "filepath" "1.3.0.2" , incGHCLib "haskell2010" "1.1.1.1" , incGHCLib "haskell98" "2.0.0.3" , incGHCLib "hpc" "0.6.0.1" , incGHCLib "old-locale" "1.0.0.6" , incGHCLib "old-time" "1.1.0.2" , incGHCLib "pretty" "1.1.1.1" , incGHCLib "process" "1.2.0.0" , incGHCLib "template-haskell" "2.9.0.0" , incGHCLib "time" "1.4.1" , incGHCLib "transformers" "0.3.0.0" , notWindows $ incGHCLib "unix" "2.7.0.1" , onlyWindows $ incGHCLib "Win32" "2.3.0.1" , incLib "async" "2.0.1.5" , incLib "attoparsec" "0.10.4.0" , incLib "case-insensitive" "1.1.0.3" , incLib "cgi" "3001.1.7.5" , incLib "fgl" "5.4.2.4" , incLib "GLUT" "2.5.0.2" , incLib "GLURaw" "1.4.0.0" , incLib "haskell-src" "1.0.1.5" , incLib "hashable" "1.2.1.0" , incLib "html" "1.0.1.2" , incLib "HTTP" "4000.2.10" , incLib "HUnit" "1.2.5.2" , incLib "mtl" "2.1.2" , incLib "network" "2.4.2.2" , incLib "OpenGL" "2.9.1.0" , incLib "OpenGLRaw" "1.4.0.0" , incLib "parallel" "3.2.0.4" , incLib "parsec" "3.1.5" , incLib "primitive" "0.5.2.1" , incLib "QuickCheck" "2.6" , incLib "random" "1.0.1.1" , incLib "regex-base" "0.93.2" , incLib "regex-compat" "0.95.1" , incLib "regex-posix" "0.95.2" , incLib "split" "0.2.2" , incLib "stm" "2.4.2" , incLib "syb" "0.4.1" , incLib "text" "1.1.0.0" , incLib "unordered-containers" "0.2.3.3" , incLib "vector" "0.10.9.1" , incLib "xhtml" "3000.2.1" , incLib "zlib" "0.5.4.1" , incTool "cabal-install" "1.18.0.3" , incTool "alex" "3.1.2" , incTool "happy" "1.19.2" , incTool "hscolour" "1.20.3" , incTool "haddock" "2.14.0" ] However, there are some issues to contend with: *Haddock* - is there any reason not to use the version built and distributed with GHC 7.8? *Shipped w/GHC* - GHC 7.8 ships with several more packages than we include in the platform. I want to review how these are handled: *possibly include in platform* - binary-0.7.1.0 - ghc-prim-0.3.1.0 - hoopl-3.10.0.0 *shouldn't include in platform* - bin-package-db-0.0.0.0 - integer-gmp-0.5.1.0 - rts-1.0 *shipped with GHC, but not registered in pkg-db, yet possible useful to include in platform:* - haskeline-0.7.1.2 - terminfo-0.4.0.0 - xhtml-3000.2.1 -- already in platform, but HP re-builds it... seems silly? *cgi* - no longer builds, and we've been unwilling to bring it forward because it pulls in MonadCatchIO-mtl *hscolour* - never approved as part of platform, but we use it to generate the haddock in both GHC and the Platform - shouldn't we just include it? *New packages:* Last time we had a bunch we wanted... but timing, especially vis-a-vis 7.8 and the new Builder classes, caused us to delay them. Shall we include: aeson dlist (needed by aeson, which version?) scientific (needed by aeson - or get aeson to subsume that code?) *anything else? now's the time to propose!* - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sun Mar 30 20:44:44 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 30 Mar 2014 16:44:44 -0400 Subject: Gearing up (again) for the next release: 2014.2.0.0 In-Reply-To: References: Message-ID: Mark: will we try to have hp use 7.8.2? A whole bunch of bug fixes are planned for that, and likewise the patches for simplifying the cpp configuration as part of the settings files are slated for 7.8.2 On Sunday, March 30, 2014, Mark Lentczner wrote: > SO, In anticipation of releasing a HP shortly (1 month?) after GHC 7.8... > I'd like to get going on nailing down package versions. > > I've been working intently on the new Haskell Platform build process (see > the new-build branch), > and have been building platforms against the release. Here is the > description of versions I'm working with: > > [ incGHC "7.8" > , incGHCLib "array" "0.5.0.0" > , incGHCLib "base" "4.7.0.0" > , incGHCLib "bytestring" "0.10.4.0" > , incGHCLib "Cabal" "1.18.1.3" > , incGHCLib "containers" "0.5.4.0" > , incGHCLib "deepseq" "1.3.0.2" > , incGHCLib "directory" "1.2.0.2" > , incGHCLib "filepath" "1.3.0.2" > , incGHCLib "haskell2010" "1.1.1.1" > , incGHCLib "haskell98" "2.0.0.3" > , incGHCLib "hpc" "0.6.0.1" > , incGHCLib "old-locale" "1.0.0.6" > , incGHCLib "old-time" "1.1.0.2" > , incGHCLib "pretty" "1.1.1.1" > , incGHCLib "process" "1.2.0.0" > , incGHCLib "template-haskell" "2.9.0.0" > , incGHCLib "time" "1.4.1" > , incGHCLib "transformers" "0.3.0.0" > > , notWindows $ incGHCLib "unix" "2.7.0.1" > , onlyWindows $ incGHCLib "Win32" "2.3.0.1" > > , incLib "async" "2.0.1.5" > , incLib "attoparsec" "0.10.4.0" > , incLib "case-insensitive" "1.1.0.3" > , incLib "cgi" "3001.1.7.5" > , incLib "fgl" "5.4.2.4" > , incLib "GLUT" "2.5.0.2" > , incLib "GLURaw" "1.4.0.0" > , incLib "haskell-src" "1.0.1.5" > , incLib "hashable" "1.2.1.0" > , incLib "html" "1.0.1.2" > , incLib "HTTP" "4000.2.10" > , incLib "HUnit" "1.2.5.2" > , incLib "mtl" "2.1.2" > , incLib "network" "2.4.2.2" > , incLib "OpenGL" "2.9.1.0" > , incLib "OpenGLRaw" "1.4.0.0" > , incLib "parallel" "3.2.0.4" > , incLib "parsec" "3.1.5" > , incLib "primitive" "0.5.2.1" > , incLib "QuickCheck" "2.6" > , incLib "random" "1.0.1.1" > , incLib "regex-base" "0.93.2" > , incLib "regex-compat" "0.95.1" > , incLib "regex-posix" "0.95.2" > , incLib "split" "0.2.2" > , incLib "stm" "2.4.2" > , incLib "syb" "0.4.1" > , incLib "text" "1.1.0.0" > , incLib "unordered-containers" "0.2.3.3" > , incLib "vector" "0.10.9.1" > , incLib "xhtml" "3000.2.1" > , incLib "zlib" "0.5.4.1" > > , incTool "cabal-install" "1.18.0.3" > , incTool "alex" "3.1.2" > , incTool "happy" "1.19.2" > > , incTool "hscolour" "1.20.3" > , incTool "haddock" "2.14.0" > ] > > However, there are some issues to contend with: > > *Haddock* - is there any reason not to use the version built and > distributed with GHC 7.8? > > *Shipped w/GHC* - GHC 7.8 ships with several more packages than we > include in the platform. I want to review how these are handled: > > *possibly include in platform* > > - binary-0.7.1.0 > - ghc-prim-0.3.1.0 > - hoopl-3.10.0.0 > > *shouldn't include in platform* > - bin-package-db-0.0.0.0 > - integer-gmp-0.5.1.0 > - rts-1.0 > > *shipped with GHC, but not registered in pkg-db, yet possible useful to > include in platform:* > > - haskeline-0.7.1.2 > - terminfo-0.4.0.0 > - xhtml-3000.2.1 -- already in platform, but HP re-builds it... > seems silly? > > *cgi* - no longer builds, and we've been unwilling to bring it forward > because it pulls in MonadCatchIO-mtl > > *hscolour* - never approved as part of platform, but we use it to > generate the haddock in both GHC and the Platform - shouldn't we just > include it? > > *New packages:* > Last time we had a bunch we wanted... but timing, especially vis-a-vis 7.8 > and the new Builder classes, caused us to delay them. Shall we include: > > aeson > > dlist (needed by aeson, which version?) > > scientific (needed by aeson - or get aeson to subsume that code?) > > *anything else? now's the time to propose!* > > > - Mark > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikita at karetnikov.org Sun Mar 30 22:05:18 2014 From: nikita at karetnikov.org (Nikita Karetnikov) Date: Mon, 31 Mar 2014 02:05:18 +0400 Subject: vector: =?utf-8?B?4oCYQU5OIHR5cGXigJk=?= without GHCi Message-ID: <87ppl31gwx.fsf@karetnikov.org> The latest Hackage version and HEAD fail to build on mips64el due to the ANN pragma in ?Data/Vector/Fusion/Stream/Monadic.hs?: [ 5 of 21] Compiling Data.Vector.Fusion.Stream.Monadic ( Data/Vector/Fusion/Stream/Monadic.hs, dist/build/Data/Vector/Fusion/Stream/Monadic.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for mipsel-unknown-linux): Cant do annotations without GHCi {Data/Vector/Fusion/Stream/Monadic.hs:104:19-33} base:GHC.Exts.ForceSpecConstr{d r2i8} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Here?s the relevant part of the code: data SPEC = SPEC | SPEC2 #if __GLASGOW_HASKELL__ >= 700 {-# ANN type SPEC ForceSpecConstr #-} #endif Is it possible to use CPP along with some configure flag to determine if GHCi is available, and if it is not, skip the said pragma? I tested the Hackage version, and it builds fine if I comment out the mentioned lines. Does the lack of the pragma make a big difference? (The relevant section of the GHC manual is very brief.) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From mark at hibberd.id.au Sun Mar 30 22:10:43 2014 From: mark at hibberd.id.au (Mark Hibberd) Date: Mon, 31 Mar 2014 09:10:43 +1100 Subject: riak-haskell-client maintainers Message-ID: All, Hi. I rely heavily on the riak-haskell-client library (http://hackage.haskell.org/package/riak), and at the moment it is unmaintained for all intents and purposes. Evidenced by: - I have patches outstanding (as do others), that have not been responded to for 8 months (https://github.com/janrain/riak-haskell-client/pull/19). - It doesn't support most of the riak APIs due to only being built against a very old version of the API (#19 addresses this partially). - And there was a comment last week indicating that janrain were no longer supporting it (https://github.com/janrain/riak-haskell-client/pull/10). Carter suggested I send a message to this list to see if there is anyone who is able to help, either as a maintainer, or by allowing me to be added as a maintainer so I can start getting things updated. I have requested the same via the maintainers email and a github issue (https://github.com/janrain/riak-haskell-client/issues/25) about a week ago, but have not received any response yet. Cheers Mark From fuuzetsu at fuuzetsu.co.uk Sun Mar 30 22:12:02 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Sun, 30 Mar 2014 23:12:02 +0100 Subject: Gearing up (again) for the next release: 2014.2.0.0 In-Reply-To: References: Message-ID: <533896B2.80701@fuuzetsu.co.uk> On 30/03/14 21:44, Carter Schonwald wrote: > Mark: will we try to have hp use 7.8.2? A whole bunch of bug fixes are > planned for that, > and likewise the patches for simplifying the cpp configuration as part of > the settings files are slated for 7.8.2 > I'd also like to recommend that 7.8.2 is used for similar reasons. > On Sunday, March 30, 2014, Mark Lentczner wrote: > >> SO, In anticipation of releasing a HP shortly (1 month?) after GHC 7.8... >> I'd like to get going on nailing down package versions. >> >> I've been working intently on the new Haskell Platform build process (see >> the new-build branch), >> and have been building platforms against the release. Here is the >> description of versions I'm working with: >> >> [ incGHC "7.8" >> , incGHCLib "array" "0.5.0.0" >> , incGHCLib "base" "4.7.0.0" >> , incGHCLib "bytestring" "0.10.4.0" >> , incGHCLib "Cabal" "1.18.1.3" >> , incGHCLib "containers" "0.5.4.0" >> , incGHCLib "deepseq" "1.3.0.2" >> , incGHCLib "directory" "1.2.0.2" >> , incGHCLib "filepath" "1.3.0.2" >> , incGHCLib "haskell2010" "1.1.1.1" >> , incGHCLib "haskell98" "2.0.0.3" >> , incGHCLib "hpc" "0.6.0.1" >> , incGHCLib "old-locale" "1.0.0.6" >> , incGHCLib "old-time" "1.1.0.2" >> , incGHCLib "pretty" "1.1.1.1" >> , incGHCLib "process" "1.2.0.0" >> , incGHCLib "template-haskell" "2.9.0.0" >> , incGHCLib "time" "1.4.1" >> , incGHCLib "transformers" "0.3.0.0" >> >> , notWindows $ incGHCLib "unix" "2.7.0.1" >> , onlyWindows $ incGHCLib "Win32" "2.3.0.1" >> >> , incLib "async" "2.0.1.5" >> , incLib "attoparsec" "0.10.4.0" >> , incLib "case-insensitive" "1.1.0.3" >> , incLib "cgi" "3001.1.7.5" >> , incLib "fgl" "5.4.2.4" >> , incLib "GLUT" "2.5.0.2" >> , incLib "GLURaw" "1.4.0.0" >> , incLib "haskell-src" "1.0.1.5" >> , incLib "hashable" "1.2.1.0" >> , incLib "html" "1.0.1.2" >> , incLib "HTTP" "4000.2.10" >> , incLib "HUnit" "1.2.5.2" >> , incLib "mtl" "2.1.2" >> , incLib "network" "2.4.2.2" >> , incLib "OpenGL" "2.9.1.0" >> , incLib "OpenGLRaw" "1.4.0.0" >> , incLib "parallel" "3.2.0.4" >> , incLib "parsec" "3.1.5" >> , incLib "primitive" "0.5.2.1" >> , incLib "QuickCheck" "2.6" >> , incLib "random" "1.0.1.1" >> , incLib "regex-base" "0.93.2" >> , incLib "regex-compat" "0.95.1" >> , incLib "regex-posix" "0.95.2" >> , incLib "split" "0.2.2" >> , incLib "stm" "2.4.2" >> , incLib "syb" "0.4.1" >> , incLib "text" "1.1.0.0" >> , incLib "unordered-containers" "0.2.3.3" >> , incLib "vector" "0.10.9.1" >> , incLib "xhtml" "3000.2.1" >> , incLib "zlib" "0.5.4.1" >> >> , incTool "cabal-install" "1.18.0.3" >> , incTool "alex" "3.1.2" >> , incTool "happy" "1.19.2" >> >> , incTool "hscolour" "1.20.3" >> , incTool "haddock" "2.14.0" Haddock 2.14.0 was effectively an internal release. If the platform were to be released today, you should be using 2.14.1. It contains some extra bugfixes. Following up on my request for waiting until 7.8.2, this will again go up after further bugfixes follow (at the moment doc building is broken for certain packages due to some Clang problems). >> ] >> >> However, there are some issues to contend with: >> >> *Haddock* - is there any reason not to use the version built and >> distributed with GHC 7.8? There is no reason to do so as long as you pick the release with the various bugfixes in place. >> *Shipped w/GHC* - GHC 7.8 ships with several more packages than we >> include in the platform. I want to review how these are handled: >> >> *possibly include in platform* >> >> - binary-0.7.1.0 >> - ghc-prim-0.3.1.0 >> - hoopl-3.10.0.0 >> >> *shouldn't include in platform* >> - bin-package-db-0.0.0.0 >> - integer-gmp-0.5.1.0 >> - rts-1.0 >> >> *shipped with GHC, but not registered in pkg-db, yet possible useful to >> include in platform:* >> >> - haskeline-0.7.1.2 >> - terminfo-0.4.0.0 >> - xhtml-3000.2.1 -- already in platform, but HP re-builds it... >> seems silly? >> >> *cgi* - no longer builds, and we've been unwilling to bring it forward >> because it pulls in MonadCatchIO-mtl >> >> *hscolour* - never approved as part of platform, but we use it to >> generate the haddock in both GHC and the Platform - shouldn't we just >> include it? >> >> *New packages:* >> Last time we had a bunch we wanted... but timing, especially vis-a-vis 7.8 >> and the new Builder classes, caused us to delay them. Shall we include: >> >> aeson >> >> dlist (needed by aeson, which version?) >> >> scientific (needed by aeson - or get aeson to subsume that code?) >> >> *anything else? now's the time to propose!* >> >> >> - Mark >> >> +1 for aeson merely because there are so many packages nowadays that depend on it, it seems like it would be a worthwhile addition but I don't have strong feelings otherwise. -- Mateusz K. From carter.schonwald at gmail.com Sun Mar 30 22:40:50 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 30 Mar 2014 18:40:50 -0400 Subject: riak-haskell-client maintainers In-Reply-To: References: Message-ID: I'll be on irc this evening. Now that the current maintainer has been unresponsive plus you have asked on the list (hence public record), I'm happy to help get a fix release on hackage etc (though I should probably try to contact the maintainer myself too) On Sunday, March 30, 2014, Mark Hibberd wrote: > All, Hi. > > I rely heavily on the riak-haskell-client library > (http://hackage.haskell.org/package/riak), and at the moment it is > unmaintained for all intents and purposes. Evidenced by: > - I have patches outstanding (as do others), that have not been > responded to for 8 months > (https://github.com/janrain/riak-haskell-client/pull/19). > - It doesn't support most of the riak APIs due to only being built > against a very old version of the API (#19 addresses this partially). > - And there was a comment last week indicating that janrain were no > longer supporting it > (https://github.com/janrain/riak-haskell-client/pull/10). > > Carter suggested I send a message to this list to see if there is > anyone who is able to help, either as a maintainer, or by allowing me > to be added as a maintainer so I can start getting things updated. > > I have requested the same via the maintainers email and a github issue > (https://github.com/janrain/riak-haskell-client/issues/25) about a > week ago, but have not received any response yet. > > Cheers > Mark > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Sun Mar 30 22:43:30 2014 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sun, 30 Mar 2014 15:43:30 -0700 Subject: Gearing up (again) for the next release: 2014.2.0.0 In-Reply-To: References: Message-ID: *happy *bumped to* 1.19.3* *alex *bumped to* 3.1.3* *haddock *bumped to* 2.14.1* *- but question about tying to GHC release still open: The concern is since GHC ships with it's doc built with the haddock executable it ships, will we have problems building the rest of the docs with a later haddock -- and having all the cross references work?* As for GHC 7.8.2 - Where is the plan for 7.8.2 documented? It is barely mentioned in the GHC mailing list, and no mention in the GHC trac wiki, and the issues milestone has scant info. I'm very reluctant to hold out for an unknown GHC release. Unless we have good reason to think that GHC 7.8.1 is a bad release and will leave scads of people with broken build systems.... I'd like to continue to plan on releasing HP in mid May (so on schedule for 2014.2.0.0). As such, unless the turn of 7.8.2 comes within a week or two of 7.8.1 - let's stick with 7.8.1. Finally - note that part of my big push to totally re-write the Haskell Platform is so that we can all feel more confident turning a version more quickly if we need. If 7.8.2 comes out this Summer, and we think it is an important enough improvement - we can turn HP too. - Mark ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuuzetsu at fuuzetsu.co.uk Sun Mar 30 23:02:30 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Mon, 31 Mar 2014 00:02:30 +0100 Subject: Gearing up (again) for the next release: 2014.2.0.0 In-Reply-To: References: Message-ID: <5338A286.8020606@fuuzetsu.co.uk> On 30/03/14 23:43, Mark Lentczner wrote: > *happy *bumped to* 1.19.3* > *alex *bumped to* 3.1.3* > *haddock *bumped to* 2.14.1* > > *- but question about tying to GHC release still open: The concern is since > GHC ships with it's doc built with the haddock executable it ships, will we > have problems building the rest of the docs with a later haddock -- and > having all the cross references work?* It will work provided that the Haddock used has not had the interface file version changed. While we don't plan on doing this, I don't see why this is a concern: you're planning to use Haddock that ships with the GHC version you're going to use, right? All the documentation that will come with it will be generated with the same version. > As for GHC 7.8.2 - Where is the plan for 7.8.2 documented? It is barely > mentioned in the GHC mailing list, and no mention in the GHC trac wiki, and > the issues milestone has scant info. I don't think there's an official plan but the window for 7.8.1 features is pretty much closed but there are still fixes &c that people want in. I think it has been pretty much agreed to (at least in #ghc on Freenode) that 7.8.2 is happening although I can't speak for the GHC team here. > I'm very reluctant to hold out for an unknown GHC release. Unless we have > good reason to think that GHC 7.8.1 is a bad release and will leave scads > of people with broken build systems.... I'd like to continue to plan on > releasing HP in mid May (so on schedule for 2014.2.0.0). As such, unless > the turn of 7.8.2 comes within a week or two of 7.8.1 - let's stick with > 7.8.1. Well, 7.8.1 is not actually out yet but from what I gather, 7.8.2 is to follow very soon afterwards. Again, this is just hearsay. As I mentioned, we have a pretty bad bug to do with Clang where everyone on OSX won't be able to build docs for certain libraries. I believe Austin found a workaround but I don't know if he's planning to monkey-patch that into 7.8.1 or not (and if he is, we'll have to bump the Haddock version anyway). I am sure there are other problems holding up the release at this point. Perhaps it would be worthwhile asking on ghc-devs? > Finally - note that part of my big push to totally re-write the Haskell > Platform is so that we can all feel more confident turning a version more > quickly if we need. If 7.8.2 comes out this Summer, and we think it is an > important enough improvement - we can turn HP too. > > - Mark > > > ? > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -- Mateusz K. From ekmett at gmail.com Sun Mar 30 23:22:06 2014 From: ekmett at gmail.com (Edward Kmett) Date: Sun, 30 Mar 2014 19:22:06 -0400 Subject: =?UTF-8?B?UmU6IHZlY3Rvcjog4oCYQU5OIHR5cGXigJkgd2l0aG91dCBHSENp?= In-Reply-To: <87ppl31gwx.fsf@karetnikov.org> References: <87ppl31gwx.fsf@karetnikov.org> Message-ID: Unfortunately, that pragma pretty much makes the difference between vector being fast, getting benefits out of stream fusion for all those intermediate stream types and not. It might be a much nicer story if stage-1 builds simply ignored ANN pragmas entirely. As it is I get complaints from distribution maintainers with wide distributions about any use of module or function annotations for HLint, and this particular ForceSpecConstr annotation has come up as a source of pain for Austin before, though I've forgotten the details as to why. -Edward On Sun, Mar 30, 2014 at 6:05 PM, Nikita Karetnikov wrote: > The latest Hackage version and HEAD fail to build on mips64el due to the > ANN pragma in ?Data/Vector/Fusion/Stream/Monadic.hs?: > > [ 5 of 21] Compiling Data.Vector.Fusion.Stream.Monadic ( > Data/Vector/Fusion/Stream/Monadic.hs, > dist/build/Data/Vector/Fusion/Stream/Monadic.o ) > ghc: panic! (the 'impossible' happened) > (GHC version 7.6.3 for mipsel-unknown-linux): > Cant do annotations without GHCi > {Data/Vector/Fusion/Stream/Monadic.hs:104:19-33} > base:GHC.Exts.ForceSpecConstr{d r2i8} > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > Here?s the relevant part of the code: > > data SPEC = SPEC | SPEC2 > #if __GLASGOW_HASKELL__ >= 700 > {-# ANN type SPEC ForceSpecConstr #-} > #endif > > Is it possible to use CPP along with some configure flag to determine if > GHCi is available, and if it is not, skip the said pragma? I tested the > Hackage version, and it builds fine if I comment out the mentioned > lines. > > Does the lack of the pragma make a big difference? (The relevant > section of the GHC manual is very brief.) > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Mon Mar 31 00:14:55 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Sun, 30 Mar 2014 20:14:55 -0400 Subject: Backward-compatible role annotations In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com> <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com> <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu> <53313E49.1040405@ifi.lmu.de> <8761n2ob4f.fsf@gnu.org> <533165DF.5030206@ifi.lmu.de> <59543203684B2244980D7E4057D5FBC! 1488BD709@DB3EX14MBXC308.europe.corp.microsoft.com> <7B4344AC-7EB2-4892-8C07-969456EC6602@cis.upenn.edu> Message-ID: <1916CF2B-9B03-4CBD-8559-0AD4C4834E85@cis.upenn.edu> I spent some time thinking about what, precisely, can be done here to make folks happier. (See the thread beginning here: http://www.haskell.org/pipermail/libraries/2014-March/022321.html) And, the answer seemed to all be in the concrete syntax. The only logical alternative (that I could think of) to having roles is to disallow GND, and I don't think anyone is proposing that. And, it is impossible to infer an author's desired roles for a datatype. The heuristics mentioned here all seem far too fragile and hard to predict to become a lasting feature of GHC (in my opinion). What's left? Concrete syntax. So, I have written and uploaded no-role-annots-1.0, a backward-compatible alternative to role annotations -- no CPP required. It's not as principled as proper role annotations, but it should do the job for most users. Here are two examples: 1. Datatypes: > import Language.Haskell.RoleAnnots > > data Map k v = > (Nominal k, Representational v) => MkMap [(k,v)] The constraints (which need be put on only one data constructor, if there are many) will get the built-in role inference mechanism to do what the user requests. In this example, the `Representational v` is actually redundant, but causes no harm. Because these classes have universal instances ("instance Nominal a") and have no methods, they should have no run-time significance. The only downside I can see is that the code above needs -XGADTs or -XExistentialQuantification to work, though it is neither a GADT nor has existentials. (Pattern-matching on such a definition needs no extensions.) 2. Newtypes: Newtype constructors cannot be constrained, unfortunately. So, we have to resort to Template Haskell: > import Language.Haskell.RoleAnnots > > roleAnnot [NominalR, RepresentationalR] > [d| newtype Map k v = MkMap [(k, v)] |] This is clearly worse, but I was able to come up with no other solution that worked for newtypes. Note that, in the example, I used the fact that Template Haskell interprets a bare top-level expression as a Template Haskell splice. We could also wrap that line in $( ... ) to be more explicit about the use of TH. Also problematic here is that the code above requires -XRoleAnnotations in GHC 7.8. To get this extension enabled without using CPP, put it in a condition chunk in your .cabal file, like this: > if impl(ghc >= 7.8) > default-extensions: RoleAnnotations I hope this is helpful to everyone. Please feel free to post issues/pull requests to my github repo at github.com/goldfirere/no-role-annots. Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominique.devriese at cs.kuleuven.be Mon Mar 31 06:51:18 2014 From: dominique.devriese at cs.kuleuven.be (Dominique Devriese) Date: Mon, 31 Mar 2014 08:51:18 +0200 Subject: Backward-compatible role annotations In-Reply-To: <1916CF2B-9B03-4CBD-8559-0AD4C4834E85@cis.upenn.edu> References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com> <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com> <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu> <53313E49.1040405@ifi.lmu.de> <8761n2ob4f.fsf@gnu.org> <533165DF.5030206@ifi.lmu.de> <7B4344AC-7EB2-4892-8C07-969456EC6602@cis.upenn.edu> <1916CF2B-9B03-4CBD-8559-0AD4C4834E85@cis.upenn.edu> Message-ID: Richard, (re-posting because I first used an address that is not subscribed to the lists) I've been wondering about the following: it seems like the main problem in this situation is that the GeneralizedNewtypeDeriving extension changed meaning from "just coerce everything while deriving" to "only coerce stuff if it's allowed by the relevant role annotations". Would it not be an alternative solution to split up the GND extension into * a backwards-compatible one (called GeneralizedNewtypeDeriving for backwards compatibility ;)) that ignores role annotations (as before) and uses unsafeCoerce whereever necessary * a safe one (called e.g. SafeNewtypeDeriving) that respects role annotations The first one could then be deprecated and removed in a release or two. That might give library maintainers time to move their packages to SafeNewtypeDeriving when they have tested that everything works... Regards, Dominique P.S.: The above is based on a limited understanding of the problem, so I'm sorry if it misses some aspect of the problem... 2014-03-31 2:14 GMT+02:00 Richard Eisenberg : > I spent some time thinking about what, precisely, can be done here to make > folks happier. (See the thread beginning here: > http://www.haskell.org/pipermail/libraries/2014-March/022321.html) And, the > answer seemed to all be in the concrete syntax. The only logical alternative > (that I could think of) to having roles is to disallow GND, and I don't > think anyone is proposing that. And, it is impossible to infer an author's > desired roles for a datatype. The heuristics mentioned here all seem far too > fragile and hard to predict to become a lasting feature of GHC (in my > opinion). What's left? Concrete syntax. > > So, I have written and uploaded no-role-annots-1.0, a backward-compatible > alternative to role annotations -- no CPP required. It's not as principled > as proper role annotations, but it should do the job for most users. > > Here are two examples: > > 1. Datatypes: > >> import Language.Haskell.RoleAnnots >> >> data Map k v = >> (Nominal k, Representational v) => MkMap [(k,v)] > > The constraints (which need be put on only one data constructor, if there > are many) will get the built-in role inference mechanism to do what the user > requests. In this example, the `Representational v` is actually redundant, > but causes no harm. Because these classes have universal instances > ("instance Nominal a") and have no methods, they should have no run-time > significance. The only downside I can see is that the code above needs > -XGADTs or -XExistentialQuantification to work, though it is neither a GADT > nor has existentials. (Pattern-matching on such a definition needs no > extensions.) > > 2. Newtypes: > > Newtype constructors cannot be constrained, unfortunately. So, we have to > resort to Template Haskell: > >> import Language.Haskell.RoleAnnots >> >> roleAnnot [NominalR, RepresentationalR] >> [d| newtype Map k v = MkMap [(k, v)] |] > > This is clearly worse, but I was able to come up with no other solution that > worked for newtypes. Note that, in the example, I used the fact that > Template Haskell interprets a bare top-level expression as a Template > Haskell splice. We could also wrap that line in $( ... ) to be more explicit > about the use of TH. Also problematic here is that the code above requires > -XRoleAnnotations in GHC 7.8. To get this extension enabled without using > CPP, put it in a condition chunk in your .cabal file, like this: > >> if impl(ghc >= 7.8) >> default-extensions: RoleAnnotations > > I hope this is helpful to everyone. Please feel free to post issues/pull > requests to my github repo at github.com/goldfirere/no-role-annots. > > Thanks, > Richard > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From schlepptop at henning-thielemann.de Mon Mar 31 07:43:11 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Mon, 31 Mar 2014 09:43:11 +0200 Subject: Backward-compatible role annotations In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com> <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com> <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu> <53313E49.1040405@ifi.lmu.de> <8761n2ob4f.fsf@gnu.org> <533165DF.5030206@ifi.lmu.de> <7B4344AC-7EB2-4892-8C07-969456EC6602@cis.upenn.edu> <1916CF2B-9B03-4CBD-8559-0AD4C4834E85@cis.upenn.edu> Message-ID: <53391C8F.4040900@henning-thielemann.de> Am 31.03.2014 08:51, schrieb Dominique Devriese: > Richard, > > (re-posting because I first used an address that is not subscribed to the lists) > > I've been wondering about the following: it seems like the main > problem in this situation is that the GeneralizedNewtypeDeriving > extension changed meaning from "just coerce everything while deriving" > to "only coerce stuff if it's allowed by the relevant role > annotations". Would it not be an alternative solution to split up the > GND extension into > > * a backwards-compatible one (called GeneralizedNewtypeDeriving for > backwards compatibility ;)) that ignores role annotations (as before) > and uses unsafeCoerce whereever necessary > * a safe one (called e.g. SafeNewtypeDeriving) that respects role annotations That's very similar to what I proposed with respect to SafeHaskell, i.e. GeneralizedNewtypeDeriving in an Unsafe module means backwards-compatible old GeneralizedNewtypeDeriving and GeneralizedNewtypeDeriving in a Safe module means SafeNewtypeDeriving. > P.S.: The above is based on a limited understanding of the problem, so > I'm sorry if it misses some aspect of the problem... I think their main concern is not on the side of the user who wants to use GeneralizedNewtypeDeriving, but on the side of the library writer who has to take GeneralizedNewtypeDeriving into account, although it is an extension and his code would be perfectly safe without GeneralizedNewtypeDeriving. The first one is a problem only in the transition from GHC-7.6 to GHC-7.8, but the latter one is a permanent problem. But then again, the backward-compatible role annotations proposal seems to address yet another problem. From simonpj at microsoft.com Mon Mar 31 07:55:27 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 31 Mar 2014 07:55:27 +0000 Subject: Gearing up (again) for the next release: 2014.2.0.0 In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF0C9F08@DB3PRD3001MB020.064d.mgd.msft.net> As for GHC 7.8.2 - Where is the plan for 7.8.2 documented? It is barely mentioned in the GHC mailing list, and no mention in the GHC trac wiki, and the issues milestone has scant info. We have not begun to think about when to release 7.8.2. It?ll depend on what issues show up in 7.8.1 and how urgent they seem to be. We have delayed 7.8.1 for ages, and given masses of warning about the release, so I?d be sad if there are known, show-stopping bugs in it that we already know about. If there really really really are, maybe we should delay 7.8.1 further. But that process can go on indefinitely (as we have already seen), so I?m pretty reluctant. But I?d certainly listen to a consensus view from the HP team. You represent our customers. Simon From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Mark Lentczner Sent: 30 March 2014 23:44 To: haskell-platform at projects.haskell.org; Haskell Libraries Subject: Re: Gearing up (again) for the next release: 2014.2.0.0 happy bumped to 1.19.3 alex bumped to 3.1.3 haddock bumped to 2.14.1 - but question about tying to GHC release still open: The concern is since GHC ships with it's doc built with the haddock executable it ships, will we have problems building the rest of the docs with a later haddock -- and having all the cross references work? As for GHC 7.8.2 - Where is the plan for 7.8.2 documented? It is barely mentioned in the GHC mailing list, and no mention in the GHC trac wiki, and the issues milestone has scant info. I'm very reluctant to hold out for an unknown GHC release. Unless we have good reason to think that GHC 7.8.1 is a bad release and will leave scads of people with broken build systems.... I'd like to continue to plan on releasing HP in mid May (so on schedule for 2014.2.0.0). As such, unless the turn of 7.8.2 comes within a week or two of 7.8.1 - let's stick with 7.8.1. Finally - note that part of my big push to totally re-write the Haskell Platform is so that we can all feel more confident turning a version more quickly if we need. If 7.8.2 comes out this Summer, and we think it is an important enough improvement - we can turn HP too. - Mark ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From voldermort at hotmail.com Mon Mar 31 08:20:30 2014 From: voldermort at hotmail.com (harry) Date: Mon, 31 Mar 2014 01:20:30 -0700 (PDT) Subject: Gearing up (again) for the next release: 2014.2.0.0 In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0C9F08@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF0C9F08@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <1396254030124-5746686.post@n5.nabble.com> Simon Peyton Jones wrote > We have not begun to think about when to release 7.8.2. It?ll depend on > what issues show up in 7.8.1 and how urgent they seem to be. We have > delayed 7.8.1 for ages, and given masses of warning about the release, so > I?d be sad if there are known, show-stopping bugs in it that we already > know about. If there really really really are, maybe we should delay > 7.8.1 further. But that process can go on indefinitely (as we have > already seen), so I?m pretty reluctant. > > But I?d certainly listen to a consensus view from the HP team. You > represent our customers. If I've understood #8736 correctly, GHCi on Windows can't load modules that were compiled with --dynamic-too. That's a pretty nasty regression, as --dynamic-too will now be the default for anything used by TH. -- View this message in context: http://haskell.1045720.n5.nabble.com/Gearing-up-again-for-the-next-release-2014-2-0-0-tp5746660p5746686.html Sent from the Haskell - Libraries mailing list archive at Nabble.com. From chris at chrisdornan.com Mon Mar 31 09:44:25 2014 From: chris at chrisdornan.com (Chris Dornan) Date: Mon, 31 Mar 2014 09:44:25 +0000 Subject: Gearing up (again) for the next release: 2014.2.0.0 In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0C9F08@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF0C9F08@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: I would have expected 7.8.1 will need some work before it is ready for the platform and holding up 7.8.1 further seems like a bad idea, so isn?t 7.8.2 the first real 7.8 candidate for the platform? Is there any reason why we cannot base 2014.2.0.0 on 7.6.3 again? Chris From: Simon Peyton-Jones Date: Monday, 31 March 2014 07:55 To: Mark Lentczner , "haskell-platform at projects.haskell.org" , Haskell Libraries Subject: RE: Gearing up (again) for the next release: 2014.2.0.0 As for GHC 7.8.2 - Where is the plan for 7.8.2 documented? It is barely mentioned in the GHC mailing list, and no mention in the GHC trac wiki, and the issues milestone has scant info. We have not begun to think about when to release 7.8.2. It?ll depend on what issues show up in 7.8.1 and how urgent they seem to be. We have delayed 7.8.1 for ages, and given masses of warning about the release, so I?d be sad if there are known, show-stopping bugs in it that we already know about. If there really really really are, maybe we should delay 7.8.1 further. But that process can go on indefinitely (as we have already seen), so I?m pretty reluctant. But I?d certainly listen to a consensus view from the HP team. You represent our customers. Simon From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Mark Lentczner Sent: 30 March 2014 23:44 To: haskell-platform at projects.haskell.org; Haskell Libraries Subject: Re: Gearing up (again) for the next release: 2014.2.0.0 happy bumped to 1.19.3 alex bumped to 3.1.3 haddock bumped to 2.14.1 > > - but question about tying to GHC release still open: The concern is since GHC > ships with it's doc built with the haddock executable it ships, will we have > problems building the rest of the docs with a later haddock -- and having all > the cross references work? As for GHC 7.8.2 - Where is the plan for 7.8.2 documented? It is barely mentioned in the GHC mailing list, and no mention in the GHC trac wiki, and the issues milestone has scant info. I'm very reluctant to hold out for an unknown GHC release. Unless we have good reason to think that GHC 7.8.1 is a bad release and will leave scads of people with broken build systems.... I'd like to continue to plan on releasing HP in mid May (so on schedule for 2014.2.0.0). As such, unless the turn of 7.8.2 comes within a week or two of 7.8.1 - let's stick with 7.8.1. Finally - note that part of my big push to totally re-write the Haskell Platform is so that we can all feel more confident turning a version more quickly if we need. If 7.8.2 comes out this Summer, and we think it is an important enough improvement - we can turn HP too. - Mark ? _______________________________________________ Libraries mailing list Libraries at haskell.org http://www.haskell.org/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Mar 31 08:44:03 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 31 Mar 2014 08:44:03 +0000 Subject: Gearing up (again) for the next release: 2014.2.0.0 In-Reply-To: <1396254030124-5746686.post@n5.nabble.com> References: <618BE556AADD624C9C918AA5D5911BEF0C9F08@DB3PRD3001MB020.064d.mgd.msft.net> <1396254030124-5746686.post@n5.nabble.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF0CA5CF@DB3PRD3001MB020.064d.mgd.msft.net> | If I've understood #8736 correctly, GHCi on Windows can't load modules | that | were compiled with --dynamic-too. That's a pretty nasty regression, as | --dynamic-too will now be the default for anything used by TH. Well, five weeks ago we marked the ticket as "not a release blocker". No one commented. And it's not a regression, is it? I don't think -dynamic-too existed in 7.6. We'd welcome help with this. There is some reason it's not straightforward to fix, but I've forgotten what it is. Simon | -----Original Message----- | From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of harry | Sent: 31 March 2014 09:21 | To: libraries at haskell.org | Subject: RE: Gearing up (again) for the next release: 2014.2.0.0 | | Simon Peyton Jones wrote | > We have not begun to think about when to release 7.8.2. It?ll depend | on | > what issues show up in 7.8.1 and how urgent they seem to be. We have | > delayed 7.8.1 for ages, and given masses of warning about the release, | so | > I?d be sad if there are known, show-stopping bugs in it that we already | > know about. If there really really really are, maybe we should delay | > 7.8.1 further. But that process can go on indefinitely (as we have | > already seen), so I?m pretty reluctant. | > | > But I?d certainly listen to a consensus view from the HP team. You | > represent our customers. | | If I've understood #8736 correctly, GHCi on Windows can't load modules | that | were compiled with --dynamic-too. That's a pretty nasty regression, as | --dynamic-too will now be the default for anything used by TH. | | | | -- | View this message in context: | http://haskell.1045720.n5.nabble.com/Gearing-up-again-for-the-next- | release-2014-2-0-0-tp5746660p5746686.html | Sent from the Haskell - Libraries mailing list archive at Nabble.com. | _______________________________________________ | Libraries mailing list | Libraries at haskell.org | http://www.haskell.org/mailman/listinfo/libraries From greg at gregorycollins.net Mon Mar 31 09:03:29 2014 From: greg at gregorycollins.net (Gregory Collins) Date: Mon, 31 Mar 2014 11:03:29 +0200 Subject: Gearing up (again) for the next release: 2014.2.0.0 In-Reply-To: References: Message-ID: On Sun, Mar 30, 2014 at 10:06 PM, Mark Lentczner wrote: > *cgi* - no longer builds, and we've been unwilling to bring it forward > because it pulls in MonadCatchIO-mtl Should we remove it from the platform? G -- Gregory Collins -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.leather at gmail.com Mon Mar 31 09:20:52 2014 From: sean.leather at gmail.com (Sean Leather) Date: Mon, 31 Mar 2014 11:20:52 +0200 Subject: Gearing up (again) for the next release: 2014.2.0.0 In-Reply-To: References: Message-ID: On Sun, Mar 30, 2014 at 10:06 PM, Mark Lentczner wrote: > *New packages:* > > dlist (needed by aeson, which version?) > > 0.7.0.1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From voldermort at hotmail.com Mon Mar 31 09:40:39 2014 From: voldermort at hotmail.com (harry) Date: Mon, 31 Mar 2014 02:40:39 -0700 (PDT) Subject: Gearing up (again) for the next release: 2014.2.0.0 In-Reply-To: References: Message-ID: <1396258839666-5746699.post@n5.nabble.com> Should html be replaced with blaze-html? That's what people actually seem to be using these days. -- View this message in context: http://haskell.1045720.n5.nabble.com/Gearing-up-again-for-the-next-release-2014-2-0-0-tp5746660p5746699.html Sent from the Haskell - Libraries mailing list archive at Nabble.com. From svenpanne at gmail.com Mon Mar 31 09:50:43 2014 From: svenpanne at gmail.com (Sven Panne) Date: Mon, 31 Mar 2014 11:50:43 +0200 Subject: Gearing up (again) for the next release: 2014.2.0.0 In-Reply-To: References: Message-ID: 2014-03-30 22:06 GMT+02:00 Mark Lentczner : > [...] > , incLib "GLUT" "2.5.0.2" > [...] Using 2.5.1.0 (released about 2 months ago) would be nice, but not really crucial. From mark.lentczner at gmail.com Mon Mar 31 14:56:33 2014 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Mon, 31 Mar 2014 07:56:33 -0700 Subject: Gearing up (again) for the next release: 2014.2.0.0 In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0C9F08@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF0C9F08@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Thanks Simon for confirming the status. Short: I see no reason not to proceed with 7.8.1 in the next HP. Long: On Mon, Mar 31, 2014 at 2:44 AM, Chris Dornan wrote: > I would have expected 7.8.1 will need some work before it is ready for the > platform and holding up 7.8.1 further seems like a bad idea, so isn?t 7.8.2 > the first real 7.8 candidate for the platform? This has been a common sentiment here. But I believe that 7.8.1, and GHC in general, is being released with due diligence toward stability on all three major OS platforms. I don't expect to see this release, or any GHC release going forward that immediately needs to be retracted, or breaks for many users, or should be avoided. Of course GHC will ship with bugs - all large software does. We cannot ever wait for a bug-free release. Or even "relatively bug-free" or "no show stoppers" release, because with this many developers, maintainers, committers, and just sheer volume of code, we will never all agree here on the platform team what constitutes those states. If we start delaying for some unknown future release... we'll be waiting for 7.8.3 and 7.8.4, etc... We must trust that the GHC team will triage bugs and release when ready. With software this big, we all have a responsibility to stable and dependable releases. - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Mon Mar 31 15:00:39 2014 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Mon, 31 Mar 2014 08:00:39 -0700 Subject: Gearing up (again) for the next release: 2014.2.0.0 In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF0C9F08@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: On Mon, Mar 31, 2014 at 2:44 AM, Chris Dornan wrote: > > Is there any reason why we cannot base 2014.2.0.0 on 7.6.3 again? > Yes. Significant reorganizations of functionality not yet in the platform took place between 7.6.3 and 7.8.1 time frames. When we add that functionality (aeson, for example), it pulls a bunch of that functionality into the platform (builder, for example). If we release HP on 7.6.3, then either we don't include the new functionality at all (the decision back last Fall when we considered this), or we release on 7.6.3, with the new functionality, but have to accept that the APIs will wholly change when we release with 7.8.x down the road. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Mon Mar 31 15:02:07 2014 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Mon, 31 Mar 2014 08:02:07 -0700 Subject: Gearing up (again) for the next release: 2014.2.0.0 In-Reply-To: References: Message-ID: On Mon, Mar 31, 2014 at 2:20 AM, Sean Leather wrote: > On Sun, Mar 30, 2014 at 10:06 PM, Mark Lentczner wrote: > >> *New packages:* >> >> dlist (needed by aeson, which version?) >> >> > 0.7.0.1 > Noted. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Mon Mar 31 15:03:36 2014 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Mon, 31 Mar 2014 08:03:36 -0700 Subject: Gearing up (again) for the next release: 2014.2.0.0 In-Reply-To: <1396258839666-5746699.post@n5.nabble.com> References: <1396258839666-5746699.post@n5.nabble.com> Message-ID: On Mon, Mar 31, 2014 at 2:40 AM, harry wrote: > Should html be replaced with blaze-html? That's what people actually seem > to > be using these days. > If we want to switch to blaze-html, we should include it now, but leave html in for perhaps the next year (two?), marking it deprecated. Discussion? -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Mon Mar 31 15:05:23 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 31 Mar 2014 11:05:23 -0400 Subject: Backward-compatible role annotations In-Reply-To: References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com> <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com> <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu> <53313E49.1040405@ifi.lmu.de> <8761n2ob4f.fsf@gnu.org> <533165DF.5030206@ifi.lmu.de> <7B4344AC-7EB2-4892-8C07-969456EC6602@cis.upenn.edu> <1916CF2B-9B03-4CBD-8559-0AD4C4834E85@cis.upenn.edu> Message-ID: <1C0E9E4D-CEF0-4832-888F-7284A1597294@cis.upenn.edu> Hi Dominique, When implementing roles, I was indeed worried about the problem you're addressing: that code that previously worked with GND now won't. However, it turns out that few people have really complained about this. IIRC, in all of Hackage, only 3 packages needed to be changed because of this. If there were a larger impact to the GND breakage, I think your suggestion would be a good one. The problem I'm adressing in this thread is different: that library authors have been given a new, not-backward-compatible way of preventing abuses of their datatypes, and no proposal I have seen really addresses all of the problems here. I'm hoping my no-role-annots package might be helpful, but it doesn't fully resolve the issues. Richard On Mar 31, 2014, at 2:51 AM, Dominique Devriese wrote: > Richard, > > (re-posting because I first used an address that is not subscribed to the lists) > > I've been wondering about the following: it seems like the main > problem in this situation is that the GeneralizedNewtypeDeriving > extension changed meaning from "just coerce everything while deriving" > to "only coerce stuff if it's allowed by the relevant role > annotations". Would it not be an alternative solution to split up the > GND extension into > > * a backwards-compatible one (called GeneralizedNewtypeDeriving for > backwards compatibility ;)) that ignores role annotations (as before) > and uses unsafeCoerce whereever necessary > * a safe one (called e.g. SafeNewtypeDeriving) that respects role annotations > > The first one could then be deprecated and removed in a release or > two. That might give library maintainers time to move their packages > to SafeNewtypeDeriving when they have tested that everything works... > > Regards, > Dominique > > P.S.: The above is based on a limited understanding of the problem, so > I'm sorry if it misses some aspect of the problem... > > 2014-03-31 2:14 GMT+02:00 Richard Eisenberg : >> I spent some time thinking about what, precisely, can be done here to make >> folks happier. (See the thread beginning here: >> http://www.haskell.org/pipermail/libraries/2014-March/022321.html) And, the >> answer seemed to all be in the concrete syntax. The only logical alternative >> (that I could think of) to having roles is to disallow GND, and I don't >> think anyone is proposing that. And, it is impossible to infer an author's >> desired roles for a datatype. The heuristics mentioned here all seem far too >> fragile and hard to predict to become a lasting feature of GHC (in my >> opinion). What's left? Concrete syntax. >> >> So, I have written and uploaded no-role-annots-1.0, a backward-compatible >> alternative to role annotations -- no CPP required. It's not as principled >> as proper role annotations, but it should do the job for most users. >> >> Here are two examples: >> >> 1. Datatypes: >> >>> import Language.Haskell.RoleAnnots >>> >>> data Map k v = >>> (Nominal k, Representational v) => MkMap [(k,v)] >> >> The constraints (which need be put on only one data constructor, if there >> are many) will get the built-in role inference mechanism to do what the user >> requests. In this example, the `Representational v` is actually redundant, >> but causes no harm. Because these classes have universal instances >> ("instance Nominal a") and have no methods, they should have no run-time >> significance. The only downside I can see is that the code above needs >> -XGADTs or -XExistentialQuantification to work, though it is neither a GADT >> nor has existentials. (Pattern-matching on such a definition needs no >> extensions.) >> >> 2. Newtypes: >> >> Newtype constructors cannot be constrained, unfortunately. So, we have to >> resort to Template Haskell: >> >>> import Language.Haskell.RoleAnnots >>> >>> roleAnnot [NominalR, RepresentationalR] >>> [d| newtype Map k v = MkMap [(k, v)] |] >> >> This is clearly worse, but I was able to come up with no other solution that >> worked for newtypes. Note that, in the example, I used the fact that >> Template Haskell interprets a bare top-level expression as a Template >> Haskell splice. We could also wrap that line in $( ... ) to be more explicit >> about the use of TH. Also problematic here is that the code above requires >> -XRoleAnnotations in GHC 7.8. To get this extension enabled without using >> CPP, put it in a condition chunk in your .cabal file, like this: >> >>> if impl(ghc >= 7.8) >>> default-extensions: RoleAnnotations >> >> I hope this is helpful to everyone. Please feel free to post issues/pull >> requests to my github repo at github.com/goldfirere/no-role-annots. >> >> Thanks, >> Richard >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries From mark.lentczner at gmail.com Mon Mar 31 15:05:54 2014 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Mon, 31 Mar 2014 08:05:54 -0700 Subject: Gearing up (again) for the next release: 2014.2.0.0 In-Reply-To: References: Message-ID: On Mon, Mar 31, 2014 at 2:50 AM, Sven Panne wrote: > Using 2.5.1.0 (released about 2 months ago) would be nice, but not > really crucial. > Noted and updated in spec file. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Mon Mar 31 15:18:53 2014 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 31 Mar 2014 11:18:53 -0400 Subject: Gearing up (again) for the next release: 2014.2.0.0 In-Reply-To: References: Message-ID: mtl should bump to 2.1.3.1 On Sunday, March 30, 2014, Mark Lentczner wrote: > SO, In anticipation of releasing a HP shortly (1 month?) after GHC 7.8... > I'd like to get going on nailing down package versions. > > I've been working intently on the new Haskell Platform build process (see > the new-build branch), > and have been building platforms against the release. Here is the > description of versions I'm working with: > > [ incGHC "7.8" > , incGHCLib "array" "0.5.0.0" > , incGHCLib "base" "4.7.0.0" > , incGHCLib "bytestring" "0.10.4.0" > , incGHCLib "Cabal" "1.18.1.3" > , incGHCLib "containers" "0.5.4.0" > , incGHCLib "deepseq" "1.3.0.2" > , incGHCLib "directory" "1.2.0.2" > , incGHCLib "filepath" "1.3.0.2" > , incGHCLib "haskell2010" "1.1.1.1" > , incGHCLib "haskell98" "2.0.0.3" > , incGHCLib "hpc" "0.6.0.1" > , incGHCLib "old-locale" "1.0.0.6" > , incGHCLib "old-time" "1.1.0.2" > , incGHCLib "pretty" "1.1.1.1" > , incGHCLib "process" "1.2.0.0" > , incGHCLib "template-haskell" "2.9.0.0" > , incGHCLib "time" "1.4.1" > , incGHCLib "transformers" "0.3.0.0" > > , notWindows $ incGHCLib "unix" "2.7.0.1" > , onlyWindows $ incGHCLib "Win32" "2.3.0.1" > > , incLib "async" "2.0.1.5" > , incLib "attoparsec" "0.10.4.0" > , incLib "case-insensitive" "1.1.0.3" > , incLib "cgi" "3001.1.7.5" > , incLib "fgl" "5.4.2.4" > , incLib "GLUT" "2.5.0.2" > , incLib "GLURaw" "1.4.0.0" > , incLib "haskell-src" "1.0.1.5" > , incLib "hashable" "1.2.1.0" > , incLib "html" "1.0.1.2" > , incLib "HTTP" "4000.2.10" > , incLib "HUnit" "1.2.5.2" > , incLib "mtl" "2.1.2" > , incLib "network" "2.4.2.2" > , incLib "OpenGL" "2.9.1.0" > , incLib "OpenGLRaw" "1.4.0.0" > , incLib "parallel" "3.2.0.4" > , incLib "parsec" "3.1.5" > , incLib "primitive" "0.5.2.1" > , incLib "QuickCheck" "2.6" > , incLib "random" "1.0.1.1" > , incLib "regex-base" "0.93.2" > , incLib "regex-compat" "0.95.1" > , incLib "regex-posix" "0.95.2" > , incLib "split" "0.2.2" > , incLib "stm" "2.4.2" > , incLib "syb" "0.4.1" > , incLib "text" "1.1.0.0" > , incLib "unordered-containers" "0.2.3.3" > , incLib "vector" "0.10.9.1" > , incLib "xhtml" "3000.2.1" > , incLib "zlib" "0.5.4.1" > > , incTool "cabal-install" "1.18.0.3" > , incTool "alex" "3.1.2" > , incTool "happy" "1.19.2" > > , incTool "hscolour" "1.20.3" > , incTool "haddock" "2.14.0" > ] > > However, there are some issues to contend with: > > *Haddock* - is there any reason not to use the version built and > distributed with GHC 7.8? > > *Shipped w/GHC* - GHC 7.8 ships with several more packages than we > include in the platform. I want to review how these are handled: > > *possibly include in platform* > > - binary-0.7.1.0 > - ghc-prim-0.3.1.0 > - hoopl-3.10.0.0 > > *shouldn't include in platform* > - bin-package-db-0.0.0.0 > - integer-gmp-0.5.1.0 > - rts-1.0 > > *shipped with GHC, but not registered in pkg-db, yet possible useful to > include in platform:* > > - haskeline-0.7.1.2 > - terminfo-0.4.0.0 > - xhtml-3000.2.1 -- already in platform, but HP re-builds it... > seems silly? > > *cgi* - no longer builds, and we've been unwilling to bring it forward > because it pulls in MonadCatchIO-mtl > > *hscolour* - never approved as part of platform, but we use it to > generate the haddock in both GHC and the Platform - shouldn't we just > include it? > > *New packages:* > Last time we had a bunch we wanted... but timing, especially vis-a-vis 7.8 > and the new Builder classes, caused us to delay them. Shall we include: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Mon Mar 31 15:34:05 2014 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Mon, 31 Mar 2014 08:34:05 -0700 Subject: Gearing up (again) for the next release: 2014.2.0.0 In-Reply-To: References: Message-ID: On Mon, Mar 31, 2014 at 8:18 AM, Edward Kmett wrote: > mtl should bump to 2.1.3.1 > Noted. Should we be considering exceptions ready for the platform? The package cgi is in a bind as it uses mtl, and now uses MonadCatchIO-mtl.... but I'm assuming that exceptions would satisfy its needs, and is a more likely the way forward. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Mon Mar 31 15:51:43 2014 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 31 Mar 2014 11:51:43 -0400 Subject: Gearing up (again) for the next release: 2014.2.0.0 In-Reply-To: References: Message-ID: <6F7EC423-A832-4562-A871-65FA8151E6DE@gmail.com> I'd be open to including it. I've been working with Snoyman on it off and on, and it is pretty stable. Frankly, I've been on a quest to eradicate MonadCatchIO-transformers dependencies from my code ever since it added monads-tf support, as it drags in conflicts for the mtl and drives up random user complaints I receive. Sent from my iPad > On Mar 31, 2014, at 11:34 AM, Mark Lentczner wrote: > > >> On Mon, Mar 31, 2014 at 8:18 AM, Edward Kmett wrote: >> mtl should bump to 2.1.3.1 > > Noted. > > Should we be considering exceptions ready for the platform? > The package cgi is in a bind as it uses mtl, and now uses MonadCatchIO-mtl.... but I'm assuming that exceptions would satisfy its needs, and is a more likely the way forward. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicsma at chalmers.se Mon Mar 31 17:32:29 2014 From: nicsma at chalmers.se (Nick Smallbone) Date: Mon, 31 Mar 2014 19:32:29 +0200 Subject: Gearing up (again) for the next release: 2014.2.0.0 In-Reply-To: (Mark Lentczner's message of "Sun, 30 Mar 2014 13:06:26 -0700") References: Message-ID: <8761munuj6.fsf@laptop.8325.org> Mark Lentczner writes: > SO, In anticipation of releasing a HP shortly (1 month?) after GHC > 7.8... I'd like to get going on nailing down package versions. Hi Mark, Any chance of getting QuickCheck 2.7.3 in there? It has a number of nice improvements over 2.6, the biggest of which is generic shrinking to make it easier to get minimal counterexamples (changelog: http://hackage.haskell.org/package/QuickCheck-2.7.3/changelog). One complication is that we switched to a different random number generator because of some flaws with the one in System.Random. So we would also need to pull in the tf-random package (http://hackage.haskell.org/package/tf-random-0.4). Nick From dominique.devriese at cs.kuleuven.be Mon Mar 31 18:12:59 2014 From: dominique.devriese at cs.kuleuven.be (Dominique Devriese) Date: Mon, 31 Mar 2014 20:12:59 +0200 Subject: Backward-compatible role annotations In-Reply-To: <1C0E9E4D-CEF0-4832-888F-7284A1597294@cis.upenn.edu> References: <78518EC7-BC18-4732-90B6-1AB37048D2A3@cis.upenn.edu> <59543203684B2244980D7E4057D5FBC1488BA55B@DB3EX14MBXC308.europe.corp.microsoft.com> <2F1D91F2-0AD6-4E98-81E3-9A95E6024BA3@gmail.com> <8FD54493-CC52-4B90-9DD2-E7C91024FC30@cis.upenn.edu> <53313E49.1040405@ifi.lmu.de> <8761n2ob4f.fsf@gnu.org> <533165DF.5030206@ifi.lmu.de> <7B4344AC-7EB2-4892-8C07-969456EC6602@cis.upenn.edu> <1916CF2B-9B03-4CBD-8559-0AD4C4834E85@cis.upenn.edu> <1C0E9E4D-CEF0-4832-888F-7284A1597294@cis.upenn.edu> Message-ID: Richard, Right, but I was thinking about the debate between "nominal/non-parametric-by-default" or "representational/parametric-by-default" for parameters of data types that aren't forced to nominal from inspecting the datatype implementation. As I understand it, representational-by-default (currently used) may leave libraries that don't add role annotations open for abuse, but won't unnecessarily break library users' code and nominal-by-default prevents all abuse but may unnecessarily break code that uses libraries that have not added proper role annotations. What I was wondering about is if the dilemma could be solved by choosing nominal-by-default in the long term for the role inference (so that library writers cannot accidentally leave abstraction holes open by forgetting to add role annotations) and use them in the long-term-supported SafeNewtypeDeriving extension, but provide a deprecated not-quite-as-safe GND extension for helping out users of libraries that have not yet added role annotations. I would fancy that this not-quite-as-safe GND could use unsafeCoerce wherever the safe one would give an error about annotated roles. Regards, Dominique 2014-03-31 17:05 GMT+02:00 Richard Eisenberg : > Hi Dominique, > > When implementing roles, I was indeed worried about the problem you're addressing: that code that previously worked with GND now won't. However, it turns out that few people have really complained about this. IIRC, in all of Hackage, only 3 packages needed to be changed because of this. If there were a larger impact to the GND breakage, I think your suggestion would be a good one. > > The problem I'm adressing in this thread is different: that library authors have been given a new, not-backward-compatible way of preventing abuses of their datatypes, and no proposal I have seen really addresses all of the problems here. I'm hoping my no-role-annots package might be helpful, but it doesn't fully resolve the issues. > > Richard > > On Mar 31, 2014, at 2:51 AM, Dominique Devriese wrote: > >> Richard, >> >> (re-posting because I first used an address that is not subscribed to the lists) >> >> I've been wondering about the following: it seems like the main >> problem in this situation is that the GeneralizedNewtypeDeriving >> extension changed meaning from "just coerce everything while deriving" >> to "only coerce stuff if it's allowed by the relevant role >> annotations". Would it not be an alternative solution to split up the >> GND extension into >> >> * a backwards-compatible one (called GeneralizedNewtypeDeriving for >> backwards compatibility ;)) that ignores role annotations (as before) >> and uses unsafeCoerce whereever necessary >> * a safe one (called e.g. SafeNewtypeDeriving) that respects role annotations >> >> The first one could then be deprecated and removed in a release or >> two. That might give library maintainers time to move their packages >> to SafeNewtypeDeriving when they have tested that everything works... >> >> Regards, >> Dominique >> >> P.S.: The above is based on a limited understanding of the problem, so >> I'm sorry if it misses some aspect of the problem... >> >> 2014-03-31 2:14 GMT+02:00 Richard Eisenberg : >>> I spent some time thinking about what, precisely, can be done here to make >>> folks happier. (See the thread beginning here: >>> http://www.haskell.org/pipermail/libraries/2014-March/022321.html) And, the >>> answer seemed to all be in the concrete syntax. The only logical alternative >>> (that I could think of) to having roles is to disallow GND, and I don't >>> think anyone is proposing that. And, it is impossible to infer an author's >>> desired roles for a datatype. The heuristics mentioned here all seem far too >>> fragile and hard to predict to become a lasting feature of GHC (in my >>> opinion). What's left? Concrete syntax. >>> >>> So, I have written and uploaded no-role-annots-1.0, a backward-compatible >>> alternative to role annotations -- no CPP required. It's not as principled >>> as proper role annotations, but it should do the job for most users. >>> >>> Here are two examples: >>> >>> 1. Datatypes: >>> >>>> import Language.Haskell.RoleAnnots >>>> >>>> data Map k v = >>>> (Nominal k, Representational v) => MkMap [(k,v)] >>> >>> The constraints (which need be put on only one data constructor, if there >>> are many) will get the built-in role inference mechanism to do what the user >>> requests. In this example, the `Representational v` is actually redundant, >>> but causes no harm. Because these classes have universal instances >>> ("instance Nominal a") and have no methods, they should have no run-time >>> significance. The only downside I can see is that the code above needs >>> -XGADTs or -XExistentialQuantification to work, though it is neither a GADT >>> nor has existentials. (Pattern-matching on such a definition needs no >>> extensions.) >>> >>> 2. Newtypes: >>> >>> Newtype constructors cannot be constrained, unfortunately. So, we have to >>> resort to Template Haskell: >>> >>>> import Language.Haskell.RoleAnnots >>>> >>>> roleAnnot [NominalR, RepresentationalR] >>>> [d| newtype Map k v = MkMap [(k, v)] |] >>> >>> This is clearly worse, but I was able to come up with no other solution that >>> worked for newtypes. Note that, in the example, I used the fact that >>> Template Haskell interprets a bare top-level expression as a Template >>> Haskell splice. We could also wrap that line in $( ... ) to be more explicit >>> about the use of TH. Also problematic here is that the code above requires >>> -XRoleAnnotations in GHC 7.8. To get this extension enabled without using >>> CPP, put it in a condition chunk in your .cabal file, like this: >>> >>>> if impl(ghc >= 7.8) >>>> default-extensions: RoleAnnotations >>> >>> I hope this is helpful to everyone. Please feel free to post issues/pull >>> requests to my github repo at github.com/goldfirere/no-role-annots. >>> >>> Thanks, >>> Richard >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://www.haskell.org/mailman/listinfo/libraries > From mark.lentczner at gmail.com Mon Mar 31 18:15:59 2014 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Mon, 31 Mar 2014 11:15:59 -0700 Subject: Gearing up (again) for the next release: 2014.2.0.0 In-Reply-To: <8761munuj6.fsf@laptop.8325.org> References: <8761munuj6.fsf@laptop.8325.org> Message-ID: On Mon, Mar 31, 2014 at 10:32 AM, Nick Smallbone wrote: > Any chance of getting QuickCheck 2.7.3 in there? > Sounds good... but... > One complication is that we switched to a different random number > generator because of some flaws with the one in System.Random. > So we would also need to pull in the tf-random package > (http://hackage.haskell.org/package/tf-random-0.4). > This is unfortunate. That package doesn't look like a likely candidate for the platform: It is new, and the API looks like it has been in rapid, non-stable development for the last month. Is is possible that you can make QC work with standard random package, and only use tf-random as an option? Is there something seriously flawed in random that should be fixed there? - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Mon Mar 31 18:21:26 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 31 Mar 2014 14:21:26 -0400 Subject: Gearing up (again) for the next release: 2014.2.0.0 In-Reply-To: References: Message-ID: If the new shake tooling really means the release cycles will be faster with HP 7.8 series, i"m all for 7.8.1 HP :) On Sunday, March 30, 2014, Mark Lentczner wrote: > *happy *bumped to* 1.19.3* > *alex *bumped to* 3.1.3* > *haddock *bumped to* 2.14.1* > > *- but question about tying to GHC release still open: The concern is > since GHC ships with it's doc built with the haddock executable it ships, > will we have problems building the rest of the docs with a later haddock -- > and having all the cross references work?* > > > As for GHC 7.8.2 - Where is the plan for 7.8.2 documented? It is barely > mentioned in the GHC mailing list, and no mention in the GHC trac wiki, and > the issues milestone has scant info. > > I'm very reluctant to hold out for an unknown GHC release. Unless we have > good reason to think that GHC 7.8.1 is a bad release and will leave scads > of people with broken build systems.... I'd like to continue to plan on > releasing HP in mid May (so on schedule for 2014.2.0.0). As such, unless > the turn of 7.8.2 comes within a week or two of 7.8.1 - let's stick with > 7.8.1. > > Finally - note that part of my big push to totally re-write the Haskell > Platform is so that we can all feel more confident turning a version more > quickly if we need. If 7.8.2 comes out this Summer, and we think it is an > important enough improvement - we can turn HP too. > > - Mark > > > ? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicsma at chalmers.se Mon Mar 31 18:58:30 2014 From: nicsma at chalmers.se (Nick Smallbone) Date: Mon, 31 Mar 2014 20:58:30 +0200 Subject: Gearing up (again) for the next release: 2014.2.0.0 In-Reply-To: References: <8761munuj6.fsf@laptop.8325.org> Message-ID: <20140331185830.GA15279@8325.org> Hi Mark, On Monday 31 March, 2014 at 11:15 am, Mark Lentczner wrote: > On Mon, Mar 31, 2014 at 10:32 AM, Nick Smallbone wrote: > > One complication is that we switched to a different random number > > generator because of some flaws with the one in System.Random. > > So we would also need to pull in the tf-random package > > (http://hackage.haskell.org/package/tf-random-0.4). > > > This is unfortunate. That package doesn't look like a likely candidate for > the platform: It is new, and the API looks like it has been in rapid, > non-stable development for the last month. Yes, I understand this objection. Then perhaps we should hold back on it for now and see how we stand the next time around. > Is is possible that you can make QC work with standard random package, and > only use tf-random as an option? Is there something seriously flawed in > random that should be fixed there? I would rather not switch back to StdGen. We have stumbled into situations in the past where we can't falsify a property just because StdGen can't come up with the right random values - while (thankfully) extremely rare, it makes me uncomfortable that it happens at all. This mostly happens when generating random functions. Nick