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 [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
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 <[hidden email]> wrote: Hi libraries, Johan, Edward, _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
That looks correct to me. Analogously for HashMap in unordered-containers of course. On Thu, Mar 13, 2014 at 2:49 PM, Johan Tibell <[hidden email]> wrote:
_______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
In reply to this post by Johan Tibell-2
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 <[hidden email]> wrote:
_______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
In reply to this post by Edward Kmett-2
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 <[hidden email]> 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 <[hidden email]> > 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 <[hidden email]> >> 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 > [hidden email] > http://www.haskell.org/mailman/listinfo/libraries > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
In reply to this post by Carter Schonwald
Yep. The role annotation should be CPP guarded. On Thu, Mar 13, 2014 at 2:51 PM, Carter Schonwald <[hidden email]> wrote:
_______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
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 <[hidden email]> wrote:
_______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
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 <[hidden email]> wrote:
_______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
In reply to this post by Johan Tibell-2
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 <[hidden email]> wrote:
_______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
In reply to this post by Edward Kmett-2
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 <[hidden email]> wrote:
_______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
In reply to this post by Edward Kmett-2
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 <[hidden email]> wrote:
_______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
In reply to this post by Edward Kmett-2
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 <[hidden email]> wrote:
_______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
In reply to this post by Richard Eisenberg-2
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 <[hidden email]> wrote:
_______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
In reply to this post by Richard Eisenberg-2
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 <[hidden email]> wrote:
_______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
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 <[hidden email]> 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 <[hidden email]> > 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 <[hidden email]> 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 <[hidden email]> >> 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 > [hidden email] > http://www.haskell.org/mailman/listinfo/libraries > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
Tagged and released containers-0.5.5.0. On Thu, Mar 13, 2014 at 9:26 PM, Austin Seipp <[hidden email]> wrote: That would be ideal if you don't mind, so we can go ahead and merge it _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
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:
_______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
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, _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
In reply to this post by Johan Tibell-2
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 _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
[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 [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
Free forum by Nabble | Edit this page |