From jpm at cs.uu.nl Mon Sep 1 08:49:01 2008 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Mon Sep 1 08:47:18 2008 Subject: [Hs-Generics] Splitting SYB from the base package in GHC 6.10 Message-ID: <52f14b210809010549y4cd91ae8ue7916b3d8f0670ed@mail.gmail.com> Hello all, I'm initiating this discussion per suggestion of SP Jones and following from [1]. The issue is: SYB is being moved out of base into its own package. However, the Data class is, in a way, tied to base since it depends on the deriving mechanism. Therefore, it was suggested that the entire Data.Generics.Basics module [2] should remain in base. This module defines the Data class and several associated functions and datatypes. I don't think anyone objected to this so far: please correct me if I'm wrong, or object now. Then it was also suggested that Data.Generics.Instances [3] could stay in base (perhaps inside Basics as well). This, however, would prevent dealing with the "dubious" Data instances [4], and this was one of the motivating factors to split SYB from base. This refers concretely to the instances: instance (Data a, Data b) => Data (a -> b) instance Typeable a => Data (IO a) instance Typeable a => Data (Ptr a) instance Typeable a => Data (StablePtr a) instance Typeable a => Data (IORef a) instance Typeable a => Data (ForeignPtr a) instance (Typeable s, Typeable a) => Data (ST s a) instance Typeable a => Data (TVar a) instance Typeable a => Data (MVar a) instance Typeable a => Data (STM a) instance (Data a, Integral a) => Data (Ratio a) These instances are defined in such a way that they do not traverse the datatype. In fact, there is no other possible implementation, and this implementation at least allows for datatypes which contain both "regular" and "dubious" elements to still have their "regular" elements traversed. However, this implies that a user cannot redefine such instances even in the case where s/he knows extra information about these types that would allow for a more useful instance definition, for instance. Claus, please correct me if I'm wrong, but if the 11 "dubious" instances (or perhaps less, given your message in [5]) go in the syb package and the remaining, "standard" ones stay in base, we: - Mantain backwards compatibility regarding SYB in 6.10, and - Can still deal with the issue by releasing a new version of the syb package later, independently of GHC. Since the deadline for 6.10 is approaching I'm assuming that we should try to minimize the changes there, while keeping future development in the syb package as open as possible. Finally, there are module naming issues, which are probably secondary to the issue above and can be dealt with separately and later. Thanks, Pedro [1] The base library and GHC 6.10: http://thread.gmane.org/gmane.comp.lang.haskell.libraries/9929 [2] http://www.haskell.org/ghc/dist/stable/docs/libraries/base/Data-Generics-Basics.html [3] http://www.haskell.org/ghc/dist/stable/docs/libraries/base/Data-Generics-Instances.html [4] http://www.haskell.org/pipermail/generics/2008-June/000347.html [5] http://article.gmane.org/gmane.comp.lang.haskell.libraries/9957 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/generics/attachments/20080901/4de68177/attachment.htm From bulat.ziganshin at gmail.com Mon Sep 1 08:55:41 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Sep 1 08:55:33 2008 Subject: [Hs-Generics] Splitting SYB from the base package in GHC 6.10 In-Reply-To: <52f14b210809010549y4cd91ae8ue7916b3d8f0670ed@mail.gmail.com> References: <52f14b210809010549y4cd91ae8ue7916b3d8f0670ed@mail.gmail.com> Message-ID: <13810139294.20080901165541@gmail.com> Hello Jose, Monday, September 1, 2008, 4:49:01 PM, you wrote: > These instances are defined in such a way that they do not traverse > the datatype. In fact, there is no other possible implementation, > and this implementation at least allows for datatypes which contain > both "regular" and "dubious" elements to still have their "regular" elements traversed. afaiu, this solution isn't specific to SYB, so it doesn't make sense to move this into SYB. alternatively, we can move these instances into separate module in order to allow user control whether these instances are imported -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From claus.reinke at talk21.com Mon Sep 1 11:04:53 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Mon Sep 1 11:03:16 2008 Subject: [Hs-Generics] Re: Splitting SYB from the base package in GHC 6.10 References: <52f14b210809010549y4cd91ae8ue7916b3d8f0670ed@mail.gmail.com> Message-ID: > The issue is: SYB is being moved out of base into its own package. > However, the Data class is, in a way, tied to base since it depends on the > deriving mechanism. My understanding is that the deriving mechanism would still work if class 'Data' was moved into 'syb', but changes in 'Data' would still need to be matched in the deriving mechanism (which isn't auto-generated from 'base', either). As long as 'syb' remains a core library, we can thus focus on assigning modules to 'syb' or 'base' by functionality. > Therefore, it was suggested that the entire Data.Generics.Basics module [2] > should remain in base. This module defines the Data class and several > associated functions and datatypes. I don't think anyone objected to this so > far: please correct me if I'm wrong, or object now. Assuming this is based on 'Data.Generics.Basics' and 'Data.Typeable' being of more general use than the rest of 'syb' (justifying a preferred dependency on 'base' rather than 'syb'), not any implementation constraints, I don't object in general. It does suggest a separate 'data-reflect' package for these two modules, but that could be left for later. However, if 'Data' is in 'base', and the 'data' types are in 'base', then the 'Data' instances for those 'data' types should probably also be in base (*) (the instance for 'Array a b' ought to move to 'array'). And the short-term issue with this is that these instances, their location, and their importers, need some revision, while 'base' wants to be stable. The hope was that splitting off 'syb' from 'base' would contain the changes in a package with named maintainer, outside 'base'. Wouldn't it be easier to have all of 'Data' in 'syb', at least until 'Data' and 'Typeable' move into their own package? But if you can find a way to make the 'Data'-in-'base' route work, I'm not going to object. > Then it was also suggested that Data.Generics.Instances [3] could stay in > base (perhaps inside Basics as well). This, however, would prevent dealing > with the "dubious" Data instances [4], and this was one of the motivating > factors to split SYB from base. This refers concretely to the instances: Rearranging the list slightly, for easier reference: -- these have (or produce) substructures of type 'a', which aren't -- traversed by the current Data instances (contrary to what one -- would expect, say, from a generic 'fmap' over these types) > instance (Data a, Data b) => Data (b -> a) > instance Typeable a => Data (IO a) > instance (Typeable s, Typeable a) => Data (ST s a) > instance Typeable a => Data (STM a) > instance Typeable a => Data (IORef a) > instance Typeable a => Data (TVar a) > instance Typeable a => Data (MVar a) -- here, the 'a' is a phantom type, without matching substructures > instance Typeable a => Data (Ptr a) > instance Typeable a => Data (StablePtr a) > instance Typeable a => Data (ForeignPtr a) -- here, the 'a' corresponds to substructures that should only -- be visible through the abstract interface, on top of which a -- 'data'-like view can be provided > instance (Data a, Integral a) => Data (Ratio a) In addition, a longer list of instances offer only runtime errors for some 'Data' operations (most notably for 'gunfold', though abstract types in general have a problem with reflection support). Are these necessary or would they profit from closer investigation? If the latter, those instances should probably not be in 'base'. > These instances are defined in such a way that they do not traverse the > datatype. In fact, there is no other possible implementation, and this > implementation at least allows for datatypes which contain both "regular" > and "dubious" elements to still have their "regular" elements traversed. Well, there are alternative instances that would at least improve traversal support [3], but that wouldn't work for queries, I think. > However, this implies that a user cannot redefine such instances even in the > case where s/he knows extra information about these types that would allow > for a more useful instance definition, for instance. Indeed, the implicit presence of these instances is the main issue, and reducing their presence and propagation affects 'base' and other core and extra libaries, so needs to happen soon. > Claus, please correct me if I'm wrong, but if the 11 "dubious" instances (or > perhaps less, given your message in [5]) go in the syb package and the > remaining, "standard" ones stay in base, we: > - Mantain backwards compatibility regarding SYB in 6.10, and > - Can still deal with the issue by releasing a new version of the syb > package later, independently of GHC. issues to consider, of the top of my head: - to what extent can core libraries be updated independent of 'base'? - unless 'base' can now be updated (there are two versions of 'base' in ghc head), 'base' must not depend on 'syb' - which other core libraries depend on 'syb'? are they updateable? - the current importers of (parts of) 'Data.Generics' need to be revised [1] - instances cannot be deprecated - since all instances are in one module, one could deprecate the module, but are module deprecations propagated to their importers automatically? - would 'Data.Generics' need to be deprecated, in favour of a version that does not implicitly re-export any/all instances? [2] Maintaining strict backwards-compatibility in 6.10 while still allowing for changes in 'syb' is going to be difficult, if only because clients might depend on 'Data.IntSet' and the like to re-export all current 'Data' instances, which we certainly want to stop. My 'syb-utils' [2] has alternatives to 'Data.Generics' that export either only standard instances or no instances, which would allow to deprecate all 'Data.Generics*' modules that are less specific about their instance exports, but would require use of alternative module names.. > Since the deadline for 6.10 is approaching I'm assuming that we should try > to minimize the changes there, while keeping future development in the syb > package as open as possible. Definitely. But some choices need to be made now. Mainly what goes where, how to handle deprecation, and how to reduce implicit instance propagation. Claus [1] http://article.gmane.org/gmane.comp.lang.haskell.libraries/9957 [2] http://www.cs.kent.ac.uk/~cr3/toolbox/haskell/#syb-utils [3] http://www.haskell.org/pipermail/libraries/2008-July/010319.html (*) this isn't a firm rule, either: recently, it was decided to keep the 'Data' instances for 'ghc' types out of 'ghc'.. From claus.reinke at talk21.com Mon Sep 1 15:04:23 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Mon Sep 1 15:08:18 2008 Subject: [Hs-Generics] Re: Splitting SYB from the base package in GHC 6.10 References: <52f14b210809010549y4cd91ae8ue7916b3d8f0670ed@mail.gmail.com> <20080901144259.GA3507@soi.city.ac.uk> Message-ID: > These instances are defined in such a way that they do not traverse the > datatype. In fact, there is no other possible implementation, and this > implementation at least allows for datatypes which contain both "regular" and > "dubious" elements to still have their "regular" elements traversed. > However, this implies that a user cannot redefine such instances even in the > case where s/he knows extra information about these types that would allow for > a more useful instance definition, for instance. |These two statements appear to be contradictory. Perhaps an example of |a possible instance would help. "no other possible implementation" is an overstatement, though an easy one to make: those 'Data' instances are incomplete because better instances are hard to come by. One can perhaps do little improvements, like replace the effective 'gmapT = id' for 'IO a' and 'b -> a' with something like[1]: gmapT f fun = f . fun -- instead of gmapT f fun = fun gmapT f io = (return . f) =<< io -- instead of gmapT f io = io but that still doesn't make those instances complete. If it wasn't for the partial uses, like skipping 'IO a' and 'b -> a' as parts of derived 'Data' instances, one wouldn't want these instances at all, imho (at least not in their current form). Then there are abstract types, for which the current default when implementing reflection is to assume "no constructors", hence no basis for 'gunfold', hence more incomplete 'Data' instances and runtime errors. It might be possible to experiment with associating exactly one, abstract, constructor with each abstract type instead, but that isn't something I'd like to bake in without more experience. Another way to look at it: 'Data' tries to do too much in a single class, and the consequence are all those half-implemented 'Data' instances. The probable long-term solution is to split 'Data' into 2 or 3 classes, so that we know that a any type instantiating 'DataGfoldl' really supports 'gfoldl' b any type instantiating 'DataGunfold' really supports 'gunfold' c any type instantiating 'DataReflect' really supports 'Data' reflection Currently, too many types instantiate 'Data' without supporting b or c (-> runtime errors), and a few instances don't even support a. All of which suggests that 'Data' should probably leave 'base', as it needs to evolve further? |Claus argued that -> and the monads could be treated by analogy |with Show for these types. I had mentioned 'Text.Show.Functions' as an example of "improper" instances provided for optional import to support 'deriving Show'. But when I read your sentence, my first thought was: perhaps there's also a way to apply the showList trick? That would neatly avoid either changing the 'deriving' mechanism or having dummy instances. More reason for moving everything to 'syb', keeping it flexible for a while. |There is an additional problem with types like ThreadId, Array, ST, STM, |TVar and MVar: they're notionally defined in other packages, even though |they're actually defined in partially-hidden GHC.* modules in base and |re-exported. Would it be sufficient for 'syb' to depend on both 'base' and those notional source packages? It would be useful to keep the instances in 'syb' until the 'Data' story has settled down, after which the instances ought to move to their 'data' type source packages. Claus [1] http://www.haskell.org/pipermail/libraries/2008-July/010319.html From jpm at cs.uu.nl Mon Sep 1 15:31:20 2008 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Mon Sep 1 15:29:36 2008 Subject: [Hs-Generics] Re: Splitting SYB from the base package in GHC 6.10 In-Reply-To: References: <52f14b210809010549y4cd91ae8ue7916b3d8f0670ed@mail.gmail.com> <20080901144259.GA3507@soi.city.ac.uk> Message-ID: <52f14b210809011231i46374da8t22c0a0f245d4ac6a@mail.gmail.com> Hello, On Mon, Sep 1, 2008 at 21:04, Claus Reinke wrote: > "no other possible implementation" is an overstatement, though an easy > one to make: those 'Data' instances are incomplete because better instances > are hard to come by. One can perhaps do little improvements, like replace > the effective 'gmapT = id' for 'IO a' and 'b -> a' with something like[1]: > > gmapT f fun = f . fun > -- instead of gmapT f fun = fun > > gmapT f io = (return . f) =<< io > -- instead of gmapT f io = io > But wouldn't these introduce additional inconsistencies? At least if introduced in the library itself. I am used to think that gmapT is implemented using gfoldl, and is only inside the Data class to allow for more efficient implementations, and not for alternative implementations... > Another way to look at it: > > 'Data' tries to do too much in a single class, and the consequence > are all those half-implemented 'Data' instances. The probable > long-term solution is to split 'Data' into 2 or 3 classes, > > so that we know that > > a any type instantiating 'DataGfoldl' really supports 'gfoldl' > b any type instantiating 'DataGunfold' really supports 'gunfold' > c any type instantiating 'DataReflect' really supports 'Data' reflection > > Currently, too many types instantiate 'Data' without supporting b > or c (-> runtime errors), and a few instances don't even support a. > > All of which suggests that 'Data' should probably leave 'base', > as it needs to evolve further? > Just for my understanding, can you give me an example of a datatype which currently has (b) but not (c) and vice-versa? Anyway, I guess keeping Data inside base does not preclude such splitting of Data: for backward compatibility the original Data would have to remain available, right? > |Claus argued that -> and the monads could be treated by analogy > |with Show for these types. > > I had mentioned 'Text.Show.Functions' as an example of "improper" > instances provided for optional import to support 'deriving Show'. > > But when I read your sentence, my first thought was: perhaps there's > also a way to apply the showList trick? That would neatly avoid either > changing the 'deriving' mechanism or having dummy instances. > > More reason for moving everything to 'syb', keeping it flexible > for a while. > By "everything" do you mean all instances or all the "dubious" ones? IIRC, the argument for having the "standard" instances in base is that leaving Data alone without any instances would mean that in most cases you would have to import SYB anyway to get any functionality. Or are there other reasons? Thanks, Pedro -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/generics/attachments/20080901/0bb4da79/attachment-0001.htm From leather at cs.uu.nl Mon Sep 1 16:22:45 2008 From: leather at cs.uu.nl (Sean Leather) Date: Mon Sep 1 16:31:17 2008 Subject: [Hs-Generics] Re: Splitting SYB from the base package in GHC 6.10 In-Reply-To: References: <52f14b210809010549y4cd91ae8ue7916b3d8f0670ed@mail.gmail.com> Message-ID: <3c6288ab0809011322t6db3700bn77f64a19690c1419@mail.gmail.com> > The issue is: SYB is being moved out of base into its own package. >> However, the Data class is, in a way, tied to base since it depends on the >> deriving mechanism. >> > > My understanding is that the deriving mechanism would still work if class > 'Data' was moved into 'syb', but changes in 'Data' would still need to be > matched in the deriving mechanism (which isn't auto-generated from 'base', > either). As long as 'syb' remains a core library, we can thus focus on > assigning modules to 'syb' or 'base' by functionality. > So, here's a (possible) summary from a general perspective. (1) Some people want to keep some parts of the SYB functionality in 'base', because these parts are closely linked to some parts of GHC. This is desired for convenience (and perhaps test coverage?). (2) Some people want to remove some parts of the SYB functionality from 'base', because they want to be able to maintain and release SYB separately. (3) Some people in group #2 are not sure what should be left in 'base' or extracted into 'syb.' My observations: (A) I don't see 'syb' ever becoming something other than a core library for GHC, considering it's close family ties. (B) I expect 'syb' to get updated and released more often than GHC. This is especially true considering the newfound interest. (C) I expect the 'syb' library will be tested using the current (and possibly past?) release(s) of GHC, because that's what releases will use in general. If something in a development version of GHC breaks SYB, then there may need to be a new 'syb' release for when that version of GHC is released. At that point, there may be a need for a temporary fork if other work is ongoing. (C) From a user's perspective I don't understand the splitting of SYB. Why is it that I can derive Data.Generics.Data, but I cannot actually use other functions built for it? So, given all of the above (assuming it's correct), it seems to me that the benefit leans towards migrating everything SYB-related into the 'syb' library. Is the motivation/argument for group #1 very strong? Hope this helps, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/generics/attachments/20080901/78632b33/attachment.htm From claus.reinke at talk21.com Mon Sep 1 20:00:26 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Mon Sep 1 19:58:48 2008 Subject: [Hs-Generics] Re: Splitting SYB from the base package in GHC 6.10 References: <52f14b210809010549y4cd91ae8ue7916b3d8f0670ed@mail.gmail.com> <20080901144259.GA3507@soi.city.ac.uk> <52f14b210809011231i46374da8t22c0a0f245d4ac6a@mail.gmail.com> Message-ID: <4502A3EDE1C74860B22EF664CE894C27@cr3lt> >> gmapT f fun = f . fun >> -- instead of gmapT f fun = fun > > But wouldn't these introduce additional inconsistencies? At least if > introduced in the library itself. I am used to think that gmapT is > implemented using gfoldl, and is only inside the Data class to allow for > more efficient implementations, and not for alternative implementations... Well, I'd like to define 'gmapT' in terms of 'gfoldl' (in a non-trivial, sensible way). The default for gfoldl is 'gfoldl _ z = z', but that doesn't help much here since 'z's type is rather too polymorphic to be of use: 'forall c g . g -> c g'. I've wondered occasionally whether requiring 'Typeable g' there would help. The next try is to expand our function, so that we can pretend we have some constructor to work on in 'gfoldl': -- fun ==> \x->fun x ==> (\fun x->fun x) fun Then we can do (using scoped type variables to fix the 'a' and 'b'): gfoldl k z fun = z (\fun x->fun x) `k` fun -- gmapT f fun = f . fun gmapT f fun = unId $ gfoldl (k f) (Id) fun where k f (Id c) x = Id (c (case (cast x :: Maybe (a -> b)) of Just x -> fromJust $ cast (f . x) Nothing -> x)) but whether that is very enlightening, I wouldn't want to say;-) > Just for my understanding, can you give me an example of a datatype which > currently has (b) but not (c) and vice-versa? b ('toConstr'&co) usually comes with c ('gunfold'). I've defined some 'Data' instances which implemented b without c, but I don't think that is typical. My reason for splitting the functionality in three ('gfoldl', 'toConstr', 'gunfold') was just to be systematic, hoping in particular for implementations of 'gunfold' (or, more generally, constructing 'data' from parts) that do not depend on reflection. > Anyway, I guess keeping Data inside base does not preclude such splitting of > Data: for backward compatibility the original Data would have to remain > available, right? It used to be the case that 'base' could not be updated, so anything in it would be fixed until the next ghc release. Preserving the original 'Data' would also preserve the original clients and incomplete instances, which is not what one would want (instead, one would want to instantiate just those component classes whose methods can be implemented and used without runtime errors, preserving compatibility of non-failing code). But that is all far future, 6.12 or so, not urgent now. I just mentioned it because there is very little about SYB that I'm sure about, and this is another example of something that might be worth looking into. And the more you keep in 'base', the less you can improve. >> More reason for moving everything to 'syb', keeping it flexible >> for a while. > > By "everything" do you mean all instances or all the "dubious" ones? IIRC, > the argument for having the "standard" instances in base is that leaving > Data alone without any instances would mean that in most cases you would > have to import SYB anyway to get any functionality. Or are there other > reasons? Note the "for a while" there. If you are at liberty to change 'base' and users can update 'base' without waiting for the next ghc release, then you can do the changes in 'base'. Otherwise, everything that might change should be in a package you can change and users can update. Making that package 'syb' keeps things simple - later, after things have settled down again, one could spin off 'Data' and 'Typeable' into their own package ('data-reflection', 'introspection', ..). Or one could re-integrate 'Data' into 'base' to get smaller 'build-depends' (and less accurate Cabal dependencies..). But while you're looking into improving things, they need to be changeable, and 'base' usually isn't. Claus From simonpj at microsoft.com Tue Sep 2 06:50:15 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Sep 2 06:48:32 2008 Subject: [Hs-Generics] RE: Splitting SYB from the base package in GHC 6.10 In-Reply-To: <3c6288ab0809011322t6db3700bn77f64a19690c1419@mail.gmail.com> References: <52f14b210809010549y4cd91ae8ue7916b3d8f0670ed@mail.gmail.com> <3c6288ab0809011322t6db3700bn77f64a19690c1419@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE87494A8@EA-EXMSG-C334.europe.corp.microsoft.com> Sean Your analysis is good, but missing the following You can build stuff on class Data *other than* SYB. That's a motivation for not identifying Data with SYB. That's really the argument for keeping Data in 'base', so that others can build on it without depending on the full glory of SYB. (A weaker argument is that GHC "knows" about Data, to support 'deriving'. But that's less important.) Simon From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Sean Leather Sent: 01 September 2008 21:23 To: Claus Reinke Cc: Jos? Pedro Magalh?es; ross@soi.city.ac.uk; Simon Peyton-Jones; libraries@haskell.org; generics@haskell.org; igloo@earth.li Subject: Re: Splitting SYB from the base package in GHC 6.10 The issue is: SYB is being moved out of base into its own package. However, the Data class is, in a way, tied to base since it depends on the deriving mechanism. My understanding is that the deriving mechanism would still work if class 'Data' was moved into 'syb', but changes in 'Data' would still need to be matched in the deriving mechanism (which isn't auto-generated from 'base', either). As long as 'syb' remains a core library, we can thus focus on assigning modules to 'syb' or 'base' by functionality. So, here's a (possible) summary from a general perspective. (1) Some people want to keep some parts of the SYB functionality in 'base', because these parts are closely linked to some parts of GHC. This is desired for convenience (and perhaps test coverage?). (2) Some people want to remove some parts of the SYB functionality from 'base', because they want to be able to maintain and release SYB separately. (3) Some people in group #2 are not sure what should be left in 'base' or extracted into 'syb.' My observations: (A) I don't see 'syb' ever becoming something other than a core library for GHC, considering it's close family ties. (B) I expect 'syb' to get updated and released more often than GHC. This is especially true considering the newfound interest. (C) I expect the 'syb' library will be tested using the current (and possibly past?) release(s) of GHC, because that's what releases will use in general. If something in a development version of GHC breaks SYB, then there may need to be a new 'syb' release for when that version of GHC is released. At that point, there may be a need for a temporary fork if other work is ongoing. (C) From a user's perspective I don't understand the splitting of SYB. Why is it that I can derive Data.Generics.Data, but I cannot actually use other functions built for it? So, given all of the above (assuming it's correct), it seems to me that the benefit leans towards migrating everything SYB-related into the 'syb' library. Is the motivation/argument for group #1 very strong? Hope this helps, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/generics/attachments/20080902/6bee1806/attachment.htm From leather at cs.uu.nl Tue Sep 2 08:00:19 2008 From: leather at cs.uu.nl (Sean Leather) Date: Tue Sep 2 07:58:55 2008 Subject: [Hs-Generics] Re: Splitting SYB from the base package in GHC 6.10 In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE87494A8@EA-EXMSG-C334.europe.corp.microsoft.com> References: <52f14b210809010549y4cd91ae8ue7916b3d8f0670ed@mail.gmail.com> <3c6288ab0809011322t6db3700bn77f64a19690c1419@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE87494A8@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <3c6288ab0809020500n243c1127k2961068daa279714@mail.gmail.com> On Tue, Sep 2, 2008 at 12:50, Simon Peyton-Jones wrote: > Sean Your analysis is good, but missing the following > > You can build stuff on class Data **other than** SYB. That's a > motivation for not identifying Data with SYB. > > That's really the argument for keeping Data in 'base', so that others can > build on it without depending on the full glory of SYB. > Ah, okay. Then, that is a stronger argument. Thanks, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/generics/attachments/20080902/ff5b0504/attachment-0001.htm From jpm at cs.uu.nl Sun Sep 7 16:03:32 2008 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Sun Sep 7 16:01:31 2008 Subject: [Hs-Generics] Re: Splitting SYB from the base package in GHC 6.10 In-Reply-To: <48C12767.5010200@jellybean.co.uk> References: <20080903081355.GA2149@soi.city.ac.uk> <20080903115750.GA4722@soi.city.ac.uk> <52f14b210809040044k6df6a92x3442b04f45ba54f4@mail.gmail.com> <48C12767.5010200@jellybean.co.uk> Message-ID: <52f14b210809071303h4556c302mf3b52c93c8235d32@mail.gmail.com> Hello, On Fri, Sep 5, 2008 at 14:34, Jules Bean wrote: > Jos? Pedro Magalh?es wrote: > >> Complex has a derived instance. In Data.Complex: >> >> data (RealFloat a) => Complex a >> = !a :+ !a # if __GLASGOW_HASKELL__ >> deriving (Eq, Show, Read, Data) >> # else >> deriving (Eq, Show, Read) >> # endif >> >> Was there a problem with this? >> >> > Yes, isn't it exactly the same problem as Ratio? > > The derived instance 'leaks' the implementation detail of a complex number > as a real and imaginary component. As part of a large structure I might want > to apply some operation to all the 'Doubles' therein, but certainly not to > the components of any Complex Doubles. You can imagine particular situations > where I want to apply only to the real component, or something more subtle. > > You can also imagine that an alternative implementation of Complexes in > polar coordinates (with a suitable solution to the principle value problem) > is supposed to be abstractly the same, but would gain a totally different > Data instance. I think the question here is if the datatype if abstract or not. Complex exports its (:+) constructor, so the implementation details are not hidden. Therefore it is correct to traverse its arguments. Ratio, however, does not export its (:%) constructor: Ratio is abstract, while Complex is not. I guess then Complex should have a Data instance as it is above. But regarding Ratio, do we want to change its gfoldl to match its current gunfoldl (as suggested before), or go the other way around, and change its gunfold, toConstr and dataTypeOf to match its gfoldl? If we change its gfoldl, the instance is fully defined, but does not respect the data abstraction. If we go the other way around, the instance becomes partial (gunfold and toConstr return errors), but respects the data abstraction. In any case, the behaviour would differ from the current. Any opinions on this? Thanks, Pedro -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/generics/attachments/20080907/7bf009b1/attachment.htm From jpm at cs.uu.nl Mon Sep 15 07:28:30 2008 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Mon Sep 15 07:26:03 2008 Subject: [Hs-Generics] Re: Splitting SYB from the base package in GHC 6.10 In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE88093CD@EA-EXMSG-C334.europe.corp.microsoft.com> References: <52f14b210809010549y4cd91ae8ue7916b3d8f0670ed@mail.gmail.com> <20080902123523.GA18657@matrix.chaos.earth.li> <52f14b210809021145y5e667093m3d80290be2504b4c@mail.gmail.com> <1C4AE74FD8C843B1AAC9D92AE067F090@cr3lt> <20080902210637.GA7519@matrix.chaos.earth.li> <20080903081355.GA2149@soi.city.ac.uk> <638ABD0A29C8884A91BC5FB5C349B1C32AE88093CD@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <52f14b210809150428w4cd4061bg4b855fc44ac11b28@mail.gmail.com> Hello, On Wed, Sep 3, 2008 at 13:50, Simon Peyton-Jones wrote: > My reading of Claus's message is that, modulo discussion of some details of > [partial], he'd go with that plan. > > Is that acceptable to others? If so, someone (Jose) needs to sort out the > details. 19 Sept is GHC's release candidate, so we need this done well > before then. Are the details sorted out? Summarizing: - Data.Generics.Basics stays in base; - All other SYB modules besides Data.Generics.Instances go into a new 'syb' package; - Data.Generics.Instances is split in two, one part remaining in base and the other moving to the syb package. Regarding the instances, two aspects have to be considered: 1. Avoiding the implicit re-export of Data instances from modules in base; 2. Deciding which instances go where. Regarding (1), the following changes need to be done: - Ratio has to be fixed to have a consistent instance: either it's seen as an abstract datatype (therefore with undefined gunfold) or a gfoldl has to be defined matching its gunfold; - Complex should have its derived instance restored (or otherwise a manual instance with a proper gfoldl); - Other places that have to be changed: - The Data instance of Data.Array should be moved from Data.Generics.Instances into Array, to avoid syb dependency; - The imports of SYB in the following modules should be fixed to avoid bringing into scope all the instances: ./containers/Data/IntMap.hs ./containers/Data/IntSet.hs ./containers/Data/Map.hs ./containers/Data/Sequence.hs ./containers/Data/Set.hs ./containers/Data/Tree.hs ./network/Network/URI.hs ./packedstring/Data/PackedString.hs - The following modules use of Ratio instances, which is not problematic if the instance for Ratio is fixed. Therefore no change is needed here: ./haskell-src/Language/Haskell/Syntax.hs ./template-haskell/Language/Haskell/TH/Quote.hs ./template-haskell/Language/Haskell/TH/Syntax.hs - These modules depend on an instance for ForeignPtr Word8. Instances for types with phantom types stay in base, since no suitable instance can be given (see (2) below). Therefore no change is needed here: ./bytestring/Data/ByteString/Internal.hs ./bytestring/Data/ByteString/Lazy/Internal.hs Regarding (2), the separation of the 44 Data instances in Data.Generics.Instances is the following: - These 26 [standard] instances are uncontroversial and can accompany the Data class: [a] (Maybe a) (Either a b) () (,) (,,) (,,,) (,,,,) (,,,,,) (,,,,,,) Bool Ordering Char Double Float Integer Int Int8 Int16 Int32 Int64 Word Word8 Word16 Word32 Word64 - These 2 instances could also be [standard] and stay in base, after fixing (see (1) above): Ratio Complex - These 2 instances have phantom types. No good suggestion for what to do with them has shown up, therefore they stay in base as they are: Ptr ForeignPtr - These 6 instances have abstract datatypes. Unless there is some reason to keep them in base, I suggest they go into the syb package: DataType TyCon TypeRep Handle ThreadId StablePtr - These 7 go in the syb package for future discussion: (a -> b) (IO a) (ST s a) (STM a) (IORef a) (TVar a) (MVar a) - The instance for Array is moved into Data.Array. Any remarks? Thanks, Pedro -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/generics/attachments/20080915/19a7e702/attachment.htm From leather at cs.uu.nl Fri Sep 19 12:05:06 2008 From: leather at cs.uu.nl (Sean Leather) Date: Fri Sep 19 12:02:38 2008 Subject: [Hs-Generics] ANNOUNCE: Extensible and Modular Generics for the Masses (EMGM) 0.1 Message-ID: <3c6288ab0809190905h171fe0a6i3aac97454ba700e@mail.gmail.com> Extensible and Modular Generics for the Masses ============================================== Extensible and Modular Generics for the Masses (EMGM) is a library for generic programming in Haskell using type classes. This is the initial release of a maintained library for EMGM. Other versions have previously existed in various states from various sources. We plan to continue updating and maintaining this version. Visit the home page: http://www.cs.uu.nl/wiki/GenericProgramming/EMGM Features -------- The primary features of EMGM include: * Datatype-generic programming using sum-of-product views * Large collection of ready-to-use generic functions * Included support for standard datatypes: lists, Maybe, tuples * Easy to add support for new datatypes * Type classes make writing new functions straightforward in a structurally inductive style * Generic functions are extensible with ad-hoc cases for arbitrary datatypes * Good performance of generic functions The features of this distribution include: * The API is thoroughly documented with Haddock * Fully tested with QuickCheck and HUnit * Program coverage ensures that all useful code has been touched by tests * Tested on both Mac and Windows systems Requirements ------------ EMGM has the following requirements: * GHC 6.8.1 - It has been tested with versions 6.8.3 and 6.9.20080916. * Cabal library 1.2.1 - It has been tested with versions 1.2.3 and 1.4.0.1. Download & Source ----------------- Use caball-install: cabal install emgm Get the package: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/emgm Get the source: svn checkout https://svn.cs.uu.nl:12443/repos/dgp-haskell/EMGM Examples -------- Check out the examples: https://svn.cs.uu.nl:12443/viewvc/dgp-haskell/EMGM/examples/ Bugs & Support -------------- Report issues or request features: http://code.google.com/p/emgm/ Discuss EMGM with the authors, maintainers, and other interested persons: http://www.haskell.org/mailman/listinfo/generics Credits ------- The research for EMGM originated with Ralf Hinze. It was extended with work by Bruno Oliveira and Andres L?h. More details of the library functionality were explored by Alexey Rodriguez. We are very grateful to all of these people for the foundation on which this library was built. The current authors and maintainers of EMGM are: * Sean Leather * Jos? Pedro Magalh?es * Alexey Rodriguez * Andres L?h -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/generics/attachments/20080919/98272ec1/attachment-0001.htm From jpm at cs.uu.nl Tue Sep 30 09:52:37 2008 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Tue Sep 30 09:49:22 2008 Subject: [Hs-Generics] Re: instance visibility In-Reply-To: <48E1F683.7000702@gmail.com> References: <48BE480C.5050308@gmail.com> <2D93D24B65084422832AF68B82EF4106@cr3lt> <48DA55C0.2090406@gmail.com> <77766447D98E4243A6B4B87A3FC61A03@cr3lt> <20080924171002.GP1961@darcs.net> <48DA8B66.7020108@gmail.com> <20080924190928.GR1961@darcs.net> <48E1F683.7000702@gmail.com> Message-ID: <52f14b210809300652t6c79d354nf59ed0d7b8c651b4@mail.gmail.com> I'm trying to understand the implications of this discussion in the current splitting off of SYB from base. In the division that was more or less agreed [1], the Data class and its uncontested instances would be kept in base, whereas the rest would go into a new syb package. The instances were traditionally orphans in Data.Generics.Instances, but it was suggested that they should now be moved into Data.Generics.Basics. This would make SYB free of orphans, but no longer offers a user the possibility of avoid the import of Data.Generics.Instances to define its own instances. It also invalidates some of the changes proposed in [1], namely caring about the imports of Data.IntMap, Data.IntSet, etc. So my question is: should Data.Generics.Instances indeed be folded into Data.Generics.Basics (which contains the Data class and associated stuff)? (Worth noting is that the instances that are moved to the syb package will remain orphans, but the idea is that those might change or disappear in the future.) Thanks, Pedro [1] http://thread.gmane.org/gmane.comp.lang.haskell.libraries/9962/focus=9981 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/generics/attachments/20080930/bbc11239/attachment.htm