Re: Type-level generics
Ah, nice. I was actually exploring the vague general idea behind that approach earlier this evening. Magalhães (unsurprisingly) has developed it much much further. David FeuerWell-Typed, LLP Original message From: Ryan ScottDate: 9/2/17 10:36 PM (GMT-05:00) To: ghc-devs@haskell.org Subject: Re: Type-level generics If you're willing to go a completely different route from GHC.Generics, then you might be interested in the paper Generic Programming with Multiple Parameters [1] (whose existence I just learned of—thanks to Pedro, the author, for pointing it out to me). It does present a single Generic class that is capable of working over any number of type parameters, although the interface presented is significantly more complex than the current GHC.Generics. The only reason I mention backwards compatibility is that if we are going to introduce a GHC.Generics 2.0 some day, it'd be nice to have a way to subsume the old interface with the new one, and fortunately, the aforementioned paper includes an algorithm for doing so. My hope was that we'd be able to incorporate these ideas into a design that also grants the ability to write Generic instances for GADTs, but I don't think GHC has a fancy enough type system to do this satisfactorily at the moment. Ryan S. - [1] http://dreixel.net/research/pdf/gpmp_colour.pdf ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Type-level generics
If you're willing to go a completely different route from GHC.Generics, then you might be interested in the paper Generic Programming with Multiple Parameters [1] (whose existence I just learned of—thanks to Pedro, the author, for pointing it out to me). It does present a single Generic class that is capable of working over any number of type parameters, although the interface presented is significantly more complex than the current GHC.Generics. The only reason I mention backwards compatibility is that if we are going to introduce a GHC.Generics 2.0 some day, it'd be nice to have a way to subsume the old interface with the new one, and fortunately, the aforementioned paper includes an algorithm for doing so. My hope was that we'd be able to incorporate these ideas into a design that also grants the ability to write Generic instances for GADTs, but I don't think GHC has a fancy enough type system to do this satisfactorily at the moment. Ryan S. - [1] http://dreixel.net/research/pdf/gpmp_colour.pdf ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Type-level generics
Am Samstag, den 02.09.2017, 11:35 -0400 schrieb Ryan Scott: > > When I looked at it the last time, there were some apparent > > leftovers in the form of types or type parameters never used. > > Are you referring to the `p` type parameters that are found in most of > the data types in GHC.Generics? No, there were really unused things. > If so, they are most definitely used—try deriving Generic1 to see this > in action! I know that they are needed for Generic1, but they are not needed for Generic. > It's true that in the context of Generic (without the 1 at the end) > the `p` isn't used, but this is by design, as this allows us to share > the same representation types across Generic and Generic1. It would be great if we could employ kind polymorphism or even type-in- type to have a single set of representation types, but still no unused parameters. > > there is no possibility to work with types with more than one > > parameter. > > Quite true. But I posit that engineering GHC.Generics to work with > more than one type parameter at a time is much harder than it sounds. > After all, to profitably work with even a *single* type parameter > (what Generic1 does), we must bring in three additional representation > types: Par1, Rec1, and (:.:), depending on where in the datatype the > last type parameter occurs. If we wanted to have, say, Generic2, we'd > similarly need to be able to work with many more combinations of type > parameter positions, such as: > > * data Foo1 a b = Foo1 a b > * data Foo2 a b = Foo2 (Either a b) > * data Foo3 a b = Foo3 (Either b a) > * etc. Actually, I am looking for something even bigger: not just a Generic2 class, but a Generic class that can deal with types of any arity. > A naïve approach would be to tack on another type parameter at the end > of every representation type, and introduce more types to deal with > all the combinations of the first and second type parameter that could > arise. But this approach doesn't scale well—after all, at what number > N do you stop introducing new representation types? We should nowhere stop, but allow an arbitrary number of parameters. ☺ Maybe through striving for a Generic class that works with arbitrary arities, we will find some deeper pattern, which could relieve us from having ad-hoc types such as the Foo1, Foo2, and so on you mention above. > So extending GHC.Generics to deal with more than one type parameter is > far from obvious to me It is also far from obvious for me. I actually think that makin g GHC.Generics more generic (making it work with types of arbitrary arity) is a nice research task, not something than can be done very easily. > (let alone whether it could be made backwards compatible with the > current API). It should not be backwards compatible. If we insist on backwards compatibility, we can never arrive at a version that works with types of any arity. > > the GHC.Generics module looks a bit unpolished and ad-hoc at the > > moment. > > Yes, quite literally everything in GHC.Generics is one large, ad hoc > hack. But it's also a darn useful one :) I am worried that people get so much used to the current interface that it will be hard to change it for something better later. You already argued in favor of backwards compatibility. ☹ All the best, Wolfgang ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Type-level generics
Several good points were brought up. Let me go through them and try to make sense of what I can: > When I looked at it the last time, there were some apparent leftovers in the > form of types or type parameters never used. Are you referring to the `p` type parameters that are found in most of the data types in GHC.Generics? If so, they are most definitely used—try deriving Generic1 to see this in action! It's true that in the context of Generic (without the 1 at the end) the `p` isn't used, but this is by design, as this allows us to share the same representation types across Generic and Generic1. > there is no possibility to work with types with more than one parameter. Quite true. But I posit that engineering GHC.Generics to work with more than one type parameter at a time is much harder than it sounds. After all, to profitably work with even a *single* type parameter (what Generic1 does), we must bring in three additional representation types: Par1, Rec1, and (:.:), depending on where in the datatype the last type parameter occurs. If we wanted to have, say, Generic2, we'd similarly need to be able to work with many more combinations of type parameter positions, such as: * data Foo1 a b = Foo1 a b * data Foo2 a b = Foo2 (Either a b) * data Foo3 a b = Foo3 (Either b a) * etc. A naïve approach would be to tack on another type parameter at the end of every representation type, and introduce more types to deal with all the combinations of the first and second type parameter that could arise. But this approach doesn't scale well—after all, at what number N do you stop introducing new representation types? So extending GHC.Generics to deal with more than one type parameter is far from obvious to me (let alone whether it could be made backwards compatible with the current API). > the GHC.Generics module looks a bit unpolished and ad-hoc at the moment. Yes, quite literally everything in GHC.Generics is one large, ad hoc hack. But it's also a darn useful one :) > It looks like there's still one confusing reference to Par0: "Note how Par0 > and Rec0 both being mapped to K1 allows us to define a uniform instance here. > " but at least it's not tangled up in the already very confusing examples and > signatures. I think that sentence can be deleted entirely now? Indeed, an earlier part of the documentation in that module mentions that Par0 was deprecated (and removed, in fact), so we really shouldn't be mentioning it elsewhere. I'll remove that sentence. Ryan S. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Darwin Harbormaster builder down
Hello everyone, It seems that the OS X Harbormaster builder has dropped off the face of the internet. I'm trying to get in touch with Futureice about this but in the meantime I've disabled the OS X build plan. This means that patches submitted won't be validated on OS X until this is resolved. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Convenient URL alias for Trac tickets
Jan Stolarekwrites: > One can also create bookmark with a keyword, as described on GHC wiki: > Indeed that is true; however, this won't work in most mobile browsers it seems. Isn't progress great? :) Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Convenient URL alias for Trac tickets
One can also create bookmark with a keyword, as described on GHC wiki: https://ghc.haskell.org/trac/ghc/wiki/FirefoxTips Janek --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs