From jpm at cs.uu.nl Mon Sep 1 02:53:46 2008 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Mon Sep 1 02:52:03 2008 Subject: The base library and GHC 6.10 In-Reply-To: References: <20080828111232.GA15998@matrix.chaos.earth.li> <404396ef0808280428j5f8ce984q904f5f0e2b0e61ee@mail.gmail.com> <20080830120134.GA3741@matrix.chaos.earth.li> <20080831121055.GA5326@soi.city.ac.uk> <20080831121633.GA17919@matrix.chaos.earth.li> Message-ID: <52f14b210808312353g7a215815g3e65911f068c554e@mail.gmail.com> Hello, This issue has been discussed before [1] and I got the impression all instances were going to be in the syb package and not in base. I think it's preferable to deal with the dubious instances issue [2] once SYB has been put into its own package, but maybe the "standard" instances could stay in base. Regarding the naming issue: I would very much be in favor of entirely renaming SYB to Generics.SYB altogether. I think the current name doesn't make much sense (why Data? it doesn't really define a datastructure), and simply calling it Generics is too broad, given that this is only one of the libraries for generic programming around. This would also fit nicely with other (upcoming) libraries for generic programming. Thanks, Pedro [1] http://thread.gmane.org/gmane.comp.lang.haskell.libraries/9738 [2] http://thread.gmane.org/gmane.comp.lang.haskell.libraries/9672 On Mon, Sep 1, 2008 at 00:02, Claus Reinke wrote: > Leaving Data.Generics.Basics in base while moving > Data.Generics.Instances to syb raises the interesting issue of > dealing with the accidental re-exports of Data.Generics.Instances > from various places. Here is that list again (*): > > $ find . -name '*hs' | grep -v _darcs | xargs grep -l 'Data.Generics' | > grep -v Generics > ./array/Data/Array.hs > ./base/Data/Typeable.hs > ./bytestring/Data/ByteString/Internal.hs > ./bytestring/Data/ByteString/Lazy/Internal.hs > ./bytestring/Data/ByteString/Unsafe.hs > ./containers/Data/IntMap.hs > ./containers/Data/IntSet.hs > ./containers/Data/Map.hs > ./containers/Data/Sequence.hs > ./containers/Data/Set.hs > ./containers/Data/Tree.hs > ./haskell-src/Language/Haskell/Syntax.hs > ./network/Network/URI.hs > ./packedstring/Data/PackedString.hs > ./template-haskell/Language/Haskell/TH/Quote.hs > ./template-haskell/Language/Haskell/TH/Syntax.hs > > And here is a brief scan of what each of these is doing. References > to 'standard' vs 'dubious' Data instances are wrt the suggested split > in [1], with some possible refinements: > > - array: the Data instance for Array could be moved into array, > avoiding the need for instance imports and syb dependency? > > - bytestring: uses deriving, which for Internal.hs depends on > Data instances for Int [standard] and (ForeignPtr Word8) > [dubious]; would need to depend on syb; and import both > standard and dubious instances :-( > > perhaps Data instances for type constructors with phantom > types should be re-classified into Standard, given that there > are no data objects to be traversed? > > - containers: IntMap.hs, IntSet.hs, Map.hs, Sequencs.hs, Set.hs, > Tree.hs define their own Data instances, or derive them in such > a way that they do not need to import any instances :-) > > - haskell-src: uses deriving, will need to depend on syb; depends > almost exclusively on standard instances (the only exception I > can see in a quick scan is Rational); > > perhaps this is an argument in favour of moving the Data instance > for 'Ratio a' from Dubious to Standard: the parameter type is > never meant to be traversed, and tainting every client of 'Ratio a' > with the really bad instances is not a good idea. Opinions? > > - network: uses deriving, will need to depend on syb; depends > only on standard instances > > - packedstring: defines its own instances, no need to import any > > - template-haskell: uses deriving, roughly the same situation as > for haskell-src? > > Claus > > [1] see the last page of > http://www.haskell.org/pipermail/libraries/2008-July/010313.html > [2] http://www.cs.kent.ac.uk/~cr3/toolbox/haskell/#syb-utils > > > > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20080901/1adbdf16/attachment.htm From jed at 59A2.org Mon Sep 1 04:39:27 2008 From: jed at 59A2.org (Jed Brown) Date: Mon Sep 1 04:37:48 2008 Subject: Bugfix for QuickCheck 1.1.0.0 In-Reply-To: References: <4E804BD8-22DB-4EDF-AC29-900908603650@stanford.edu> <62E8F614-D0C2-46BA-AE22-FFE642C88585@stanford.edu> <90889fe70808311053h4e040b1k55c9e173822399df@mail.gmail.com> Message-ID: <20080901083927.GC11684@brakk.ethz.ch> On Sun 2008-08-31 11:19, Patrick Perry wrote: > In the old version, "split" gets called n times, so the run time is > O(n). For certain double values, variant gets called with n on the > order of 2^30, hence the hang in QuickCheck. The new version of variant > employs the same algorithm as in QuickCheck2. I haven't looked at this in a while but I'm not sure this completely fixes things with regard to coarbitrary. That is, we can produce very simple Doubles (as defined by arbitrary) that produce (via coarbitrary) very complicated generators for other types (and there was an issue of overflow with possible sign change due to nasty casting, hence variant getting a negative argument). As I understand it, your fix to variant means that variant will return in a reasonable amount of time even with a huge argument, but it doesn't fix the issue that coarbitrary should produce a `simple' generator for a `simple' argument. I thought QC2 had a mechanism to fix this. Jed -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20080901/beedfd9c/attachment-0001.bin From simonpj at microsoft.com Mon Sep 1 06:45:46 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Sep 1 06:44:02 2008 Subject: The base library and GHC 6.10 In-Reply-To: <52f14b210808312353g7a215815g3e65911f068c554e@mail.gmail.com> References: <20080828111232.GA15998@matrix.chaos.earth.li> <404396ef0808280428j5f8ce984q904f5f0e2b0e61ee@mail.gmail.com> <20080830120134.GA3741@matrix.chaos.earth.li> <20080831121055.GA5326@soi.city.ac.uk> <20080831121633.GA17919@matrix.chaos.earth.li> <52f14b210808312353g7a215815g3e65911f068c554e@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE8748DDB@EA-EXMSG-C334.europe.corp.microsoft.com> Let's think of what we are trying to achieve. Plan A: ? The class Data is defined in 'base' ? The SYB library builds on it ? Other libraries may build on it, independent of SYB Plan B: ? The class Data is defined in SYB ? Other libraries that want reflection-like facilities must build on SYB I think we were proposing to carry out Plan A. If so, then it would make sense for instances of Int, Maybe, tuples, etc to be in 'base' too; otherwise you have to import SYB anyway to get those instances. Claus says that "half the instances of Data are controversial". Is that really right Claus? Isn't it just functions and IO? My suggestion: ? Plan A ? Simple, obvious data instances (eg Bool, Maybe, lists) go in base ? A handful of controversial instances go in SYB This more or less what Ross suggested. Jose, should we be copying the 'generics' list? We need a chairperson for this discussion, to drive us to a timely conclusion. Jose: would you be willing to play that role? Simon From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Jos? Pedro Magalh?es Sent: 01 September 2008 07:54 To: libraries@haskell.org; Claus Reinke Subject: Re: The base library and GHC 6.10 Hello, This issue has been discussed before [1] and I got the impression all instances were going to be in the syb package and not in base. I think it's preferable to deal with the dubious instances issue [2] once SYB has been put into its own package, but maybe the "standard" instances could stay in base. Regarding the naming issue: I would very much be in favor of entirely renaming SYB to Generics.SYB altogether. I think the current name doesn't make much sense (why Data? it doesn't really define a datastructure), and simply calling it Generics is too broad, given that this is only one of the libraries for generic programming around. This would also fit nicely with other (upcoming) libraries for generic programming. Thanks, Pedro [1] http://thread.gmane.org/gmane.comp.lang.haskell.libraries/9738 [2] http://thread.gmane.org/gmane.comp.lang.haskell.libraries/9672 On Mon, Sep 1, 2008 at 00:02, Claus Reinke > wrote: Leaving Data.Generics.Basics in base while moving Data.Generics.Instances to syb raises the interesting issue of dealing with the accidental re-exports of Data.Generics.Instances from various places. Here is that list again (*): $ find . -name '*hs' | grep -v _darcs | xargs grep -l 'Data.Generics' | grep -v Generics ./array/Data/Array.hs ./base/Data/Typeable.hs ./bytestring/Data/ByteString/Internal.hs ./bytestring/Data/ByteString/Lazy/Internal.hs ./bytestring/Data/ByteString/Unsafe.hs ./containers/Data/IntMap.hs ./containers/Data/IntSet.hs ./containers/Data/Map.hs ./containers/Data/Sequence.hs ./containers/Data/Set.hs ./containers/Data/Tree.hs ./haskell-src/Language/Haskell/Syntax.hs ./network/Network/URI.hs ./packedstring/Data/PackedString.hs ./template-haskell/Language/Haskell/TH/Quote.hs ./template-haskell/Language/Haskell/TH/Syntax.hs And here is a brief scan of what each of these is doing. References to 'standard' vs 'dubious' Data instances are wrt the suggested split in [1], with some possible refinements: - array: the Data instance for Array could be moved into array, avoiding the need for instance imports and syb dependency? - bytestring: uses deriving, which for Internal.hs depends on Data instances for Int [standard] and (ForeignPtr Word8) [dubious]; would need to depend on syb; and import both standard and dubious instances :-( perhaps Data instances for type constructors with phantom types should be re-classified into Standard, given that there are no data objects to be traversed? - containers: IntMap.hs, IntSet.hs, Map.hs, Sequencs.hs, Set.hs, Tree.hs define their own Data instances, or derive them in such a way that they do not need to import any instances :-) - haskell-src: uses deriving, will need to depend on syb; depends almost exclusively on standard instances (the only exception I can see in a quick scan is Rational); perhaps this is an argument in favour of moving the Data instance for 'Ratio a' from Dubious to Standard: the parameter type is never meant to be traversed, and tainting every client of 'Ratio a' with the really bad instances is not a good idea. Opinions? - network: uses deriving, will need to depend on syb; depends only on standard instances - packedstring: defines its own instances, no need to import any - template-haskell: uses deriving, roughly the same situation as for haskell-src? Claus [1] see the last page of http://www.haskell.org/pipermail/libraries/2008-July/010313.html [2] http://www.cs.kent.ac.uk/~cr3/toolbox/haskell/#syb-utils _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20080901/e09eb91a/attachment.htm From claus.reinke at talk21.com Mon Sep 1 08:13:35 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Mon Sep 1 08:11:55 2008 Subject: The base library and GHC 6.10 References: <20080828111232.GA15998@matrix.chaos.earth.li><404396ef0808280428j5f8ce984q904f5f0e2b0e61ee@mail.gmail.com><20080830120134.GA3741@matrix.chaos.earth.li><20080831121055.GA5326@soi.city.ac.uk><20080831121633.GA17919@matrix.chaos.earth.li> <52f14b210808312353g7a215815g3e65911f068c554e@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE8748DDB@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <1782CAF73FFE4496B2D2616FE2FBEA7D@cr3lt> I thought class 'Data' was in 'Data.Generics.Basics' because it provides generic access to 'data'-definitions. SYB's generic programming library code (strategies for queries and transformations) builds on that, so does (one version of) Uniplate. Most other generic programming libraries are based on generic access to _type_ representations, the basics of which would more accurately appear somewhere in 'Types.Generics' - no conflict with SYB here. One could move the actual generic libraries into 'Generics.*', but until there is an actual need for that, I'd prefer things to stay stable, with libraries building on generic data access in 'Data.Generics' and libraries building on generic type access appearing in 'Types.Generics'. One could rename some of the SYB modules, eg, 'Data.Generics.Schemes' -> 'Data.Generics.SybSchemes' and so forth, but as long as other 'data'-based libraries are not deprived of namespace there, and other 'type'-based libraries either don't provide general traversal schemes or live in 'Types.Generics', there is no immediate need for such renaming, beyong putting the modules in a 'syb' package, is there? (note that 'Data.Typeable' is outside 'Data.Generics', though it is part of the basics that SYB depends on) > Claus says that "half the instances of Data are controversial". > Is that really right Claus? Isn't it just functions and IO? As an ideal, I'd like 'Data.Generics.Instances.Dubious' to be empty - 'Data' instances should either be standard, or not exist at all (at least not in library code). What I did was simply to take anything that looked dubious and move it into a separate module, to facilitate further discussion and more control over imports. The discussion I had hoped for didn't happen, so that is still were my code stands, but I do hope it isn't the final state. As for numbers, I currently have 32 instances in 'Data.Generics.Instances.Standard' and 11 instances in 'Data.Generics.Instances.Dubious' [1]. My initial split was mostly on the basis of 'gfold'/'gmapT' not traversing substructures, so some more of the 'Standard' instances are actually incomplete, and some of the 'Dubious' instances could possibly be declared "safe (with side conditions)", but then someone would still have to look at making the instances more complete/less certain to generate runtime errors. The current 'Dubious' list has things like - 'Ratio a': while values of type 'a' actually exist here, they are not meant to be visible in a concrete way, only via the abstract interface; and the abstract interface can support a 'data'-like view - various 'Ptr a': here the 'a' is a phantom type, there are no objects of type 'a' to be traversed; but neither is there much 'data'-like about these pointers.. - 'b->a', 'IO a', 'ST s a', 'STM a': these are thoroughly un-'data'-like; though the instances could be improved to provide transformation access to the 'a' values, the same doesn't work for queries, and the '(->)b' context is completely out of range for 'Data'. The current 'Standard' list has various instances that just bomb on some operations, including the 'Array a b' instance, which otherwise nicely demonstrates how to handle abstract types. Moving the more stable and standard 'Data' instances into base might not hinder development/debugging of the remaining instances, but right now, I don't think it will include sufficiently many instances to avoid dependencies on syb. As I explained in my previous email, the implicit presence of instances is itself a source of bugs, due to the propagation of instances in Haskell, not to mention ghc bug #2182. Since very few of the current 'Data' instance importers actually need those imports (they just happen to be included if one imports 'Data.Generics'), I'd prefer to remove the implicit imports (and implied re-exports), making the remaining real dependencies explicit by depending on syb (again, see previous email). I'd really like to see the real issues addressed before we start worrying about names, as this has turned out to be a rats nest of bugs, including: - incomplete 'Data' instances (operations that bomb now, but might be given better implementations) - incompleteable 'Data' instances (operations that cannot be implemented, suggesting that these instances shouldn't exist) - 'deriving Data' depending on 'Data' instances for everything, instead of skipping substructure types that cannot be handled anyway (smarter deriving could avoid dumb instances, by annotating types that should not be traversed instead of traversing these types via dummy instances that are then globally available/irreplaceable) - unneccessary 'Data' instance import/export (Data.IntMap has absolutely no business bringing 'instance Data (IO a)' into scope) - ghc sessions retaining instances (#2182), leading to build errors even in separate module hierarchies - ghc listing "orphan instances" as a performance issue, re-emphasized recently by warnings turned into errors, which has led some to believe they are a design fault, rather than a representation of a valid design decision - it doesn't help that Haskell doesn't support instance import/ export control (yes, the instances are unnamed, but naming class, type, and module would seem sufficient to block instance imports/exports where they are not wanted) Claus [1] http://www.cs.kent.ac.uk/~cr3/toolbox/haskell/#syb-utils 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:17 2008 Subject: 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/libraries/attachments/20080901/4de68177/attachment.htm From simonpj at microsoft.com Mon Sep 1 09:08:12 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Sep 1 09:06:28 2008 Subject: The base library and GHC 6.10 In-Reply-To: <1782CAF73FFE4496B2D2616FE2FBEA7D@cr3lt> References: <20080828111232.GA15998@matrix.chaos.earth.li><404396ef0808280428j5f8ce984q904f5f0e2b0e61ee@mail.gmail.com><20080830120134.GA3741@matrix.chaos.earth.li><20080831121055.GA5326@soi.city.ac.uk><20080831121633.GA17919@matrix.chaos.earth.li> <52f14b210808312353g7a215815g3e65911f068c554e@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE8748DDB@EA-EXMSG-C334.europe.corp.microsoft.com> <1782CAF73FFE4496B2D2616FE2FBEA7D@cr3lt> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE8748F46@EA-EXMSG-C334.europe.corp.microsoft.com> | I'd really like to see the real issues addressed before we start | worrying about names, as this has turned out to be a rats nest | of bugs, including: I'm all for addressing the real issues! But there are two time-frames involved a) In the next fortnight we must decide what stays in 'base' and what moves to the new 'syb' package. b) On a longer timescale, the 'syb' package maintainers can improve the library. The whole point of splitting syb out is to decouple (b) from (a). I'm currently focused on (a), because it is urgent, and this is the discussion that Jose is now kindly chairing. (b) remains important, but it is less urgent. Concerning the GHC-related parts of Claus's specific points: | - ghc sessions retaining instances (#2182), leading to build errors | even in separate module hierarchies Yes I agree this is bad, but I don't think I can fix it in time for 6.10; it's a consequence of an ill-made but fairly deeply wired in design choice. | - ghc listing "orphan instances" as a performance issue, | re-emphasized recently by warnings turned into errors, which | has led some to believe they are a design fault, rather than a | representation of a valid design decision They are not turned into errors. They are simply warnings. They only appear if you ask for them. If you use -Werror then they turn into errors, but then you asked for that! (The recent change is that previously they were second-class warnings that did not have this property.) Simon From ross at soi.city.ac.uk Mon Sep 1 10:43:00 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Sep 1 10:41:18 2008 Subject: Splitting SYB from the base package in GHC 6.10 In-Reply-To: <52f14b210809010549y4cd91ae8ue7916b3d8f0670ed@mail.gmail.com> References: <52f14b210809010549y4cd91ae8ue7916b3d8f0670ed@mail.gmail.com> Message-ID: <20080901144259.GA3507@soi.city.ac.uk> On Mon, Sep 01, 2008 at 02:49:01PM +0200, Jos? Pedro Magalh?es wrote: > 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. These two statements appear to be contradictory. Perhaps an example of a possible instance would help. In any case, it seems there's no objection to placing the following instances together with the Data class: () Bool Char Double Float Handle Ordering Int Int8 Int16 Int32 Int64 Integer Word Word8 Word16 Word32 Word64 DataType TyCon TypeRep [] Maybe Either tuples Claus also mentioned the Ptr/Var types, which also don't seem to have a value that can be traversed. I think the Ratio instance really ought to be in base, as Rational is in the Prelude. What about Complex? Claus argued that -> and the monads could be treated by analogy with Show for these types. 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. 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:15 2008 Subject: 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 11:11:33 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Mon Sep 1 11:09:54 2008 Subject: The base library and GHC 6.10 References: <20080828111232.GA15998@matrix.chaos.earth.li><404396ef0808280428j5f8ce984q904f5f0e2b0e61ee@mail.gmail.com><20080830120134.GA3741@matrix.chaos.earth.li><20080831121055.GA5326@soi.city.ac.uk><20080831121633.GA17919@matrix.chaos.earth.li> <52f14b210808312353g7a215815g3e65911f068c554e@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE8748DDB@EA-EXMSG-C334.europe.corp.microsoft.com> <1782CAF73FFE4496B2D2616FE2FBEA7D@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C32AE8748F46@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <286CE82CDA344FC3A250FBE7A0ED3DD8@cr3lt> >I'm all for addressing the real issues! But there are two time-frames involved >a) In the next fortnight we must decide what stays in 'base' and what moves to the new 'syb' >package. >b) On a longer timescale, the 'syb' package maintainers can improve the library. >The whole point of splitting syb out is to decouple (b) from (a). >I'm currently focused on (a), because it is urgent, and this is the discussion that Jose is >now kindly chairing. (b) remains important, but it is less urgent. understood and agreed. We just need to make sure that decoupling 'Data' from the decoupling of 'syb' doesn't ruin the intended decoupling!-) | - ghc sessions retaining instances (#2182), leading to build errors | even in separate module hierarchies >Yes I agree this is bad, but I don't think I can fix it in time for 6.10; >it's a consequence of an ill-made but fairly deeply wired in design choice. Just knowing whether you actually hope to do something about it, or whether it is so deeply ingrained that it can't be fixed, would help. | - ghc listing "orphan instances" as a performance issue, | re-emphasized recently by warnings turned into errors, which | has led some to believe they are a design fault, rather than a | representation of a valid design decision >They are not turned into errors. They are simply warnings. They >only appear if you ask for them. If you use -Werror then they turn >into errors, but then you asked for that! (The recent change is that >previously they were second-class warnings that did not have this property.) You have made your views quite clear in previous messages. Unfortunately, that doesn't keep others from drawing other conclusions, turning against any instance of orphans;-) Claus From simonpj at microsoft.com Mon Sep 1 12:45:36 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Sep 1 12:43:49 2008 Subject: The base library and GHC 6.10 In-Reply-To: <286CE82CDA344FC3A250FBE7A0ED3DD8@cr3lt> References: <20080828111232.GA15998@matrix.chaos.earth.li><404396ef0808280428j5f8ce984q904f5f0e2b0e61ee@mail.gmail.com><20080830120134.GA3741@matrix.chaos.earth.li><20080831121055.GA5326@soi.city.ac.uk><20080831121633.GA17919@matrix.chaos.earth.li> <52f14b210808312353g7a215815g3e65911f068c554e@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE8748DDB@EA-EXMSG-C334.europe.corp.microsoft.com> <1782CAF73FFE4496B2D2616FE2FBEA7D@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C32AE8748F46@EA-EXMSG-C334.europe.corp.microsoft.com> <286CE82CDA344FC3A250FBE7A0ED3DD8@cr3lt> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE8749103@EA-EXMSG-C334.europe.corp.microsoft.com> | | - ghc sessions retaining instances (#2182), leading to build errors | | even in separate module hierarchies | | >Yes I agree this is bad, but I don't think I can fix it in time for 6.10; | >it's a consequence of an ill-made but fairly deeply wired in design choice. | | Just knowing whether you actually hope to do something about it, | or whether it is so deeply ingrained that it can't be fixed, would help. Oh yes, it can definitely be fixed, and I fully intend to fix it. It just needs a little uninterrupted thought. Simon 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:03:03 2008 Subject: 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:37 2008 Subject: 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/libraries/attachments/20080901/0bb4da79/attachment.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:22:34 2008 Subject: 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/libraries/attachments/20080901/78632b33/attachment.htm From ashley at semantic.org Mon Sep 1 17:30:12 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Mon Sep 1 17:28:28 2008 Subject: The base library and GHC 6.10 In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE8748DDB@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20080828111232.GA15998@matrix.chaos.earth.li> <404396ef0808280428j5f8ce984q904f5f0e2b0e61ee@mail.gmail.com> <20080830120134.GA3741@matrix.chaos.earth.li> <20080831121055.GA5326@soi.city.ac.uk> <20080831121633.GA17919@matrix.chaos.earth.li> <52f14b210808312353g7a215815g3e65911f068c554e@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE8748DDB@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <48BC5EE4.1040305@semantic.org> Simon Peyton-Jones wrote: > Plan A: > ? The class Data is defined in ?base? > ? The SYB library builds on it > ? Other libraries may build on it, independent of SYB > > Plan B: > ? The class Data is defined in SYB > ? Other libraries that want reflection-like facilities must > build on SYB What about a new "introspection" package containing Typeable, Dynamic and Data? -- Ashley Yakeley 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:47 2008 Subject: 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 ashley at semantic.org Tue Sep 2 00:54:38 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Tue Sep 2 00:53:04 2008 Subject: ANN: unicode-properties 3.2.0.0, unicode-names 3.2.0.0 Message-ID: unicode-properties 3.2.0.0, unicode-names 3.2.0.0 These two packages are representations in Haskell of various data in the Unicode 3.2.0 Character Database. Unicode 3.2.0 was the latest version of the Unicode standard at the time I wrote most of the code; later I may move the packages to the latest version (currently 5.1.0). The unicode-properties package contains functions to determine general category, case, and a wide range of other properties, as well as to do decomposition and case-folding. The unicode-names package contains just one function, getCharacterName, for getting the name of a character. It's separated out because it's a sufficiently large proportion of the total data. Both packages use the type "Char" to represent Unicode characters (more pedantically, codepoints). In GHC Char has the range ['\x0'..'\x10FFFF'], matching the Unicode standard. The packages won't work with compilers that restrict Char to a smaller range. Hackage: Source for both packages: Most of the data is auto-generated at build time from files downloadable from the Unicode web-site. I expect Don will have them both in Arch Linux within the hour. -- Ashley Yakeley From dons at galois.com Tue Sep 2 01:02:26 2008 From: dons at galois.com (Don Stewart) Date: Tue Sep 2 01:00:34 2008 Subject: ANN: unicode-properties 3.2.0.0, unicode-names 3.2.0.0 In-Reply-To: References: Message-ID: <20080902050226.GF29572@scytale.galois.com> ashley: > unicode-properties 3.2.0.0, unicode-names 3.2.0.0 > > These two packages are representations in Haskell of various data in the > Unicode 3.2.0 Character Database. Unicode 3.2.0 was the latest version > of the Unicode standard at the time I wrote most of the code; later I > may move the packages to the latest version (currently 5.1.0). Arch Linux native packages available, http://aur.archlinux.org/packages.php?ID=19528 http://aur.archlinux.org/packages.php?ID=19527 Come on Debian, we need you! -- Don From allbery at ece.cmu.edu Tue Sep 2 01:08:40 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Sep 2 01:07:11 2008 Subject: ANN: unicode-properties 3.2.0.0, unicode-names 3.2.0.0 In-Reply-To: References: Message-ID: <23D179EC-BDC4-4F74-B1F3-0630724ED350@ece.cmu.edu> On 2008 Sep 2, at 0:54, Ashley Yakeley wrote: > Both packages use the type "Char" to represent Unicode characters > (more pedantically, codepoints). In GHC Char has the range > ['\x0'..'\x10FFFF'], matching the Unicode standard. The packages > won't work with compilers that restrict Char to a smaller range. Hm. Are there any? I thought Unicode was required by H98. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From patperry at stanford.edu Tue Sep 2 01:36:27 2008 From: patperry at stanford.edu (Patrick Perry) Date: Tue Sep 2 01:34:43 2008 Subject: Bugfix for QuickCheck 1.1.0.0 Message-ID: Two things: First, the version of variant I gave will behave reasonably if given a negative argument, so the overflow is not catastrophic. Second, I'm not sure what you mean by a "simple" generator. Let's consider Int instead of Double. With the current version of variant, "coarbitrary 1" calls split one time, and "coarbitrary 1000" calls split 1000 times. At the end of the day, though, all random number generators are equally "complex". The only difference is that they have different seeds. You are correct the QuickCheck2 uses "toRational" instead of "decodeFlloat" for the coarbitrary instance. I don't think it matters either way which one gets used, though, and I would rather change as little code as possible in QuickCheck1. Patrick Jed Brown wrote: > I haven't looked at this in a while but I'm not sure this completely > fixes things with regard to coarbitrary. That is, we can produce very > simple Doubles (as defined by arbitrary) that produce (via > coarbitrary) > very complicated generators for other types (and there was an issue of > overflow with possible sign change due to nasty casting, hence variant > getting a negative argument). As I understand it, your fix to variant > means that variant will return in a reasonable amount of time even > with > a huge argument, but it doesn't fix the issue that coarbitrary should > produce a `simple' generator for a `simple' argument. I thought QC2 > had > a mechanism to fix this. > From ross at soi.city.ac.uk Tue Sep 2 04:26:30 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Sep 2 04:24:46 2008 Subject: ANN: unicode-properties 3.2.0.0, unicode-names 3.2.0.0 In-Reply-To: References: Message-ID: <20080902082630.GA12956@soi.city.ac.uk> On Mon, Sep 01, 2008 at 09:54:38PM -0700, Ashley Yakeley wrote: > These two packages are representations in Haskell of various data in the > Unicode 3.2.0 Character Database. Unicode 3.2.0 was the latest version > of the Unicode standard at the time I wrote most of the code; later I > may move the packages to the latest version (currently 5.1.0). > > The unicode-properties package contains functions to determine general > category, case, and a wide range of other properties, as well as to do > decomposition and case-folding. > > The unicode-names package contains just one function, getCharacterName, > for getting the name of a character. It's separated out because it's a > sufficiently large proportion of the total data. On a minor point, it would probably be better to avoid prefixing names of constants (e.g. DCVertical). Also, the prefix "get" is usually reserved for functions that have a monadic effect, so names like decomposition :: Char -> Decomposition would be more usual than getDecomposition. Note that Data.Char already has functions generalCategory, toUpper, toLower and toTitle, which should work on the full range. It should probably have majorClass as well. From jed at 59A2.org Tue Sep 2 05:14:06 2008 From: jed at 59A2.org (Jed Brown) Date: Tue Sep 2 05:12:24 2008 Subject: Bugfix for QuickCheck 1.1.0.0 In-Reply-To: References: Message-ID: <20080902091406.GF11684@brakk.ethz.ch> On Mon 2008-09-01 22:36, Patrick Perry wrote: > Second, I'm not sure what you mean by a "simple" generator. Let's > consider Int instead of Double. With the current version of variant, > "coarbitrary 1" calls split one time, and "coarbitrary 1000" calls split > 1000 times. At the end of the day, though, all random number generators > are equally "complex". The only difference is that they have different > seeds. The idea with QC is that you start with `simple' random input and progress to more `complicated' input. If say, you are testing a function that builds a list with length equal to the output of the QC-generated function (Double->Int) (with positive precondition) you could be building a huge list very early. This wouldn't happen with other types since `simple' QC-generated functions for, say, (Int->Int) will map small integers to small integers. Jed -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20080902/6e7626c2/attachment.bin From ashley at semantic.org Tue Sep 2 05:51:45 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Tue Sep 2 05:49:58 2008 Subject: ANN: unicode-properties 3.2.0.0, unicode-names 3.2.0.0 In-Reply-To: <20080902082630.GA12956@soi.city.ac.uk> References: <20080902082630.GA12956@soi.city.ac.uk> Message-ID: <48BD0CB1.30802@semantic.org> Ross Paterson wrote: > Note that Data.Char already has functions generalCategory, toUpper, > toLower and toTitle, which should work on the full range. It depends on whether libunicode is installed at the time GHC is built. You _might_ get some version of Unicode, or you might get ISO Latin-1 case folding instead. -- Ashley Yakeley From ross at soi.city.ac.uk Tue Sep 2 06:10:21 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Sep 2 06:08:36 2008 Subject: ANN: unicode-properties 3.2.0.0, unicode-names 3.2.0.0 In-Reply-To: <48BD0CB1.30802@semantic.org> References: <20080902082630.GA12956@soi.city.ac.uk> <48BD0CB1.30802@semantic.org> Message-ID: <20080902101021.GB12956@soi.city.ac.uk> On Tue, Sep 02, 2008 at 02:51:45AM -0700, Ashley Yakeley wrote: > Ross Paterson wrote: >> Note that Data.Char already has functions generalCategory, toUpper, >> toLower and toTitle, which should work on the full range. > > It depends on whether libunicode is installed at the time GHC is built. > You _might_ get some version of Unicode, or you might get ISO Latin-1 > case folding instead. No, it's OS-independent and doesn't use libunicode. The implementation of these four functions in cbits/WCsubst.c is generated from UnicodeData.txt. 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:29 2008 Subject: 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/libraries/attachments/20080902/6bee1806/attachment-0001.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:56 2008 Subject: 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/libraries/attachments/20080902/ff5b0504/attachment.htm From igloo at earth.li Tue Sep 2 08:35:23 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Sep 2 08:33:37 2008 Subject: Splitting SYB from the base package in GHC 6.10 In-Reply-To: <52f14b210809010549y4cd91ae8ue7916b3d8f0670ed@mail.gmail.com> References: <52f14b210809010549y4cd91ae8ue7916b3d8f0670ed@mail.gmail.com> Message-ID: <20080902123523.GA18657@matrix.chaos.earth.li> On Mon, Sep 01, 2008 at 02:49:01PM +0200, Jos? Pedro Magalh?es wrote: > > with the "dubious" Data instances FWIW, I don't believe in "dubious" instances. There are two reasons one might want to not have an instance: * You want to use a different instance for the same type, e.g. you want the (Ratio t) instance to descend into the t rather than just treating the type abstractly. This sounds nice in theory, but it is flawed in practice. Instances are global in Haskell, so if one library needs Ratio instance 1, and another library needs Ratio instance 2, then those libraries cannot be used in the same program. * You don't want to actually use Data with that type, and you want the compiler to tell you if a bug in your code means that the instance would be used ("Can't find instance Data (IO a)"). However, in my (admittedly not vast) experience, this isn't a problem that tends to crop up in practice. Also, note that the presence of these instances doesn't affect correct programs. Also, I've just spent a couple of minutes staring at the SYB and SBY-With-Class Data classes; am I right in thinking that neither can be implemented on top of the other? Here's part of the classes: ------------------------------------------------ {-# LANGUAGE UndecidableInstances, OverlappingInstances, FlexibleInstances, MultiParamTypeClasses, Rank2Types, ScopedTypeVariables, EmptyDataDecls, KindSignatures #-} import Data.Typeable class Typeable a => Data1 a where gfoldl1 :: (forall b c. Data1 b => w (b -> c) -> b -> w c) -> (forall g. g -> w g) -> a -> w a class (Typeable a, Sat (ctx a)) => Data2 ctx a where gfoldl2 :: Proxy ctx -> (forall b c. Data2 ctx b => w (b -> c) -> b -> w c) -> (forall g. g -> w g) -> a -> w a data Proxy (a :: * -> *) class Sat a where dict :: a ------------------------------------------------ Could uniplate etc have been built on top of SYBWC's Data, instead of SYB's Data? Is SYB's Data the basic building block only because there are more instances for it in the wild, and GHC can derive them? Thanks Ian From igloo at earth.li Tue Sep 2 08:54:40 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Sep 2 08:52:54 2008 Subject: The base library and GHC 6.10 In-Reply-To: <20080828111232.GA15998@matrix.chaos.earth.li> References: <20080828111232.GA15998@matrix.chaos.earth.li> Message-ID: <20080902125440.GA20497@matrix.chaos.earth.li> On Thu, Aug 28, 2008 at 12:12:32PM +0100, Ian Lynagh wrote: > > We're trying to decide what to do with the base library for GHC 6.10, in > terms of how much of it should be broken up into separate packages. > Since the recent proposal about this, we may be rethinking what we want > to do, and we would welcome your opinions. The decision is to split syb out from base (some details still being discussed) and leave the getopt st concurrent, timout and unique modules in base for GHC 6.10. Thanks Ian From noteed at gmail.com Tue Sep 2 11:21:33 2008 From: noteed at gmail.com (minh thu) Date: Tue Sep 2 11:19:45 2008 Subject: cabal use questions Message-ID: <40a414c20809020821i27068c57s64f1954d43b83686@mail.gmail.com> Hi, I've some questions related to Cabal. The command "ghc-pkg list" reports two versions of Cabal : 1.2.4.0 and 1.4.0.2. How do I get rid of the first one ? Also, I try to build a Cabal package of my own but configuring it doen't work : $ runhaskell Setup.lhs configure Configuring ae-fast-0.1... Setup.lhs: At least the following dependencies are missing: GLUT -any, OpenGL -an I have the OpenGL and GLUT packages (doing :m + them in ghci works). I run the configure command in this directory : $ ls ae-fast.cabal Graphics LICENSE Setup.lhs $ cat ae-fast.cabal name: ae-fast version: 0.1 Cabal-Version: >= 1.2 synopsis: Miscellaneous stuffs to easily try new ideas description: Miscellaneous stuffs to easily try new ideas category: Graphics license: BSD3 license-file: LICENSE author: Vo Minh Thu maintainer: Vo Minh Thu build-type: Simple Library Build-Depends: base, OpenGL, GLUT Exposed-Modules: Graphics.AE.Fast.GLUT What's wrong ? Thank you, Thu From bart at cs.pdx.edu Tue Sep 2 11:59:49 2008 From: bart at cs.pdx.edu (Bart Massey) Date: Tue Sep 2 11:58:21 2008 Subject: Splitting SYB from the base package in GHC 6.10 References: <52f14b210809010549y4cd91ae8ue7916b3d8f0670ed@mail.gmail.com> <20080902123523.GA18657@matrix.chaos.earth.li> Message-ID: Ian Lynagh earth.li> writes: > * You want to use a different instance for the same type. > > Instances are global in Haskell, so if one library needs Ratio instance 1, > and another library needs Ratio instance 2, then those libraries cannot be > used in the same program. For me it's not so much about the libraries. I've run into cases (not in SYB) where I want my program to use a different definition of an instance than the one provided by a library, while still using the other stuff provided by that library. The pervasive globality of instances does seem to me to be a Haskell bug; it seems to me like they ought to be controlled using the same module export control rules as anything else. But I imagine there's some reason I don't understand that makes this hard or impossible... From patperry at stanford.edu Tue Sep 2 12:46:36 2008 From: patperry at stanford.edu (Patrick Perry) Date: Tue Sep 2 12:44:51 2008 Subject: Bugfix for QuickCheck 1.1.0.0 Message-ID: Jed Brown wrote: > The idea with QC is that you start with `simple' random input and > progress to more `complicated' input. If say, you are testing a > function that builds a list with length equal to the output of the > QC-generated function (Double->Int) (with positive precondition) you > could be building a huge list very early. This wouldn't happen with > other types since `simple' QC-generated functions for, say, (Int->Int) > will map small integers to small integers. I don't think this has anything to do with the definition of coarbitrary. As I understand things: coarbitrary is a function of type x -> StdGen arbitrary is a function of type StdGen -> Int -> x For the type "x -> y", arbitrary is equal to \g n -> (\x -> let g' = coarbitrary x in arbitrary g' n) I did an experiment in QC1 (with patch). Here are two properties: prop_f (f :: Double -> Int) x = trace (show $ f x) True prop_g (f :: Int -> Int) x = trace (show $ f x) True Below is the output. Do you think that one is "more simple" than the other? Patrick 1 0 2 -2 0 0 0 0 2 -3 00 11 -3 -5 -9 05 06 17 -5 49 30 -1 -1 33 -8 -4 66 27 78 09 60 01 -8 83 -12 35 -4 13 38 -1 -4 -1 02 -10 -3 45 06 -10 -12 -4 20 -7 -18 -2 84 -10 -2 13 38 29 60 -6 12 20 -12 95 -8 -22 58 49 90 -12 12 -12 -1 -1 -14 -14 27 -1 00 01 -16 23 54 25 24 -15 48 14 -10 -37 02 -19 84 17 -15 -19 -1 42 -3 1 -3 1 3 -3 -4 -4 -2 -3 10 -1 02 43 14 05 -1 07 18 -1 -3 21 -4 -5 34 25 -1 17 18 -8 -4 31 13 53 64 95 06 27 -2 -6 60 10 72 -2 -3 45 36 -9 16 39 -4 01 27 -3 -22 -7 -4 -14 -1 -6 -8 -1 -23 -13 14 45 -24 17 -1 49 -5 25 -13 11 44 05 26 12 -12 -33 00 11 27 93 35 25 -3 -6 98 -12 -20 10 -11 43 34 12 -43 17 -3 09 From dave at zednenem.com Tue Sep 2 13:27:34 2008 From: dave at zednenem.com (David Menendez) Date: Tue Sep 2 13:25:45 2008 Subject: Splitting SYB from the base package in GHC 6.10 In-Reply-To: References: <52f14b210809010549y4cd91ae8ue7916b3d8f0670ed@mail.gmail.com> <20080902123523.GA18657@matrix.chaos.earth.li> Message-ID: <49a77b7a0809021027o7f53c9fal882e81d03bc661f3@mail.gmail.com> On Tue, Sep 2, 2008 at 11:59 AM, Bart Massey wrote: > Ian Lynagh earth.li> writes: >> * You want to use a different instance for the same type. >> >> Instances are global in Haskell, so if one library needs Ratio instance 1, >> and another library needs Ratio instance 2, then those libraries cannot be >> used in the same program. > > For me it's not so much about the libraries. I've run into cases (not in SYB) > where I want my program to use a different definition of an instance than the > one provided by a library, while still using the other stuff provided by that > library. > > The pervasive globality of instances does seem to me to be a Haskell bug; it > seems to me like they ought to be controlled using the same module export > control rules as anything else. But I imagine there's some reason I don't > understand that makes this hard or impossible... I think there are some guarantees made by the type system that aren't valid if class instances aren't global, but I can't remember the details. More practically, there is more than one way of implementing classes: dictionary passing, partial evaluation (see "Dictionary-free overloading by partial evaluation" by Mark Jones), and explicit type parameters (used by JHC). The latter two enable optimizations that are not possible with dictionary passing, but only work if instances are global. -- Dave Menendez From pgavin at gmail.com Tue Sep 2 13:31:31 2008 From: pgavin at gmail.com (Peter Gavin) Date: Tue Sep 2 13:29:47 2008 Subject: cabal use questions In-Reply-To: <40a414c20809020821i27068c57s64f1954d43b83686@mail.gmail.com> References: <40a414c20809020821i27068c57s64f1954d43b83686@mail.gmail.com> Message-ID: <48BD7873.6060804@gmail.com> minh thu wrote: > Hi, > > I've some questions related to Cabal. > > The command "ghc-pkg list" reports two versions of > Cabal : 1.2.4.0 and 1.4.0.2. > > How do I get rid of the first one ? You don't. The first one is the one that came with GHC, probably. The other I'm assuming you installed yourself. If you try to remove the first one, I think GHC will probably break. > > Also, I try to build a Cabal package of my own > but configuring it doen't work : > > $ runhaskell Setup.lhs configure > Configuring ae-fast-0.1... > Setup.lhs: At least the following dependencies are missing: > GLUT -any, OpenGL -an > Try: $ runhaskell Setup.lhs configure --user If you've installed the OpenGL and GLUT package with --user, any packages that use them will have to be configured with --user as well. If you do ghc-pkg list, it will tell you which packages are installed just for your user, and which are installed globally. > I have the OpenGL and GLUT packages (doing :m + them in ghci works). > > I run the configure command in this directory : > $ ls > ae-fast.cabal Graphics LICENSE Setup.lhs > > $ cat ae-fast.cabal > name: ae-fast > version: 0.1 > Cabal-Version: >= 1.2 > synopsis: Miscellaneous stuffs to easily try new ideas > description: Miscellaneous stuffs to easily try new ideas > category: Graphics > license: BSD3 > license-file: LICENSE > author: Vo Minh Thu > maintainer: Vo Minh Thu > build-type: Simple > > Library > Build-Depends: base, OpenGL, GLUT > Exposed-Modules: Graphics.AE.Fast.GLUT > Your cabal file looks fine. Pete > What's wrong ? > Thank you, > Thu > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries From jonathanccast at fastmail.fm Tue Sep 2 13:40:43 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Tue Sep 2 13:43:06 2008 Subject: Splitting SYB from the base package in GHC 6.10 In-Reply-To: <49a77b7a0809021027o7f53c9fal882e81d03bc661f3@mail.gmail.com> References: <52f14b210809010549y4cd91ae8ue7916b3d8f0670ed@mail.gmail.com> <20080902123523.GA18657@matrix.chaos.earth.li> <49a77b7a0809021027o7f53c9fal882e81d03bc661f3@mail.gmail.com> Message-ID: <1220377244.12473.39.camel@jcchost> > On Tue, Sep 2, 2008 at 11:59 AM, Bart Massey wrote: > > Ian Lynagh earth.li> writes: > >> * You want to use a different instance for the same type. > >> > >> Instances are global in Haskell, so if one library needs Ratio instance 1, > >> and another library needs Ratio instance 2, then those libraries cannot be > >> used in the same program. > > > > For me it's not so much about the libraries. I've run into cases (not in SYB) > > where I want my program to use a different definition of an instance than the > > one provided by a library, while still using the other stuff provided by that > > library. > > > > The pervasive globality of instances does seem to me to be a Haskell bug; it > > seems to me like they ought to be controlled using the same module export > > control rules as anything else. But I imagine there's some reason I don't > > understand that makes this hard or impossible... I missed this the first time around, but consider the following case (I ran into this specific issue trying to formulate arithmetic using first-class modules and implicits): class Multiplication alpha beta where type Product alpha beta (*) :: alpha -> beta -> Product alpha beta class AdditiveGroup alpha where zero :: alpha (+) :: alpha -> alpha -> alpha (-) :: alpha -> alpha -> alpha class (AdditiveGroup alpha, Multiplication alpha alpha, Product alpha alpha ~ alpha) => Field alpha where one :: alpha (/) :: alpha -> alpha -> alpha class (AdditiveGroup vector, Field scalar, Multiplication scalar vector, Product scalar vector ~ vector) => VectorSpace scalar vector And consider the definition multiply :: VectorSpace scalar scalar => scalar -> scalar -> scalar multiply = (*) VectorSpace scalar scalar has two Multiplication scalar scalar super-classes: one direct, and one inherited from Field. With type classes, this isn't a problem, because the program can only contain one instance of Multiplication scalar scalar anyway (for fixed scalar), so any instance must of VectorSpace scalar scalar necessarily picks up only one definition of (*). If you had named instances, and relaxed that uniqueness constraint, I'm not even sure how you'd express that when you needed it here. jcc From jed at 59A2.org Tue Sep 2 13:52:32 2008 From: jed at 59A2.org (Jed Brown) Date: Tue Sep 2 13:50:46 2008 Subject: Bugfix for QuickCheck 1.1.0.0 In-Reply-To: References: Message-ID: <20080902175232.GH11684@brakk.ethz.ch> On Tue 2008-09-02 09:46, Patrick Perry wrote: > > Jed Brown wrote: >> The idea with QC is that you start with `simple' random input and >> progress to more `complicated' input. If say, you are testing a >> function that builds a list with length equal to the output of the >> QC-generated function (Double->Int) (with positive precondition) you >> could be building a huge list very early. This wouldn't happen with >> other types since `simple' QC-generated functions for, say, (Int->Int) >> will map small integers to small integers. > > I don't think this has anything to do with the definition of > coarbitrary. As I understand things: > coarbitrary is a function of type x -> StdGen > arbitrary is a function of type StdGen -> Int -> x > For the type "x -> y", arbitrary is equal to > \g n -> (\x -> let g' = coarbitrary x in arbitrary g' n) > > I did an experiment in QC1 (with patch). Here are two properties: > prop_f (f :: Double -> Int) x = trace (show $ f x) True > prop_g (f :: Int -> Int) x = trace (show $ f x) True > > Below is the output. Do you think that one is "more simple" than the > other? Hmm, I guess I should have run the test before speculating. It looks like the logarithmic factor keeps it all in control. Jed -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20080902/bc3df45f/attachment.bin From noteed at gmail.com Tue Sep 2 13:55:13 2008 From: noteed at gmail.com (minh thu) Date: Tue Sep 2 13:53:26 2008 Subject: cabal use questions In-Reply-To: <48BD7873.6060804@gmail.com> References: <40a414c20809020821i27068c57s64f1954d43b83686@mail.gmail.com> <48BD7873.6060804@gmail.com> Message-ID: <40a414c20809021055xf836aa1qa17c5bd6d8b8eec1@mail.gmail.com> 2008/9/2 Peter Gavin : > minh thu wrote: >> >> Hi, >> >> I've some questions related to Cabal. >> >> The command "ghc-pkg list" reports two versions of >> Cabal : 1.2.4.0 and 1.4.0.2. >> >> How do I get rid of the first one ? > > You don't. The first one is the one that came with GHC, probably. The > other I'm assuming you installed yourself. If you try to remove the first > one, I think GHC will probably break. OK. >> Also, I try to build a Cabal package of my own >> but configuring it doen't work : >> >> $ runhaskell Setup.lhs configure >> Configuring ae-fast-0.1... >> Setup.lhs: At least the following dependencies are missing: >> GLUT -any, OpenGL -an >> > > Try: > > $ runhaskell Setup.lhs configure --user Ok, it works. But I didn't installed GLUT or OpenGL that way... Thank you, Thu From jpm at cs.uu.nl Tue Sep 2 14:45:32 2008 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Tue Sep 2 14:43:46 2008 Subject: Splitting SYB from the base package in GHC 6.10 In-Reply-To: References: <52f14b210809010549y4cd91ae8ue7916b3d8f0670ed@mail.gmail.com> <20080902123523.GA18657@matrix.chaos.earth.li> Message-ID: <52f14b210809021145y5e667093m3d80290be2504b4c@mail.gmail.com> Hello, On Tue, Sep 2, 2008 at 14:35, Ian Lynagh wrote: > FWIW, I don't believe in "dubious" instances. > Indeed not changing the instances is definitely still an option. Maybe it's best, for now, to focus on choosing a splitting solution which allows for all possible flexibility in the future development of SYB. After 6.10 is out, we then have all the proposed changes to SYB (including the dubious instances issue) analized and discussed before making the changes. I find Simon PJ's argument for keeping Data in base ("so that others can build on it without depending on the full glory of SYB") rather strong, and I guess any "interesting" change to the Data class would require a change in the internal deriving mechanism. I'm not saying that Data is perfect and should not be changed, but maybe it can be in base without fundamentally diminishing the oportunites for development in SYB. Do you agree with me, Claus? Also, I've just spent a couple of minutes staring at the SYB and > SBY-With-Class Data classes; am I right in thinking that neither can be > implemented on top of the other? > I believe that is the case. syb-with-class is generally interpreted as another library for generic programming. Their interfaces differ (namely because syb-with-class requires abstraction over type classes, and since this is not possible it uses some trick). Could uniplate etc have been built on top of SYBWC's Data, instead of > SYB's Data? Is SYB's Data the basic building block only because there > are more instances for it in the wild, and GHC can derive them? I guess it could, but that would have implications on its usability. I guess SYB's Data is seen as a basic building block for generics because it's easy to use (and the automatic derivation plays a big role on that). Plus, it comes with GHC. A recent report compares various libraries for generic programming in Haskell and their expressiveness [1]. Thanks, Pedro [1] http://www.cs.uu.nl/research/techreps/repo/CS-2008/2008-010.pdf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20080902/33ebb4c8/attachment.htm From claus.reinke at talk21.com Tue Sep 2 16:46:09 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Tue Sep 2 16:44:27 2008 Subject: Splitting SYB from the base package in GHC 6.10 References: <52f14b210809010549y4cd91ae8ue7916b3d8f0670ed@mail.gmail.com> <20080902123523.GA18657@matrix.chaos.earth.li> <52f14b210809021145y5e667093m3d80290be2504b4c@mail.gmail.com> Message-ID: <1C4AE74FD8C843B1AAC9D92AE067F090@cr3lt> > Indeed not changing the instances is definitely still an option. Maybe it's > best, for now, to focus on choosing a splitting solution which allows for > all possible flexibility in the future development of SYB. After 6.10 is > out, we then have all the proposed changes to SYB (including the dubious > instances issue) analized and discussed before making the changes. > > I find Simon PJ's argument for keeping Data in base ("so that others can > build on it without depending on the full glory of SYB") rather strong, and > I guess any "interesting" change to the Data class would require a change in > the internal deriving mechanism. I'm not saying that Data is perfect and > should not be changed, but maybe it can be in base without fundamentally > diminishing the oportunites for development in SYB. Do you agree with me, > Claus? I find it curious to see you ask that question, as I've spent quite a bit of time answering it, and providing information needed to prepare a workable plan. Strangely, I had assumed you'd actually use that material to help you understand the issues involved in any decision made now. But my question haven't been answered, and now you simply repeat your question without reference to my previous answers and suggestions (have you tried playing with 'syb-utils', to see how a trying to fix the instance issues in a separate package on top of 'base' would work, or not?). Instead of repeating myself in full, I'd prefer you'd refer to my previous emails (ask if they were unclear), but here is the gist of it (with no claim of completeness): 0 if 'Data' stays in 'base', and the types are in 'base' there is no good reason for the instances to be elsewhere, right? (personally, I still like Ashley's suggestion of putting 'Data', 'Typeable' and 'Dynamic' in a separate package) 1 'base' traditionally cannot be updated between ghc releases. I asked whether that had changed, because otherwise leaving anything in 'base' will keep you from changing it. So if the technical limitations fixing 'base' are not gone, your adventure ends right there. 2 the "standard"/"dubious" separation of instances was entirely preliminary; following the recent discussion, I would suggest to split the instances into three groups, in three separate modules: [standard]: fully implemented 'Data' instances (no runtime errors). one should probably reclassify 'Ratio a' in here. [partial]: partially implemented instances (usually for abstract types, which 'Data' doesn't handle well; whether that can be mended without changing the class remains to be seen); these include 'Array a b', 'ThreadId', etc (previously in 'Standard') and the pointer types (previously in 'Dubious'); if these instances can be completed, existing clients will simply work better (fewer runtime crashes) [misfits]: 'IO a', 'b -> a', and other types that enclose a substructure type in a contravariant context ("realworld", "b", "state", etc); not only are the existing 'Data' instances incomplete, they skip substructures on both transformations and queries, and the type of query operators in 'Data' simply does not permit a complete implementation of substructure queries for these types (I think), so these instances are fairly hopeless at the moment, and should only be available if explicitly requested. 3 if the implicit re-export of misfit instances from 'Data.Generic*' isn't stopped now, any attempt to fix 'syb' is doomed (until the next ghc release). unless anyone wants to claim that it is technically possible to implement complete 'Data' instances for these types (in which case I'm all ears;-), the existing incomplete instances should not be available by default (requiring a specific import instead). I'd prefer the other partial instances also to be under explicit import only, so that noone can run into runtime crashes without having been warned (just because they use 'gunfold' instead of 'gfold', say, and happen to work with arrays instead of lists), but it seems I'm in the minority on this point. 4 even after providing selective import of non-standard instances, the existing importers of 'Data.Generic*' in core and extra libs need to be cleaned up now, so that they only import (and thus re-export) the miminum set of instances they depend on (in particular, no misfits); again, failure to do that now will doom any attempt to fix the 'syb' instances later. If the misfit instances are moved out of 'Data.Generic.Instances' into a module not imported anywhere else, while the other partial instances remain, no changes might be needed to the existing 'Data.Generics*' importers, but that needs to be checked. I have no idea whether these would give you sufficient flexibility to work on 'syb' after the ghc release, but I'm pretty sure that they are part of the necessary minimum of issues that need to be addressed now. Even after working around #2182, you can observe the issues when using my 'syb-utils' package, eg, the 'Data.Generics.GPS' module uses 'Data.IntMap', so it accidentally re-exports all the old instances, even though it carefully avoids importing them itself. If it wasn't for #2356, that would never work (and if you happen to import 'Data.Generics.GPS' before importing 'Data.Generics.Instances.*', instead, it still might not, at least while building the package). Claus PS I'll update my 'syb-utils' package to reflect the new instance split, as given in 2 above. From igloo at earth.li Tue Sep 2 17:06:37 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Sep 2 17:04:49 2008 Subject: Splitting SYB from the base package in GHC 6.10 In-Reply-To: <1C4AE74FD8C843B1AAC9D92AE067F090@cr3lt> References: <52f14b210809010549y4cd91ae8ue7916b3d8f0670ed@mail.gmail.com> <20080902123523.GA18657@matrix.chaos.earth.li> <52f14b210809021145y5e667093m3d80290be2504b4c@mail.gmail.com> <1C4AE74FD8C843B1AAC9D92AE067F090@cr3lt> Message-ID: <20080902210637.GA7519@matrix.chaos.earth.li> On Tue, Sep 02, 2008 at 09:46:09PM +0100, Claus Reinke wrote: > > I have no idea whether these would give you sufficient flexibility to > work on 'syb' after the ghc release I think I've missed something: What is the work that can't be done before the instances are moved? Thanks Ian From bulat.ziganshin at gmail.com Tue Sep 2 18:01:48 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Sep 2 18:04:00 2008 Subject: Splitting SYB from the base package in GHC 6.10 In-Reply-To: <1C4AE74FD8C843B1AAC9D92AE067F090@cr3lt> References: <52f14b210809010549y4cd91ae8ue7916b3d8f0670ed@mail.gmail.com> <20080902123523.GA18657@matrix.chaos.earth.li> <52f14b210809021145y5e667093m3d80290be2504b4c@mail.gmail.com> <1C4AE74FD8C843B1AAC9D92AE067F090@cr3lt> Message-ID: <502709682.20080903020148@gmail.com> Hello Claus, Wednesday, September 3, 2008, 12:46:09 AM, you wrote: > (personally, I still like Ashley's suggestion of putting 'Data', 'Typeable' > and 'Dynamic' in a separate package) it looks like a good idea. we don't need Data in the base, just in some core library (i.e. library definitely installed with ghc) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From ross at soi.city.ac.uk Tue Sep 2 18:21:10 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Sep 2 18:19:25 2008 Subject: Splitting SYB from the base package in GHC 6.10 In-Reply-To: <1C4AE74FD8C843B1AAC9D92AE067F090@cr3lt> References: <52f14b210809010549y4cd91ae8ue7916b3d8f0670ed@mail.gmail.com> <20080902123523.GA18657@matrix.chaos.earth.li> <52f14b210809021145y5e667093m3d80290be2504b4c@mail.gmail.com> <1C4AE74FD8C843B1AAC9D92AE067F090@cr3lt> Message-ID: <20080902222110.GA6365@soi.city.ac.uk> On Tue, Sep 02, 2008 at 09:46:09PM +0100, Claus Reinke wrote: > 2 the "standard"/"dubious" separation of instances was entirely preliminary; > following the recent discussion, I would suggest to split the > instances into three groups, in three separate modules: > > [standard]: fully implemented 'Data' instances (no runtime errors). > one should probably reclassify 'Ratio a' in here. > > [partial]: partially implemented instances (usually for abstract > types, which 'Data' doesn't handle well; whether > that can be mended without changing the class > remains to be seen); these include 'Array a b', > 'ThreadId', etc (previously in 'Standard') and the > pointer types (previously in 'Dubious'); if these > instances can be completed, existing clients will > simply work better (fewer runtime crashes) If the Data class, your [standard] instances (including Ratio and Complex) and the instances for FFI pointer types are in base, then the packages you listed (array, bytestring, containers, haskell-src, network, packedstring and template-haskell) need no longer depend on syb, and syb need no longer be a boot package. That would give maximal freedom to develop syb independently, wouldn't it? (Changes to Data can't be independent of GHC, and the instances of the types listed are canonical, aren't they?) This wouldn't allow you to hide the partial instances for the pointer types, but it would be hard to stop them leaking anyway, as they're used by several of the above packages. From igloo at earth.li Tue Sep 2 18:32:44 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Sep 2 18:30:56 2008 Subject: Splitting SYB from the base package in GHC 6.10 In-Reply-To: <20080902222110.GA6365@soi.city.ac.uk> References: <52f14b210809010549y4cd91ae8ue7916b3d8f0670ed@mail.gmail.com> <20080902123523.GA18657@matrix.chaos.earth.li> <52f14b210809021145y5e667093m3d80290be2504b4c@mail.gmail.com> <1C4AE74FD8C843B1AAC9D92AE067F090@cr3lt> <20080902222110.GA6365@soi.city.ac.uk> Message-ID: <20080902223244.GA6903@matrix.chaos.earth.li> On Tue, Sep 02, 2008 at 11:21:10PM +0100, Ross Paterson wrote: > > syb need no longer be a boot package. If base3-compat comes with GHC then syb must too. Thanks Ian From leather at cs.uu.nl Tue Sep 2 18:54:16 2008 From: leather at cs.uu.nl (Sean Leather) Date: Tue Sep 2 18:52:29 2008 Subject: Splitting SYB from the base package in GHC 6.10 In-Reply-To: <3c6288ab0809021552i52637ba3xcc73e00998145abf@mail.gmail.com> References: <52f14b210809010549y4cd91ae8ue7916b3d8f0670ed@mail.gmail.com> <20080902123523.GA18657@matrix.chaos.earth.li> <52f14b210809021145y5e667093m3d80290be2504b4c@mail.gmail.com> <1C4AE74FD8C843B1AAC9D92AE067F090@cr3lt> <20080902222110.GA6365@soi.city.ac.uk> <20080902223244.GA6903@matrix.chaos.earth.li> <3c6288ab0809021552i52637ba3xcc73e00998145abf@mail.gmail.com> Message-ID: <3c6288ab0809021554p47790a4ag987b4b5f27d89333@mail.gmail.com> On Wed, Sep 3, 2008 at 00:32, Ian Lynagh wrote: > On Tue, Sep 02, 2008 at 11:21:10PM +0100, Ross Paterson wrote: > > syb need no longer be a boot package. > > If base3-compat comes with GHC then syb must too. > So, it would still need to be a boot package. However, if base3-compat depended on the specific release version of syb (i.e. == instead of >=), then we could still install a newer version of the syb package with a different API and not break base3-compat, correct? Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20080903/9f0bee46/attachment.htm From igloo at earth.li Tue Sep 2 19:13:13 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Sep 2 19:11:25 2008 Subject: Splitting SYB from the base package in GHC 6.10 In-Reply-To: <3c6288ab0809021554p47790a4ag987b4b5f27d89333@mail.gmail.com> References: <52f14b210809010549y4cd91ae8ue7916b3d8f0670ed@mail.gmail.com> <20080902123523.GA18657@matrix.chaos.earth.li> <52f14b210809021145y5e667093m3d80290be2504b4c@mail.gmail.com> <1C4AE74FD8C843B1AAC9D92AE067F090@cr3lt> <20080902222110.GA6365@soi.city.ac.uk> <20080902223244.GA6903@matrix.chaos.earth.li> <3c6288ab0809021552i52637ba3xcc73e00998145abf@mail.gmail.com> <3c6288ab0809021554p47790a4ag987b4b5f27d89333@mail.gmail.com> Message-ID: <20080902231313.GA23956@matrix.chaos.earth.li> On Wed, Sep 03, 2008 at 12:54:16AM +0200, Sean Leather wrote: > On Wed, Sep 3, 2008 at 00:32, Ian Lynagh wrote: > > > On Tue, Sep 02, 2008 at 11:21:10PM +0100, Ross Paterson wrote: > > > syb need no longer be a boot package. > > > > If base3-compat comes with GHC then syb must too. > > > > So, it would still need to be a boot package. However, if base3-compat > depended on the specific release version of syb (i.e. == instead of >=), > then we could still install a newer version of the syb package with a > different API and not break base3-compat, correct? The binary base3-compat will depend on a specific version of syb, so you can also install a newer version without breaking base3-compat, yes. Thanks Ian From claus.reinke at talk21.com Tue Sep 2 19:29:09 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Tue Sep 2 19:27:26 2008 Subject: Splitting SYB from the base package in GHC 6.10 References: <52f14b210809010549y4cd91ae8ue7916b3d8f0670ed@mail.gmail.com> <20080902123523.GA18657@matrix.chaos.earth.li> <52f14b210809021145y5e667093m3d80290be2504b4c@mail.gmail.com> <1C4AE74FD8C843B1AAC9D92AE067F090@cr3lt> <20080902210637.GA7519@matrix.chaos.earth.li> Message-ID: >> I have no idea whether these would give you sufficient flexibility to >> work on 'syb' after the ghc release > > I think I've missed something: What is the work that can't be done > before the instances are moved? If I understand Jos?'s intentions correctly, the idea is to keep the 'Data' class intact this round, but to give the 'syb' package maintainer and users the flexibility to try and improve the situation with 'Data' instances; ie, either - improve the currently partial and incomplete instances, or - not provide/import those instances that can't be completed But if the existing incomplete instances are not moved out of the way, their implicit import/export will always interfere with whatever new instances 'syb' might try to provide. So it seems as if we need one of: - ability to update 'base', changing the instances in place - ability to selectively import the incomplete instances, so that we can chose to import either the old ones or the new ones (or neither, if fixing turns out to be impossible) Unless you want to keep everything as it is, that is; or have I missed something? Claus From claus.reinke at talk21.com Tue Sep 2 19:43:35 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Tue Sep 2 19:42:05 2008 Subject: Splitting SYB from the base package in GHC 6.10 References: <52f14b210809010549y4cd91ae8ue7916b3d8f0670ed@mail.gmail.com><20080902123523.GA18657@matrix.chaos.earth.li><52f14b210809021145y5e667093m3d80290be2504b4c@mail.gmail.com><1C4AE74FD8C843B1AAC9D92AE067F090@cr3lt> <20080902222110.GA6365@soi.city.ac.uk> Message-ID: >> following the recent discussion, I would suggest to split the >> instances into three groups, in three separate modules: >> [standard]: fully implemented 'Data' instances (no runtime errors). >> [partial]: partially implemented instances (usually for abstract types, > If the Data class, your [standard] instances (including Ratio and Complex) > and the instances for FFI pointer types are in base, then the packages you > listed (array, bytestring, containers, haskell-src, network, packedstring > and template-haskell) need no longer depend on syb, and syb need no > longer be a boot package. That would give maximal freedom to develop > syb independently, wouldn't it? (Changes to Data can't be independent > of GHC, and the instances of the types listed are canonical, aren't they?) > > This wouldn't allow you to hide the partial instances for the pointer > types, but it would be hard to stop them leaking anyway, as they're used > by several of the above packages. That would be my guess, yes. It isn't quite "maximal" freedom because some of the things that one might want to improve would not even be in 'syb', but would stay in 'base'. But with all this surprising inertia, more freedom doesn't seem realistic anymore. Claus From pgavin at gmail.com Wed Sep 3 00:09:28 2008 From: pgavin at gmail.com (Peter Gavin) Date: Wed Sep 3 00:07:44 2008 Subject: [Haskell-cafe] Re: Arrow without `>>>' In-Reply-To: References: <49a77b7a0801231032j54755252t922693b6cd81acbe@mail.gmail.com> Message-ID: <48BE0DF8.9010108@gmail.com> Valery V. Vorotyntsev wrote: > On 1/23/08, David Menendez wrote: >> On Jan 23, 2008 12:20 PM, Valery V. Vorotyntsev wrote: >>> I've built GHC from darcs, and... >>> Could anybody tell me, what's the purpose of Arrow[1] not having `>>>' >>> method? >> It's derived from the Category superclass. > > Yes, it is. > > The right question: how to build `arrows' in such circumstances? > > Here go 2 changes I made to `CoState.hs' accompanied by the > error messages. :) Unfortunately, I'm not arrow-capable enough to > make _proper_ changes to the code and satisfy GHC... Any help? > Well, without looking at your code, generally all you have to do is 1) move the definition of (>>>) to Category and rename it to (.) after flipping the arguments. 2) define the id method of Category which is just (arr id) or returnA. So essentially instance Arrow (Foo a) where a >>> b = compose a b pure f = ... first a = ... becomes instance Arrow (Foo a) where pure f = ... first a = ... instance Category (Foo a) where id = arr id a . b = compose b a That's it. It's too bad there's no way to do this automatically in the libraries, but it could be noted in the API docs. Pete > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Change #1: > > $ darcs w Control/Arrow/Transformer/CoState.hs > What's new in "Control/Arrow/Transformer/CoState.hs": > > { > hunk ./Control/Arrow/Transformer/CoState.hs 23 > +import Control.Category ((>>>)) > } > > -------------------------------------------------- > Error #1: > > Control/Arrow/Transformer/CoState.hs:29:7: > `>>>' is not a (visible) method of class `Arrow' > Failed, modules loaded: Control.Arrow.Operations. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Change #2: > > $ darcs diff -u Control/Arrow/Transformer/CoState.hs > --- old-arrows/Control/Arrow/Transformer/CoState.hs 2008-01-24 > 14:54:29.852296559 +0200 > +++ new-arrows/Control/Arrow/Transformer/CoState.hs 2008-01-24 > 14:54:29.852296559 +0200 > @@ -20,12 +20,13 @@ > > import Control.Arrow > import Control.Arrow.Operations > +import Control.Category ((>>>)) > > newtype CoStateArrow s a b c = CST (a (s -> b) (s -> c)) > > instance Arrow a => Arrow (CoStateArrow s a) where > arr f = CST (arr (f .)) > - CST f >>> CST g = CST (f >>> g) > +-- CST f >>> CST g = CST (f >>> g) > first (CST f) = CST (arr unzipMap >>> first f >>> arr zipMap) > > zipMap :: (s -> a, s -> b) -> (s -> (a,b)) > > -------------------------------------------------- > Error#2: > > Control/Arrow/Transformer/CoState.hs:27:0: > Could not deduce (Control.Category.Category (CoStateArrow s a)) > from the context (Arrow a) > arising from the superclasses of an instance declaration > at Control/Arrow/Transformer/CoState.hs:27:0 > Possible fix: > add (Control.Category.Category > (CoStateArrow s a)) to the context of > the instance declaration > or add an instance declaration for > (Control.Category.Category (CoStateArrow s a)) > In the instance declaration for `Arrow (CoStateArrow s a)' > Failed, modules loaded: Control.Arrow.Operations. > > Thank you. > From ross at soi.city.ac.uk Wed Sep 3 04:13:56 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Sep 3 04:12:09 2008 Subject: Splitting SYB from the base package in GHC 6.10 In-Reply-To: References: <52f14b210809010549y4cd91ae8ue7916b3d8f0670ed@mail.gmail.com> <20080902123523.GA18657@matrix.chaos.earth.li> <52f14b210809021145y5e667093m3d80290be2504b4c@mail.gmail.com> <1C4AE74FD8C843B1AAC9D92AE067F090@cr3lt> <20080902210637.GA7519@matrix.chaos.earth.li> Message-ID: <20080903081355.GA2149@soi.city.ac.uk> On Wed, Sep 03, 2008 at 12:29:09AM +0100, Claus Reinke wrote: > If I understand Jos?'s intentions correctly, the idea is to keep the > 'Data' class intact this round, but to give the 'syb' package maintainer > and users the flexibility to try and improve the situation with 'Data' > instances; ie, either > > - improve the currently partial and incomplete instances, or > - not provide/import those instances that can't be completed > > But if the existing incomplete instances are not moved out of > the way, their implicit import/export will always interfere with > whatever new instances 'syb' might try to provide. I think the area of contention is pretty small. As I understand it, no-one wants to change the instances you call [standard], for the types [] Maybe Either tuples () Bool Ordering Char Double Float Handle Integer Int Int8 Int16 Int32 Int64 Word Word8 Word16 Word32 Word64 DataType TyCon TypeRep So they might as well go with the Data class. That leaves the [partial] instances that would have to be taken out of syb to make most of the other packages independent of it: Ratio Complex Ptr StablePtr ForeignPtr Assuming something sensible is done for the first two, would there really be any need to change these? From marlowsd at gmail.com Wed Sep 3 04:17:16 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Sep 3 04:15:34 2008 Subject: The base library and GHC 6.10 In-Reply-To: References: <20080828111232.GA15998@matrix.chaos.earth.li><404396ef0808280428j5f8ce984q904f5f0e2b0e61ee@mail.gmail.com><20080830120134.GA3741@matrix.chaos.earth.li><20080831121055.GA5326@soi.city.ac.uk><20080831121633.GA17919@matrix.chaos.earth.li> Message-ID: <48BE480C.5050308@gmail.com> Claus Reinke wrote: > Leaving Data.Generics.Basics in base while moving > Data.Generics.Instances to syb raises the interesting issue of > dealing with the accidental re-exports of Data.Generics.Instances > from various places. Here is that list again (*): > > $ find . -name '*hs' | grep -v _darcs | xargs grep -l 'Data.Generics' | grep -v Generics > ./array/Data/Array.hs > ./base/Data/Typeable.hs > ./bytestring/Data/ByteString/Internal.hs > ./bytestring/Data/ByteString/Lazy/Internal.hs > ./bytestring/Data/ByteString/Unsafe.hs > ./containers/Data/IntMap.hs > ./containers/Data/IntSet.hs > ./containers/Data/Map.hs > ./containers/Data/Sequence.hs > ./containers/Data/Set.hs > ./containers/Data/Tree.hs > ./haskell-src/Language/Haskell/Syntax.hs > ./network/Network/URI.hs > ./packedstring/Data/PackedString.hs > ./template-haskell/Language/Haskell/TH/Quote.hs > ./template-haskell/Language/Haskell/TH/Syntax.hs This raises the more general issue of instance-visibility. Since instances are automatically re-exported and therefore break abstraction barriers, the only sensible way to think about instances is as global properties. Attempting to limt the visibility of instances by putting them in separate packages or modules is futile. If an instance exists in a library *anywhere*, it potentially exists *everywhere*, and we should think of it as global. The only way to limit the visibility of instances is to not put them in a package. That means, for the particular case of the Data class, someone should decide once and for all whether there is an instance for IO, or functions, or whatever, and either define them along with the Data class or not at all. Cheers, Simon From claus.reinke at talk21.com Wed Sep 3 07:23:35 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Sep 3 07:21:59 2008 Subject: Splitting SYB from the base package in GHC 6.10 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> Message-ID: >I think the area of contention is pretty small. As I understand it, >no-one wants to change the instances you call [standard], for the types >[] Maybe Either tuples >() Bool Ordering Char Double Float Handle >Integer Int Int8 Int16 Int32 Int64 Word Word8 Word16 Word32 Word64 >DataType TyCon TypeRep This list already includes some [partial] instances - just knowing that these types have 'Data' instances isn't sufficient to use 'Data' operations on them safely (while avoiding runtime errors). >So they might as well go with the Data class. That leaves the [partial] >instances that would have to be taken out of syb to make most of the >other packages independent of it: > >Ratio Complex >Ptr StablePtr ForeignPtr 'Ratio' has a complete 'Data' instance, it just isn't consistent; the 'gfoldl' operation assumes a nullary constructor/no visisble constructors (abstract type) while the 'gunfold' operation assumes a binary constructor (concrete type, internal constructor). 'Complex' seems to be missing an instance? >Assuming something sensible is done for the first two, would there >really be any need to change these? That depends on whether the [partial] 'Data' instances can be completed in a sensible way for these types. If they can't, then the way forward would be to split the 'Data' class into those operations supported by all current instances and those only supported by the types in [standard]. That way, one would the presence of instances would at least be indicative of the presence of instance methods, providing more static type safety. But if the 'Data' class and some instances are in 'base', there'd be no changing them (*). Claus (*) of course, it would be nice if ghc's deriving mechanism was based on a derived instance specification in the module providing the class, rather than being hardcoded into the compiler itself; so even with 'Data' out of 'base', that part currently cannot be changed without updating ghc. or if class aliases allowed the generated old-style 'Data' instances to be re-interpreted as 'DataA' and 'DataB' instances.. but none of that is realistic for the current split decision. From simonpj at microsoft.com Wed Sep 3 07:50:08 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Sep 3 07:48:15 2008 Subject: Splitting SYB from the base package in GHC 6.10 In-Reply-To: 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> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE88093CD@EA-EXMSG-C334.europe.corp.microsoft.com> | Instead of repeating myself in full, I'd prefer you'd refer to my previous | emails (ask if they were unclear), but here is the gist of it (with no claim | of completeness): Claus, I found your summary very helpful. Thank you! Although you may have said it all before, I find it very difficult to keep a whole email thread in my head, and I find compact summaries really helpful. | I think the area of contention is pretty small. As I understand it, | no-one wants to change the instances you call [standard], for the types Ross's comments (reproduced below) look sensible to me. In the short term we probably don't know enough to be sure of doing the Permanently Right Thing. But time is short for 6.10, so I think for that near-term goal we should concentrate on something modest. My criterion is: base: stuff that (a) we don't expect to want to change and (b) that others might want to build on in a different way syb: stuff that may change There is a tension between (a) and (b); and the base/syb boundary may well be fuzzy. Concretely, I propose that we follow more or less Ross's suggestion: base: the Data class itself and [standard] instances, and any [partial] instances that we feel confident won't change syb: leftover [partial] instances, and [misfits] plus lots of SYB library code My reading of Claus's message is that, modulo discussion of some details of [partial], he'd go with that plan. I urge *against* making a new package for Data/Typeable, for now at least. The gain is slight or absent, and there is a cost in terms of new package dependencies, and the possibility that we may later decide to cut the cake another way. We recently decided to un-do the proposed splitting out of packages for 'getopt', 'st', 'concurrent', 'timeout' etc. for this very reason. See http://www.haskell.org/pipermail/libraries/2008-August/010543.html 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. Simon | -----Original Message----- | From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Ross Paterson | Sent: 03 September 2008 09:14 | To: libraries@haskell.org | Cc: Jos? Pedro Magalh?es | Subject: Re: Splitting SYB from the base package in GHC 6.10 | | On Wed, Sep 03, 2008 at 12:29:09AM +0100, Claus Reinke wrote: | > If I understand Jos?'s intentions correctly, the idea is to keep the | > 'Data' class intact this round, but to give the 'syb' package maintainer | > and users the flexibility to try and improve the situation with 'Data' | > instances; ie, either | > | > - improve the currently partial and incomplete instances, or | > - not provide/import those instances that can't be completed | > | > But if the existing incomplete instances are not moved out of | > the way, their implicit import/export will always interfere with | > whatever new instances 'syb' might try to provide. | | I think the area of contention is pretty small. As I understand it, | no-one wants to change the instances you call [standard], for the types | | [] Maybe Either tuples | () Bool Ordering Char Double Float Handle | Integer Int Int8 Int16 Int32 Int64 Word Word8 Word16 Word32 Word64 | DataType TyCon TypeRep | | So they might as well go with the Data class. That leaves the [partial] | instances that would have to be taken out of syb to make most of the | other packages independent of it: | | Ratio Complex | Ptr StablePtr ForeignPtr | | Assuming something sensible is done for the first two, would there really | be any need to change these? From ross at soi.city.ac.uk Wed Sep 3 07:57:50 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Sep 3 07:56:02 2008 Subject: Splitting SYB from the base package in GHC 6.10 In-Reply-To: References: <20080903081355.GA2149@soi.city.ac.uk> Message-ID: <20080903115750.GA4722@soi.city.ac.uk> Another attempt: These [standard] instances are uncontroversial and can accompany the Data class: [] Maybe Either () tuples Bool Ordering Char Double Float Integer Int Int8 Int16 Int32 Int64 Word Word8 Word16 Word32 Word64 These instances could also be [standard], after fixing: Ratio Complex These instances are [partial]: DataType TyCon TypeRep Handle Ptr StablePtr ForeignPtr > That depends on whether the [partial] 'Data' instances can be > completed in a sensible way for these types. If they can't, then > the way forward would be to split the 'Data' class into those > operations supported by all current instances and those only > supported by the types in [standard]. That way, one would the > presence of instances would at least be indicative of the presence > of instance methods, providing more static type safety. But if the > 'Data' class and some instances are in 'base', there'd be no > changing them (*). Unless anyone can imagine a completion for these types, it seems the fix must await restructuring of the Data class, so these might as well accompany the Data class too. Stuff in base can be changed, just not easily or quickly. And given that Data is tied up with GHC, that may be unavoidable. From ross at soi.city.ac.uk Wed Sep 3 07:59:16 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Sep 3 07:57:27 2008 Subject: The base library and GHC 6.10 In-Reply-To: <48BE480C.5050308@gmail.com> References: <48BE480C.5050308@gmail.com> Message-ID: <20080903115916.GA3066@soi.city.ac.uk> On Wed, Sep 03, 2008 at 09:17:16AM +0100, Simon Marlow wrote: > This raises the more general issue of instance-visibility. Since > instances are automatically re-exported and therefore break abstraction > barriers, the only sensible way to think about instances is as global > properties. > > Attempting to limt the visibility of instances by putting them in > separate packages or modules is futile. If an instance exists in a > library *anywhere*, it potentially exists *everywhere*, and we should > think of it as global. The only way to limit the visibility of instances > is to not put them in a package. > > That means, for the particular case of the Data class, someone should > decide once and for all whether there is an instance for IO, or > functions, or whatever, and either define them along with the Data class > or not at all. I agree with all that, but there may not be time to be confident of making the right decision in all these cases in time for 6.10. From claus.reinke at talk21.com Wed Sep 3 08:12:05 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Sep 3 08:10:21 2008 Subject: The base library and GHC 6.10 References: <20080828111232.GA15998@matrix.chaos.earth.li><404396ef0808280428j5f8ce984q904f5f0e2b0e61ee@mail.gmail.com><20080830120134.GA3741@matrix.chaos.earth.li><20080831121055.GA5326@soi.city.ac.uk><20080831121633.GA17919@matrix.chaos.earth.li> <48BE480C.5050308@gmail.com> Message-ID: <2D93D24B65084422832AF68B82EF4106@cr3lt> > This raises the more general issue of instance-visibility. Since instances > are automatically re-exported and therefore break abstraction barriers, the > only sensible way to think about instances is as global properties. I've heard this fatalistic view expressed before, and even for impoverished Haskell 98, it just isn't true. Perhaps it has come about from years of being bitten by either #2182, by attempts to avoid "orphan" instances, by carelessly designed libraries, or by careless instance imports, all of which make combining libraries that provide instances of the same class for the same type a pain? A type class specifies a relation between types. Both the types and the class are named, and if instances are placed in separate modules, the modules are named as well. The combination of module, class and type names gives quite a bit of control over instance import/export, even if it is terribly cumbersome and limited (and easily defeated by just one library importing all instances "for convenience"). Neither the relation (class), nor its domain (types), nor its extent (instances) are "global". Here's an example: module A where class A a where a :: a module B where import A instance A Bool where a = True module C where import A f :: A a => a f = a -- g :: Bool -- g = a In 'C', class 'A' and type 'Bool' are available, but the instance is not, so delaying instance selection ('f') works, while forcing instance selection ('g') gives a "missing instance" error. module D where import A import B import C g :: Bool g = a main = print (f::Bool,g) In 'D', type, class, and instance are available, so 'g' is allowed here. The word you are looking for is perhaps "accumulative": no module provides fewer instances than its imports, so instances accumulate recursively along the import hierarchy, no matter what the import/ export specifications say. In Haskell 98, that means conflicting instances ought to raise an error in 'Main' at the latest, but GHC deviates from that on purpose (#2356), which makes the life of projects using multiple libraries a little easier. I have often wondered why Haskell doesn't provide control over instance import/export, even without going all the way to naming instances: module B(instance A Bool) or import B hiding (instance A Bool) should go quite a way to improving instance scope control. Is it just that people want more (named instances), or is there any real problem with this simple approach? I'd prefer explicit instance scope control import X hiding (instance C a) -- no 'C' instances from package 'x' import Y (instance C a) -- all 'C' instances from package 'y' over the current "you can have conflicting instances, as long as you don't use them in conflicting ways" (#2356). > That means, for the particular case of the Data class, someone should > decide once and for all whether there is an instance for IO, or functions, > or whatever, and either define them along with the Data class or not at all. Ultimately, yes. And there have been several suggestions for improving the instances, or limiting the class to what is implementable, or avoiding the need for dummy instances to support deriving, etc. But even in the final analysis, there may be no better option than to provide dummy instances via explicit imports for those applications that want them. I mean I could decide that I'm in a "don't permit anything unsafe" mood and try to force this instance into any importer of 'Data' instance Fail a => Data (IO a) (where 'Fail' is a class that cannot have instances, as guaranteed by not exporting the class). Then I'd be happy until the day I actually need an instance, any instance of 'Data (IO a)' (or someone else does;-). The trick is to split the imperfect code we have in such a way that it does not prevent users from taking their pick, and making their own choices, suitable for their projects. Anyway, there is no hope of deciding the fate of these instances in time for the release candidate, and the decision to be made now is how to support a realistic amount of improvement after the release, by making suitable _preparations_ before the release. Claus From jpm at cs.uu.nl Thu Sep 4 03:44:34 2008 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Thu Sep 4 03:42:41 2008 Subject: Splitting SYB from the base package in GHC 6.10 In-Reply-To: <20080903115750.GA4722@soi.city.ac.uk> References: <20080903081355.GA2149@soi.city.ac.uk> <20080903115750.GA4722@soi.city.ac.uk> Message-ID: <52f14b210809040044k6df6a92x3442b04f45ba54f4@mail.gmail.com> Hello, On Wed, Sep 3, 2008 at 13:57, Ross Paterson wrote: > Another attempt: > > These [standard] instances are uncontroversial and can accompany the > Data class: > > [] Maybe Either () tuples > Bool Ordering Char Double Float Integer > Int Int8 Int16 Int32 Int64 Word Word8 Word16 Word32 Word64 > > These instances could also be [standard], after fixing: > > Ratio Complex So Ratio would have to be given a proper gfoldl definition, to fits its unfold: gunfold k z c | constrIndex c == 1 = k (k (z (:%))) 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? Regarding the other places that have to be changed [1]: ./array/Data/Array.hs The Data instance of Array should be moved from Data.Generics.Instances into Array, to avoid syb dependency. ./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 As far as I can see, these are not problematic, but the imports should be fixed to avoid bringing into scope all the instances. ./haskell-src/Language/Haskell/Syntax.hs ./template-haskell/Language/Haskell/TH/Quote.hs ./template-haskell/Language/Haskell/TH/Syntax.hs The use of Ratio instances here is not problematic if the instance for Ratio is fixed? ./bytestring/Data/ByteString/Internal.hs ./bytestring/Data/ByteString/Lazy/Internal.hs These depend on an instance for ForeignPtr Word8. What to do here? Reclassify instances for types with phantom types into "standard", since there is nothing to traverse? On Wed, Sep 3, 2008 at 13:23, Claus Reinke wrote: > (*) of course, it would be nice if ghc's deriving mechanism was > based on a derived instance specification in the module providing > the class, rather than being hardcoded into the compiler itself; > so even with 'Data' out of 'base', that part currently cannot be > changed without updating ghc. or if class aliases allowed the > generated old-style 'Data' instances to be re-interpreted as > 'DataA' and 'DataB' instances.. but none of that is realistic for > the current split decision. I fully agree that the deriving mechanism should be customizable. That would make generic programming in general much nicer in Haskell. However, I don't think it's realistic to expect such changes for 6.10... Thanks, Pedro [1] http://article.gmane.org/gmane.comp.lang.haskell.libraries/9957 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20080904/887ac99d/attachment-0001.htm From ross at soi.city.ac.uk Thu Sep 4 05:49:26 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Sep 4 05:47:35 2008 Subject: Splitting SYB from the base package in GHC 6.10 In-Reply-To: <52f14b210809040044k6df6a92x3442b04f45ba54f4@mail.gmail.com> References: <20080903081355.GA2149@soi.city.ac.uk> <20080903115750.GA4722@soi.city.ac.uk> <52f14b210809040044k6df6a92x3442b04f45ba54f4@mail.gmail.com> Message-ID: <20080904094926.GA5093@soi.city.ac.uk> On Thu, Sep 04, 2008 at 09:44:34AM +0200, 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? I was looking at the HEAD, where the instance was moved into Data.Generics.Instances, and used the default definition of gfoldl. Presumably if the Data class is in base, there's no problem with restoring the derived instance. > Regarding the other places that have to be changed [1]: > > ./array/Data/Array.hs > > The Data instance of Array should be moved from Data.Generics.Instances > into Array, to avoid syb dependency. The instance needs only the Data class, so it would be independent of syb. Its proper place is the array package, but since GHC defines Array in GHC.Arr it might define the instance there too. > ./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 > > As far as I can see, these are not problematic, but the imports should > be fixed to avoid bringing into scope all the instances. These packages should be able to avoid depending on syb. > ./haskell-src/Language/Haskell/Syntax.hs > ./template-haskell/Language/Haskell/TH/Quote.hs > ./template-haskell/Language/Haskell/TH/Syntax.hs > > The use of Ratio instances here is not problematic if the instance > for Ratio is fixed? > > ./bytestring/Data/ByteString/Internal.hs > ./bytestring/Data/ByteString/Lazy/Internal.hs I assume so. > These depend on an instance for ForeignPtr Word8. What to do here? > Reclassify instances for types with phantom types into "standard", > since there is nothing to traverse? That was the suggestion. The types in question are Ptr, ForeignPtr and StablePtr. (I think the Var's are similar, but it's not essential to decide about them now.) From dave at zednenem.com Thu Sep 4 12:25:00 2008 From: dave at zednenem.com (David Menendez) Date: Thu Sep 4 12:23:06 2008 Subject: Splitting SYB from the base package in GHC 6.10 In-Reply-To: <52f14b210809040044k6df6a92x3442b04f45ba54f4@mail.gmail.com> References: <20080903081355.GA2149@soi.city.ac.uk> <20080903115750.GA4722@soi.city.ac.uk> <52f14b210809040044k6df6a92x3442b04f45ba54f4@mail.gmail.com> Message-ID: <49a77b7a0809040925h37869b3ag67b36f4e2ea72683@mail.gmail.com> 2008/9/4 Jos? Pedro Magalh?es : > ./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 > > As far as I can see, these are not problematic, but the imports should be > fixed to avoid bringing into scope all the instances. I see some partial instances. For example, Data.Set throws exceptions for toConstr and gunfold. -- Dave Menendez From igloo at earth.li Thu Sep 4 19:48:14 2008 From: igloo at earth.li (Ian Lynagh) Date: Thu Sep 4 19:46:19 2008 Subject: darcs patch: Unbreak the GHC build with older versions of gcc In-Reply-To: <20080831191954.GA32203@matrix.chaos.earth.li> References: <200808281950.m7SJoJnR022852@petunia.outback.escape.de> <20080831191954.GA32203@matrix.chaos.earth.li> Message-ID: <20080904234814.GA7335@matrix.chaos.earth.li> On Sun, Aug 31, 2008 at 08:19:54PM +0100, Ian Lynagh wrote: > On Thu, Aug 28, 2008 at 09:50:19PM +0200, kili@outback.escape.de wrote: > > Thu Aug 28 16:27:43 CEST 2008 kili@outback.escape.de > > * Unbreak the GHC build with older versions of gcc > > > > Stg.h must be included before HsBase.h, because the latter contains > > function definitions causing older versions of gcc (3.3.5 in my > > case) to bail out with "error: global register variable follows a > > function definition" on Regs.h, which is included by Stg.h. > > > > > hunk ./cbits/PrelIOUtils.c 8 > > -#include "HsBase.h" > > hunk ./cbits/PrelIOUtils.c 9 > > +#include "HsBase.h" > > This breaks the build for me: > > I haven't looked at why yet. It turned out that something in Stg.h, perhaps _ISOC99_SOURCE, meant S_ISSOCK wasn't being defined. I defined _BSD_SOURCE too, and now it's happy, so I've applied your patch (well, actually a new patch that does the same thing, because yours now conflicts with more recent changes). Thanks Ian From jpm at cs.uu.nl Fri Sep 5 02:37:48 2008 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Fri Sep 5 02:35:52 2008 Subject: Splitting SYB from the base package in GHC 6.10 In-Reply-To: <49a77b7a0809040925h37869b3ag67b36f4e2ea72683@mail.gmail.com> References: <20080903081355.GA2149@soi.city.ac.uk> <20080903115750.GA4722@soi.city.ac.uk> <52f14b210809040044k6df6a92x3442b04f45ba54f4@mail.gmail.com> <49a77b7a0809040925h37869b3ag67b36f4e2ea72683@mail.gmail.com> Message-ID: <52f14b210809042337o9c6d4cejcc7a7e7d51973e40@mail.gmail.com> Hello, On Thu, Sep 4, 2008 at 11:49, Ross Paterson wrote: > On Thu, Sep 04, 2008 at 09:44:34AM +0200, 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? > > I was looking at the HEAD, where the instance was moved into > Data.Generics.Instances, and used the default definition of gfoldl. > Presumably if the Data class is in base, there's no problem with > restoring the derived instance. Oh, I didn't know this had changed. I was looking in 6.8.3. Then yes, it should probably return to where it was. On Thu, Sep 4, 2008 at 18:25, David Menendez wrote: > 2008/9/4 Jos? Pedro Magalh?es : > > ./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 > > > > As far as I can see, these are not problematic, but the imports should be > > fixed to avoid bringing into scope all the instances. > > I see some partial instances. For example, Data.Set throws exceptions > for toConstr and gunfold. Yes, but those are defined instances, not imported instances. I believe that is not this problem (it is a problem, just not the one we're focusing on right now). Those would have to wait for a possible "break up" of the Data class, as Claus suggested. Thanks, Pedro -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20080905/9c92a7e3/attachment.htm From bart at cs.pdx.edu Fri Sep 5 03:06:54 2008 From: bart at cs.pdx.edu (Bart Massey) Date: Fri Sep 5 03:05:14 2008 Subject: Generalize groupBy in a useful way? Message-ID: I experienced some interesting behavior with groupBy tonight, and thought I'd run it by folks as a proposal for the Haskell libraries. Consider the predicate incp e1 e2 = e1 + 1 == e2 Naively, one might expect groupBy incp [2,3,4,5,6] == [[2,3,4,5,6]] but one actually gets [[2,3],[4,5],[6]] from the standard library implementation. The Haskell98 Report makes it clear that "When the 'By' function replaces an Eq context by a binary predicate, the predicate is assumed to define an equivalence." Thus, the observed behavior is technically correct, or at least technically not incorrect. The incp predicate does not follow the equivalence laws (it is neither symmetric nor reflexive), so groupBy is probably permitted to return most any result of the correct type. What is actually happening is that the groupBy implementation is using span with a predicate (incp a) where a is the first element in the list. I think it would be better to expand the definition of of groupBy such that the equality test is applied only to adjacent elements (with the arguments in proper order). This would not change the behavior for true equality predicates, but would permit cases like incp to have sensible behavior, which can occasionally be useful. (It was to me in this case: I was identifying straights in poker hands.) Here's a suggested (untested) implementation. (See also http://hpaste.org/10134?#a0 ) It relies on a new "chain" function that is the binary equivalent of span. This function seems to me to be useful in its own right. chain :: (a -> a -> Bool) -> [a] -> ([a],[a]) chain _ [] = ([], []) chain _ [e] = ([e], []) chain p (e1 : es@(e2 : _)) | p e1 e2 = let (s1, s2) = chain p es in (e1 : s1, s2) | otherwise = ([e1], es) groupBy' _ [] = [] groupBy' p l = s1 : groupBy' p s2 where (s1, s2) = chain p l The implementation of groupBy' is actually a bit cleaned up compared to that of groupBy. Regardless of what is done here, it would be nice to expand the Haddock for groupBy in the standard library to make it clear how the predicate is used. Comments and suggestions are welcome. Am I way off base here? Bart Massey bart@cs.pdx.edu From ross at soi.city.ac.uk Fri Sep 5 03:33:56 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Fri Sep 5 03:32:03 2008 Subject: Generalize groupBy in a useful way? In-Reply-To: References: Message-ID: <20080905073355.GA20067@soi.city.ac.uk> On Fri, Sep 05, 2008 at 07:06:54AM +0000, Bart Massey wrote: > I think it would be better to expand the definition of > groupBy such that the equality test is applied only to > adjacent elements (with the arguments in proper order). I agree: http://www.haskell.org/pipermail/haskell-cafe/2006-October/019148.html http://www.haskell.org/pipermail/libraries/2007-August/008031.html We should do it this time. (Probably too late for 6.10, though.) From duncan.coutts at worc.ox.ac.uk Fri Sep 5 08:23:11 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Sep 5 08:19:53 2008 Subject: Generalize groupBy in a useful way? In-Reply-To: <20080905073355.GA20067@soi.city.ac.uk> References: <20080905073355.GA20067@soi.city.ac.uk> Message-ID: <1220617391.6076.55.camel@localhost> On Fri, 2008-09-05 at 08:33 +0100, Ross Paterson wrote: > On Fri, Sep 05, 2008 at 07:06:54AM +0000, Bart Massey wrote: > > I think it would be better to expand the definition of > > groupBy such that the equality test is applied only to > > adjacent elements (with the arguments in proper order). > > I agree: > > http://www.haskell.org/pipermail/haskell-cafe/2006-October/019148.html > http://www.haskell.org/pipermail/libraries/2007-August/008031.html > > We should do it this time. (Probably too late for 6.10, though.) Yes, this behaviour surprised us when we were re-implementing the list library (as part of the stream fusion stuff). We assumed this was the behaviour and didn't catch it until we ran our quickcheck tests with randomly generated predicates. There's also a more efficient version that can be implemented if one is allowed to be slightly stricter and not return a group until the end of the group is encountered, but that's obviously not suitable for Data.List. (But it would be interesting if we could use RULES that could match on strictness properties.) Duncan From ganesh.sittampalam at credit-suisse.com Fri Sep 5 08:23:35 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Fri Sep 5 08:27:06 2008 Subject: #2532: Add Typeable instance to Data.Unique In-Reply-To: References: Message-ID: <78A3C5650E28124399107F21A1FA419401D3B882@ELON17P32002A.csfb.cs-group.com> Jim Apple wrote: > http://hackage.haskell.org/trac/ghc/ticket/2532 > > Discussion deadline: Sept 7 I believe that the combination of this instance, the behaviour of Data.Unique, and the behaviour of hs-plugins is broken. In particular, as I understand the behaviour of hs-plugins, it is already possible to generate Unique values inside a plugin that conflict with Unique values generated in the main program, and this instance will allow those values to be passed across the plugin boundary. It's not clear to me what is to blame here. hs-plugins does something dodgy, in that it hacks the behaviour of Data.Typeable instances so that the same types get identical instances on both sides of the plugin boundary. Data.Unique is doing something dodgy by using a global variable. (There's a long discussion about this on haskell-caf? at the moment.) The combination is what leads to the brokenness. I will test this to confirm as soon as I can, but as the deadline is approaching I thought I should raise the issue immediately. Cheers, Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From jules at jellybean.co.uk Fri Sep 5 08:34:47 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Fri Sep 5 08:32:50 2008 Subject: Splitting SYB from the base package in GHC 6.10 In-Reply-To: <52f14b210809040044k6df6a92x3442b04f45ba54f4@mail.gmail.com> References: <20080903081355.GA2149@soi.city.ac.uk> <20080903115750.GA4722@soi.city.ac.uk> <52f14b210809040044k6df6a92x3442b04f45ba54f4@mail.gmail.com> Message-ID: <48C12767.5010200@jellybean.co.uk> 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. Jules From igloo at earth.li Fri Sep 5 11:44:41 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri Sep 5 11:42:45 2008 Subject: Bugfix for QuickCheck 1.1.0.0 In-Reply-To: <62E8F614-D0C2-46BA-AE22-FFE642C88585@stanford.edu> References: <4E804BD8-22DB-4EDF-AC29-900908603650@stanford.edu> <62E8F614-D0C2-46BA-AE22-FFE642C88585@stanford.edu> Message-ID: <20080905154441.GA15602@matrix.chaos.earth.li> On Sun, Aug 31, 2008 at 10:28:32AM -0700, Patrick Perry wrote: > It's been a week and no one has objected. I'm interpreting your > silence on the matter as consent. Could someone with commit access > please add the patch and bump the version number for QuickCheck? So are we all agreed that this should be applied, now? Patrick, could you add to http://hackage.haskell.org/trac/ghc/ticket/2535 a summary of the discussion and a link to the mailing list archives of this thread, please? Thanks Ian From Malcolm.Wallace at cs.york.ac.uk Fri Sep 5 11:53:49 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Fri Sep 5 11:54:11 2008 Subject: Bugfix for QuickCheck 1.1.0.0 In-Reply-To: <20080905154441.GA15602@matrix.chaos.earth.li> References: <4E804BD8-22DB-4EDF-AC29-900908603650@stanford.edu> <62E8F614-D0C2-46BA-AE22-FFE642C88585@stanford.edu> <20080905154441.GA15602@matrix.chaos.earth.li> Message-ID: <20080905165349.752dcc21.Malcolm.Wallace@cs.york.ac.uk> > > It's been a week and no one has objected. I'm interpreting your > > silence on the matter as consent. Could someone with commit access > > please add the patch and bump the version number for QuickCheck? > > So are we all agreed that this should be applied, now? Well, I'm still slightly dubious about this change, but since I'm finding it hard to articulate why, you can ignore me. Did anyone ask Koen directly about it? Or is the fact that there is a similar fix in QC2 a sufficient blessing from the original author? Regards, Malcolm From patperry at stanford.edu Fri Sep 5 17:39:06 2008 From: patperry at stanford.edu (Patrick Perry) Date: Fri Sep 5 17:37:23 2008 Subject: Bugfix for QuickCheck 1.1.0.0 In-Reply-To: <20080905154441.GA15602@matrix.chaos.earth.li> References: <4E804BD8-22DB-4EDF-AC29-900908603650@stanford.edu> <62E8F614-D0C2-46BA-AE22-FFE642C88585@stanford.edu> <20080905154441.GA15602@matrix.chaos.earth.li> Message-ID: <740B7362-3C80-455D-B815-74B6AFF2B6A7@stanford.edu> I've updated the ticket with the a summary of the discussion and links to relevant posts. Thanks, Patrick On Sep 5, 2008, at 8:44 AM, Ian Lynagh wrote: > On Sun, Aug 31, 2008 at 10:28:32AM -0700, Patrick Perry wrote: >> It's been a week and no one has objected. I'm interpreting your >> silence on the matter as consent. Could someone with commit access >> please add the patch and bump the version number for QuickCheck? > > So are we all agreed that this should be applied, now? > > Patrick, could you add to > http://hackage.haskell.org/trac/ghc/ticket/2535 > a summary of the discussion and a link to the mailing list archives of > this thread, please? > > > Thanks > Ian > From wnoise at ofb.net Fri Sep 5 21:43:01 2008 From: wnoise at ofb.net (Aaron Denney) Date: Fri Sep 5 21:41:12 2008 Subject: Generalize groupBy in a useful way? References: Message-ID: On 2008-09-05, Bart Massey wrote: > I experienced some interesting behavior with groupBy > tonight, and thought I'd run it by folks as a proposal for > the Haskell libraries. > > > Consider the predicate > > incp e1 e2 = e1 + 1 == e2 > > Naively, one might expect > > groupBy incp [2,3,4,5,6] == [[2,3,4,5,6]] > > but one actually gets [[2,3],[4,5],[6]] from the standard library > implementation. > > The Haskell98 Report makes it clear that > > "When the 'By' function replaces an Eq context by a > binary predicate, the predicate is assumed to define an > equivalence." > > Thus, the observed behavior is technically correct, or at > least technically not incorrect. The incp predicate does > not follow the equivalence laws (it is neither symmetric nor > reflexive), so groupBy is probably permitted to return most > any result of the correct type. What is actually happening > is that the groupBy implementation is using span with a > predicate (incp a) where a is the first element in the list. If the comparison can be expensive on the first element, this allows the possibility of caching some of that computation by constructing a function that does the comparison. I admit this is unlikely... -- Aaron Denney -><- From gwern0 at gmail.com Sat Sep 6 05:42:50 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Sat Sep 6 05:41:43 2008 Subject: Performance horrors In-Reply-To: <48B47B39.2000309@iee.org> References: <48B3B305.2040907@iee.org> <404396ef0808260326v6eaf9e40s8ed25295a455ae2a@mail.gmail.com> <125EACD0CAE4D24ABDB4D148C4593DA9049E9541@GBLONXMB02.corp.amvescap.net> <20080826194514.GB11435@craft> <48B47B39.2000309@iee.org> Message-ID: <20080906094250.GA9335@craft> On 2008.08.26 22:52:57 +0100, Adrian Hey scribbled 0.5K characters: > Gwern Branwen wrote: >> FWIW, when I tested out a number of nub/uniq definitions, the map head version performed the worst, much worse than the O(n^2) one everyone is complaining about. It's a neat definition, but not performant. > > When did you try this? IIRC correctly even the old sort was O(n^2), but > someone had the sense to replace it a while ago. > > With ghci now on my machine.. > length $ map head $ group $ sort [1..100000] > finishes "instantly", but.. > length $ nub [1..100000] > takes about 90 seconds. > > Regards > -- > Adrian Hey > Sure, but suppose the list isn't nicely ascending? Suppose it's even repeated? Try out Prelude Data.List> length $ map head $ group $ sort $ take 10000000 $ repeat [1] versus Prelude> length $ nub $ take 10000000 $ repeat [1] Then the situation is the opposite, instant versus a long time. -- gwern Fetish Supreme detcord RFI Plame Yankee Kvashnin FDM Hitwords domestic -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/libraries/attachments/20080906/066b50ac/attachment.bin From nicolas.pouillard at gmail.com Sat Sep 6 08:28:49 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Sat Sep 6 08:28:50 2008 Subject: darcs patch: Export the Positive constructor. Message-ID: <767095$rhacr@mail4-relais-sop.national.inria.fr> Others types like NonNegative, NonZero have their constructor exported in Test.QuickCheck, the Positive constructor deserve the same :) Sat Sep 6 14:23:22 CEST 2008 Nicolas Pouillard * Export the Positive constructor. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 3154 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/libraries/attachments/20080906/04e923d9/attachment.bin From nicolas.pouillard at gmail.com Sat Sep 6 08:39:20 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Sat Sep 6 08:38:01 2008 Subject: darcs patch: Export the Positive constructor. In-Reply-To: <767095$rhacr@mail4-relais-sop.national.inria.fr> References: <767095$rhacr@mail4-relais-sop.national.inria.fr> Message-ID: <1220704739-sup-1139@ausone.local> Please disregard this message... Excerpts from Nicolas Pouillard's message of Mon Sep 01 14:30:09 +0200 2008: > Others types like NonNegative, NonZero have their constructor exported in > Test.QuickCheck, the Positive constructor deserve the same :) > > Sat Sep 6 14:23:22 CEST 2008 Nicolas Pouillard > * Export the Positive constructor. -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20080906/99ce313b/signature.bin From g9ks157k at acme.softbase.org Sat Sep 6 13:02:47 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Sat Sep 6 13:01:02 2008 Subject: Generalize groupBy in a useful way? In-Reply-To: References: Message-ID: <200809061902.47372.g9ks157k@acme.softbase.org> Am Freitag, 5. September 2008 09:06 schrieb Bart Massey: > [?] > I think it would be better to expand the definition of of > groupBy such that the equality test is applied only to > adjacent elements (with the arguments in proper order). > This would not change the behavior for true equality > predicates, but would permit cases like incp to have > sensible behavior, which can occasionally be useful. (It was > to me in this case: I was identifying straights in poker > hands.) I think it would be better forcing the function to be an equivalence relation using dependent types. ;-) In the absence of dependent types, I think that noone should ever call groupBy with a relation which is not an equivalence. So for me, it really doesn?t matter what the function does if the precondition for calling it is not fulfilled. > [?] Best wishes, Wolfgang From bart at cs.pdx.edu Sat Sep 6 18:10:57 2008 From: bart at cs.pdx.edu (Bart Massey) Date: Sat Sep 6 18:09:11 2008 Subject: nubOrd (Re: Performance horrors) References: <48B3B305.2040907@iee.org> <404396ef0808260326v6eaf9e40s8ed25295a455ae2a@mail.gmail.com> <125EACD0CAE4D24ABDB4D148C4593DA9049E9541@GBLONXMB02.corp.amvescap.net> <20080826194514.GB11435@craft> <48B47B39.2000309@iee.org> <20080906094250.GA9335@craft> Message-ID: IMHO the right way to think about nub is that it filters the given list with a "stop list". This code captures that intuition, and allows new kinds of nubs to be quickly constructed. Don't know if anyone wants it, but I thought I'd show it off, anyhow. nubWrt :: (StopList e s) => s -> [e] -> [e] nubWrt s [] = [] nubWrt s (e : es) | memberS e s = nubWrt s es nubWrt s (e : es) = e : nubWrt (insertS e s) es nub :: (Eq e) => [e] -> [e] nub = nubWrt [] nubOrd :: (Ord e) => [e] -> [e] nubOrd = nubWrt S.empty nubInt :: [Int] -> [Int] nubInt = nubWrt IS.empty I've omitted the StopList class and instances, which are of course crucial, but are kind of obvious. Get the whole code at http://svcs.cs.pdx.edu/gitweb?p=nub.git;f=Nub.hs;hb=master to see the details. A day of painful fiddling with how to do benchmark timing (there are three packages in Hackage and I couldn't figure out how to use any of them) tells me that this version of nub is about the same speed as the nub in Prelude (unsurprisingly). This nubOrd is capable of running a list of 10^7 elements, all different, in about 23 seconds on my box; nubInt runs that list in about 5 seconds. Plain old nub runs a list of 10^5 elements, all different, in about 70 seconds. For small lists, or lists where many of the elements are the same, everything's good: all the functions are fast and about the same speed. They all run lists of 10^8 identical elements in around 5s, although it turns out that the IntSet member test is close to twice as fast as list elem. I haven't QuickCheck tested anything, but my little tests with ghci make me think the code is probably correct. Hope this helps. Bart Massey bart@cs.pdx.edu From ashley at semantic.org Sat Sep 6 18:52:41 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Sat Sep 6 18:50:52 2008 Subject: Hackage/Cabal Broken? Message-ID: $ cabal --version cabal-install version 0.5.1 using version 1.4.0.1 of the Cabal library $ cabal update Downloading package list from server 'http://hackage.haskell.org/packages/archive' cabal: user error (Codec.Compression.Zlib: invalid stored block lengths) -- Ashley Yakeley From ashley at semantic.org Sat Sep 6 19:05:18 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Sat Sep 6 19:03:17 2008 Subject: Hackage/Cabal Broken? In-Reply-To: References: Message-ID: <48C30CAE.6080600@semantic.org> I wrote: > $ cabal update > Downloading package list from server > 'http://hackage.haskell.org/packages/archive' > cabal: user error (Codec.Compression.Zlib: invalid stored block lengths) The index file is not a valid gzip file. -- Ashley Yakeley From dons at galois.com Sat Sep 6 19:25:02 2008 From: dons at galois.com (Don Stewart) Date: Sat Sep 6 19:22:55 2008 Subject: Hackage/Cabal Broken? In-Reply-To: <48C30CAE.6080600@semantic.org> References: <48C30CAE.6080600@semantic.org> Message-ID: <20080906232502.GG16970@scytale.galois.com> ashley: > I wrote: > >$ cabal update > >Downloading package list from server > >'http://hackage.haskell.org/packages/archive' > >cabal: user error (Codec.Compression.Zlib: invalid stored block lengths) > > The index file > is not a > valid gzip file. A few people reported tihs too. But seems ok now, so looks like it was regenerated correctly. -- Don From jbapple+haskell-lib at gmail.com Sun Sep 7 11:13:57 2008 From: jbapple+haskell-lib at gmail.com (Jim Apple) Date: Sun Sep 7 11:11:54 2008 Subject: #2532: Add Typeable instance to Data.Unique In-Reply-To: <78A3C5650E28124399107F21A1FA419401D3B882@ELON17P32002A.csfb.cs-group.com> References: <78A3C5650E28124399107F21A1FA419401D3B882@ELON17P32002A.csfb.cs-group.com> Message-ID: On Fri, Sep 5, 2008 at 5:23 AM, Sittampalam, Ganesh wrote: > (There's a long discussion about this on haskell-caf? at the moment.) I tried to find this thread (by searching for "unique" and "plug" on http://www.haskell.org/pipermail/haskell-cafe/ ), but couldn't. What is the subject line? Thanks, Jim From allbery at ece.cmu.edu Sun Sep 7 12:26:36 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Sep 7 12:24:36 2008 Subject: #2532: Add Typeable instance to Data.Unique In-Reply-To: References: <78A3C5650E28124399107F21A1FA419401D3B882@ELON17P32002A.csfb.cs-group.com> Message-ID: <0EFE5228-D045-4E5F-BF1C-4BBF455944F0@ece.cmu.edu> On 2008 Sep 7, at 11:13, Jim Apple wrote: > On Fri, Sep 5, 2008 at 5:23 AM, Sittampalam, Ganesh > wrote: >> (There's a long discussion about this on haskell-caf? at the moment.) > > I tried to find this thread (by searching for "unique" and "plug" on > http://www.haskell.org/pipermail/haskell-cafe/ ), but couldn't. What > is the subject line? "Top-level <-" -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From jbapple+haskell-lib at gmail.com Sun Sep 7 12:55:07 2008 From: jbapple+haskell-lib at gmail.com (Jim Apple) Date: Sun Sep 7 12:53:03 2008 Subject: #2532: Add Typeable instance to Data.Unique In-Reply-To: <0EFE5228-D045-4E5F-BF1C-4BBF455944F0@ece.cmu.edu> References: <78A3C5650E28124399107F21A1FA419401D3B882@ELON17P32002A.csfb.cs-group.com> <0EFE5228-D045-4E5F-BF1C-4BBF455944F0@ece.cmu.edu> Message-ID: I'm afraid I haven't time to read the whole thread and come up with a good answer about whether or not adding Typeable to Data.Unique is dangerous. Given that, I'm no longer, er, proposing this proposal. Jim On Sun, Sep 7, 2008 at 9:26 AM, Brandon S. Allbery KF8NH wrote: > On 2008 Sep 7, at 11:13, Jim Apple wrote: >> >> On Fri, Sep 5, 2008 at 5:23 AM, Sittampalam, Ganesh >> wrote: >>> >>> (There's a long discussion about this on haskell-caf? at the moment.) >> >> I tried to find this thread (by searching for "unique" and "plug" on >> http://www.haskell.org/pipermail/haskell-cafe/ ), but couldn't. What >> is the subject line? > > > "Top-level <-" 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:29 2008 Subject: 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/libraries/attachments/20080907/7bf009b1/attachment.htm From ganesh.sittampalam at credit-suisse.com Sun Sep 7 16:39:15 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Sun Sep 7 16:37:34 2008 Subject: #2532: Add Typeable instance to Data.Unique In-Reply-To: References: <78A3C5650E28124399107F21A1FA419401D3B882@ELON17P32002A.csfb.cs-group.com> <0EFE5228-D045-4E5F-BF1C-4BBF455944F0@ece.cmu.edu> Message-ID: <78A3C5650E28124399107F21A1FA419401D3B88B@ELON17P32002A.csfb.cs-group.com> Sorry, I didn't intend to scare you into submission. I'm not even necessarily opposing this proposal, just warning of some consequences. I'll try to summarise the issue below. The linked thread isn't of all that much relevance except in that it led to me realising that this issue probably exists. Data.Unique uses a "top-level global variable" (an IORef) as a counter for the Integer underlying Unique values. This is initialised to 0 via a {-# NOINLINE -#} unsafePerformIO the first time it is needed. If you load something via hs-plugins, any modules it uses are loaded into the process, even if they are already loaded via the static part of the program. This only happens once, i.e. the most copies of the module you can end up with is two - although another dynamic loading architecture might well do something different. So any Unique values created in the plugin will be created with the counter starting from 0 again, so will collide with any Unique values created in the static part of the process. hs-plugins uses special knowledge of how Data.Typeable works (another global variable!) to ensure that the "same" types have the same type reps in both the static and dynamic sides of the process. So, adding Data.Typeable to Unique will allow these colliding Unique values to be passed between the static and dynamic sides, causing two separately generated Unique values to potentially compare equal. As I said in my original comment, it could well be reasonable to blame hs-plugins for hacking around with Typeable instances. On the other hand, it's hard to see what else it can do if people are to actually use plugins from the main process, and Data.Unique is clearly using an unsafe hack. (In the thread referred to below, I'm mainly opposing the formalisation of that hack into the top-level <- operation.) It doesn't really strike me as the end of the world if a module that is already doing something dodgy turns out to be broken in the dynamic loading world, as long as people are aware of this. Presumably the Typeable instance will be useful for many things other than dynamic loading. Any further questions, please do ask. Also, Brandon or someone else who is in favour of top-level <- might be able to cast what Data.Unique is doing in a more positive light :-) I've been trying to build a recent GHC HEAD and then hs-plugins (hackage package "plugins") all weekend so I can try this out for real, but haven't got far enough yet. Ganesh -----Original Message----- From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Jim Apple Sent: 07 September 2008 17:55 To: libraries@haskell.org Subject: Re: #2532: Add Typeable instance to Data.Unique I'm afraid I haven't time to read the whole thread and come up with a good answer about whether or not adding Typeable to Data.Unique is dangerous. Given that, I'm no longer, er, proposing this proposal. Jim On Sun, Sep 7, 2008 at 9:26 AM, Brandon S. Allbery KF8NH wrote: > On 2008 Sep 7, at 11:13, Jim Apple wrote: >> >> On Fri, Sep 5, 2008 at 5:23 AM, Sittampalam, Ganesh >> wrote: >>> >>> (There's a long discussion about this on haskell-caf? at the >>> moment.) >> >> I tried to find this thread (by searching for "unique" and "plug" on >> http://www.haskell.org/pipermail/haskell-cafe/ ), but couldn't. What >> is the subject line? > > > "Top-level <-" _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From ashley at semantic.org Mon Sep 8 05:50:36 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Mon Sep 8 05:48:54 2008 Subject: old-locale Message-ID: The time package uses old-locale. "Old" sounds like it should be replaced. What's old-locale been replaced by? -- Ashley Yakeley From purestorm at ggnore.net Mon Sep 8 06:25:06 2008 From: purestorm at ggnore.net (Manuel Holtgrewe) Date: Mon Sep 8 06:23:02 2008 Subject: Is Parsec's ParserError missing an Eq instance Message-ID: Hi I am trying to use HUnit to test my Parsec-based parsers. I have the following code: import Text.ParserCombinators.Parsec import Test.HUnit test1 = TestCase $ assertEqual "msg" (Right '1') (parse digit "error" "1") Running it gives the following error: HUnitParsec.hs:5:19: No instance for (Eq ParseError) arising from a use of `assertEqual' at HUnitParsec.hs:(5,19)- (8,32) Possible fix: add an instance declaration for (Eq ParseError) In the second argument of `($)', namely `assertEqual "msg" (Right '1') (parse digit "error" "1")' In the expression: TestCase $ assertEqual "msg" (Right '1') (parse digit "error" "1") In the definition of `test1': test1 = TestCase $ assertEqual "msg" (Right '1') (parse digit "error" "1") Is the missing Eq instance intentional? What is the recommended way to use HUnit to test Parsec parsers? Bests, Manuel From qdunkan at gmail.com Mon Sep 8 18:46:59 2008 From: qdunkan at gmail.com (Evan Laforge) Date: Mon Sep 8 18:44:53 2008 Subject: export toDescList from Data.Map Message-ID: <2518b95d0809081546y42f85696h694c1003e82dc5de@mail.gmail.com> So, I mentioned this a long time ago but didn't get any responses and then I got distracted. So this time I added a ticket and patch and everything: 2580 Here's the text: It's even implemented, but not exported. Without this, there's apparently no way to iterate over a map from high to low, since foldl is also not exported. Also, I implemented a toDescList for IntMap, and could do the same for Set, and could add those patches, if people agree it's a good idea. In addition, is there any problem with exporting foldl aka descending for the three modules? I implemented a foldl for IntMap and it seems to work, but I'd want someone smarter to look for problems with it. In addition, Set and Map are inconsistent with folds: Set exports 'fold' and says "no order is guaranteed", but it's just defined to foldr, which is in ascending order. Set.foldr itself is not exported. Meanwhile, Map also exports fold, but heavily implies from the doc that it's guaranteed to be ascending. Would it restrict implementation changes too much to export a descending fold for all three? Other languages that have tree oriented general purpose maps all let you start anywhere and iterate in either direction. Anyway, is 2-3 weeks ok for discussion period? The library submission wiki doesn't say how long. From benjovi at gmx.net Wed Sep 10 14:06:50 2008 From: benjovi at gmx.net (Benedikt Huber) Date: Wed Sep 10 14:04:43 2008 Subject: export toDescList from Data.Map In-Reply-To: <2518b95d0809081546y42f85696h694c1003e82dc5de@mail.gmail.com> References: <2518b95d0809081546y42f85696h694c1003e82dc5de@mail.gmail.com> Message-ID: <48C80CBA.9050507@gmx.net> Evan Laforge schrieb: > So, I mentioned this a long time ago but didn't get any responses and > then I got distracted. So this time I added a ticket and patch and > everything: 2580 > > Here's the text: > It's even implemented, but not exported. Without this, there's > apparently no way to iterate over a map from high to low, since foldl > is also not exported. Hi, foldl is available via the Foldable instance for Set,Map,IntMap. And if I'm not mistaken, a 'left fold' corresponds to 'iterate from low to high' (try foldlM failing on the first element). Anyway, while there is foldWithKey > toAscList = foldWithKey (\k v m -> (k,v) : m) [] _foldrWithKey_ seems to be missing for Map/IntMap. I don't know if there is a performance penalty using 'reverse . toAscList' (e.g. in monadic traversals which stop after a few elements), but I suppose you were talking about the API anyway. Finally, I'd like to see a view on the association list, something like > viewAssocs :: Map k v -> MapView (k,v) > instance Foldable MapView which would provide 'fold[lr]WithKey[M]' in a standard way. best regards, benedikt From garious at gmail.com Wed Sep 10 20:21:16 2008 From: garious at gmail.com (Greg Fitzgerald) Date: Wed Sep 10 20:19:02 2008 Subject: Is Parsec's ParserError missing an Eq instance In-Reply-To: References: Message-ID: <1f3dc80d0809101721h29d836b5ge37e3d3ea65024f@mail.gmail.com> Hi Manuel, > Is Parsec's ParserError missing an Eq instance > What is the recommended way to use HUnit to test Parsec parsers? In my project, I implemented Eq for ParseError locally. {-# OPTIONS_GHC -fno-warn-orphans #-} import Text.ParserCombinators.Parsec.Error(ParseError, Message, errorMessages, messageEq) instance Eq ParseError where a == b = errorMessages a == errorMessages b instance Eq Message where (==) = messageEq I don't know if it was intentionally left out or not. You might get more responses on Haskell-Cafe. -Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20080910/0ffcda77/attachment.htm From qdunkan at gmail.com Wed Sep 10 22:56:03 2008 From: qdunkan at gmail.com (Evan Laforge) Date: Wed Sep 10 22:53:51 2008 Subject: export toDescList from Data.Map In-Reply-To: <48C80CBA.9050507@gmx.net> References: <2518b95d0809081546y42f85696h694c1003e82dc5de@mail.gmail.com> <48C80CBA.9050507@gmx.net> Message-ID: <2518b95d0809101956v77cd1be0ye32ae18d92bb9f98@mail.gmail.com> On Wed, Sep 10, 2008 at 11:06 AM, Benedikt Huber wrote: > Evan Laforge schrieb: >> >> So, I mentioned this a long time ago but didn't get any responses and >> then I got distracted. So this time I added a ticket and patch and >> everything: 2580 >> >> Here's the text: >> It's even implemented, but not exported. Without this, there's >> apparently no way to iterate over a map from high to low, since foldl >> is also not exported. > > Hi, > foldl is available via the Foldable instance for Set,Map,IntMap. > And if I'm not mistaken, a 'left fold' corresponds to 'iterate from low to > high' (try foldlM failing on the first element). Oh right, I'm getting them backwards, because lists are build from back to front, so you apply the (:) from high to low, to generate a list from low to high efficiently. Then you iterate over that list from low to high, so high to low *application* via fold is actually low to high iteration via map... if I'm not even more confused now than before. But anyway, you're totally right about Foldable: 'take 10 $ Foldable.foldl (flip (:)) [] bigmap' seems to be quite fast and independent of the size of bigmap. > I don't know if there is a performance penalty using 'reverse . toAscList' > (e.g. in monadic traversals which stop after a few elements), but I suppose > you were talking about the API anyway. reverse has a large performance penalty since it has to generate an entire forward list and traverse the entire thing. Here's the cpu time output from first a head . toAscList, and then a head . reverse . toAscList: 3164 -> (0,0) 3164 -> (10000000,10000000) 5434 So since there's Foldable.foldl, I guess this isn't so pressing. I still argue that it's more straightforward to simply export toDescList (why implement it and then not export it?) rather than make people roll their own with Foldable. From qdunkan at gmail.com Thu Sep 11 00:39:58 2008 From: qdunkan at gmail.com (Evan Laforge) Date: Thu Sep 11 00:37:43 2008 Subject: export toDescList from Data.Map In-Reply-To: <2518b95d0809101956v77cd1be0ye32ae18d92bb9f98@mail.gmail.com> References: <2518b95d0809081546y42f85696h694c1003e82dc5de@mail.gmail.com> <48C80CBA.9050507@gmx.net> <2518b95d0809101956v77cd1be0ye32ae18d92bb9f98@mail.gmail.com> Message-ID: <2518b95d0809102139x65aea9a1rae2eb5cc7b9972e5@mail.gmail.com> > So since there's Foldable.foldl, I guess this isn't so pressing. I > still argue that it's more straightforward to simply export toDescList > (why implement it and then not export it?) rather than make people > roll their own with Foldable. Oh, except the key part, of course. So I guess we need toDescList after all. 'foldr' and 'foldl' are also defined in the module so I took the liberty of renaming them 'WithKey' and exporting foldlWithKey (foldrWithKey is already exported as plain foldWithKey). There's also a foldlStrict, but I don't want to get too tangled up with all these details when all I really want is toDescList. From magnus at therning.org Sat Sep 13 11:02:21 2008 From: magnus at therning.org (Magnus Therning) Date: Sat Sep 13 11:00:06 2008 Subject: Unhelpful library documentation In-Reply-To: <20080810194649.GB2585@craft> References: <20080809155101.GA13213@craft> <489DFEFD.3010107@therning.org> <20080810194649.GB2585@craft> Message-ID: <48CBD5FD.6060303@therning.org> Gwern Branwen wrote: > On 2008.08.09 21:33:01 +0100, Magnus Therning scribbled 4.2K characters: > ... > [..] >> I suppose something similar should be encouraged for libraries on >> Hackage as well. Here's what I'll do with the only library I have on >> there (dataenc): >> >> 1. Set the 'homepage' cabal property to point to the wiki page I >> created on the wiki to describe the library >> (http://www.haskell.org/haskellwiki/Library/Data_encoding). >> 2. Add a link in the Haddock comments of every module to point to the >> same page. >> >> /M >> > > A useful example; post a link to the Haddock when you do it, would you? > It took me a while to get around to get around to it, but now it's done. I've just pushed the code to http://code.haskell.org/dataenc/devo/ and the package is uploaded to hackage (http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dataenc-0.11.1). The documentation will be rebuilt soon (I hope :-). /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus?therning?org Jabber: magnus?therning?org http://therning.org/magnus Haskell is an even 'redder' pill than Lisp or Scheme. -- PaulPotts -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/libraries/attachments/20080913/5340e3fe/signature.bin From neil.mitchell.2 at credit-suisse.com Mon Sep 15 04:17:06 2008 From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil) Date: Mon Sep 15 04:14:59 2008 Subject: Time package broken with Windows and GHC Head Message-ID: <33A3F585590A6F4E81E3D45AA4A111C902CD39DB@ELON17P32001A.csfb.cs-group.com> Hi, Using GHC Head from Thursday, the Time package, as on Hackage, won't compile on Windows XP. There are some errors: In file included from cbits\HsTime.c:1:0: include\HsTime.h:16:0: error: syntax error before "int" cbits\HsTime.c: In function `get_current_timezone_seconds': cbits\HsTime.c:10:0: warning: implicit declaration of function `localtime' cbits\HsTime.c:10:0: warning: initialization makes pointer from integer without a cast cbits\HsTime.c:14:0: error: dereferencing pointer to incomplete type cbits\HsTime.c:24:0: error: `_tzname' undeclared (first use in this function) cbits\HsTime.c:24:0: error: (Each undeclared identifier is reported only once cbits\HsTime.c:24:0: error: for each function it appears in.) cbits\HsTime.c:25:0: error: `_timezone' undeclared (first use in this function) This is using a binary distribution, and using the darcs version of time. I don't know what these errors mean (or have time to investigate), and Ashley doesn't really have access to Windows at the moment. Thanks Neil ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== 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:04 2008 Subject: 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/libraries/attachments/20080915/19a7e702/attachment.htm From simonpj at microsoft.com Mon Sep 15 08:04:06 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Sep 15 08:01:40 2008 Subject: GHC version control Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D764A62C5@EA-EXMSG-C334.europe.corp.microsoft.com> Friends A few weeks back, we had a lively debate about what version control system to use for GHC. In the light of that discussion we promised a revised proposal. This is it. (We also promised a proposal about the build system: the final version is here: http://hackage.haskell.org/trac/ghc/wiki/Design/BuildSystem) Constructive comments welcomed! Simon GHC Version Control proposal: Sept 2008 * We still want to move from Darcs to Git for GHC itself. The recent flurry of work on Darcs is very encouraging, but GHC is a particularly high-end client, and taking a direct dependency leads to stress at both ends. * We do not plan to change before the 6.10 release. Doing so would be destabilising at a time when we are trying to stabilise; and we need to devote all our active cycles to getting 6.10 out. Yes, that means it'll be more painful to move patches from the (Git) HEAD to the (Darcs) 6.10 branch, but we'll put up with that. We'll delay the change until the 6.10 branch seems to have settled down; i.e. roughly 6.10.2. * A very desirable goal is that it be possible to build GHC with only Git, rather than requiring every developer to actively use both Darcs and Git. But, many of the libraries are maintained by others (notably Cabal) who, for good reasons, do not want to move. In what follows the "Boot Libraries" are the ones required to build GHC. * So we propose the following: - The GHC repo will be in Git - Each Boot Library will (a) either be mastered in Git, with a read-only Darcs mirror (b) or be mastered in Darcs, with a read-only Git mirror (c) or be mastered in Darcs, with an occasional, manual process to copy a snapshot of the library from Darcs into GHC's Git repo. (Those Git files should be considered read-only.) - That means that if we want to modify a Darcs-mastered library we'll have to get the Darcs version, make the patch, test it, push it, and then the Git mirror will be right. Inconvenient, but we can live with that. We might even arrange it to be possible for super-developers to use the Darcs repo (rather than the mirror) direct from their tree. Ordinary developers can continue to be Git-only. - The same issue will arise for other people who want to modify a Git-mastered package. - Which is which will be decided on a case-by-case basis. The main criterion is: is GHC a passive client of the library, which is maintained by someone else (e.g. Cabal, containers), or is the library intimately coupled with GHC's inner workings (e.g. template-haskell)? If in doubt we should resolve ties in favour of darcs; we can always change our minds later, but changing and then changing back would be silly. * Our specific proposals for the master VCS for each boot library are: hsc2hs darcs haddock2 either: up to David Waern packages/array git packages/base git packages/base3-compat git packages/bytestring darcs packages/Cabal darcs packages/containers darcs packages/directory darcs packages/editline darcs packages/filepath darcs packages/ghc-prim git packages/haskell98 darcs packages/hpc either: up to Andy Gill packages/integer-gmp git packages/old-locale darcs packages/old-time darcs packages/packedstring darcs packages/pretty darcs packages/process git packages/random darcs packages/syb either: up to Utrecht packages/template-haskell git packages/unix git packages/Win32 git * Of these, probably the only contentious one is 'base', which is both very tightly coupled to GHC, but also used by nhc and Hugs. We humbly beg indulgence from Malcolm and Ross, and hope that the Darcs mirror be acceptable. They have kindly offered such indulgence! * array, process, unix, Win32 are also somewhat less obvious, but they are quite intimately connected to GHC From chak at cse.unsw.edu.au Mon Sep 15 20:58:49 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Mon Sep 15 20:56:22 2008 Subject: GHC version control In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32D764A62C5@EA-EXMSG-C334.europe.corp.microsoft.com> References: <638ABD0A29C8884A91BC5FB5C349B1C32D764A62C5@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: Simon Peyton-Jones wrote: > In what follows the "Boot Libraries" are the ones required to build > GHC. > > * So we propose the following: > - The GHC repo will be in Git > > - Each Boot Library will > (a) either be mastered in Git, with a read-only Darcs mirror > (b) or be mastered in Darcs, with a read-only Git mirror > (c) or be mastered in Darcs, with an occasional, manual > process to copy a snapshot of the library from Darcs > into GHC's Git repo. (Those Git files should be > considered read-only.) For (b), will the Git-mirror be automatically updated or patches from darcs be pulled manually? > - That means that if we want to modify a Darcs-mastered library > we'll have to get the Darcs version, make the patch, test it, > push it, and then the Git mirror will be right. Inconvenient, > but we can live with that. We might even arrange it to be > possible > for super-developers to use the Darcs repo (rather than the > mirror) > direct from their tree. Ordinary developers can continue to be > Git-only. [..] > * Our specific proposals for the master VCS for each boot library are: > hsc2hs darcs > haddock2 either: up to David Waern > packages/array git > packages/base git > packages/base3-compat git > packages/bytestring darcs > packages/Cabal darcs > packages/containers darcs > packages/directory darcs > packages/editline darcs > packages/filepath darcs > packages/ghc-prim git > packages/haskell98 darcs > packages/hpc either: up to Andy Gill > packages/integer-gmp git > packages/old-locale darcs > packages/old-time darcs > packages/packedstring darcs > packages/pretty darcs > packages/process git > packages/random darcs > packages/syb either: up to Utrecht > packages/template-haskell git > packages/unix git > packages/Win32 git You do not distinguish between (b) and (c) in that list. Personally, I think, every (b) library is a Bad Thing if the Git-mirror update is *automatic*. Why? The setup discourages the library developer from validating their library changes against the GHC build. In other words, every single library that is marked as "darcs" above should be used by ghc at arms length. That is, ghc should not use the bleeding edge development version, but the latest stable version (or something similar). When there is a new stable version, the person maintaining the GHC Git mirror of the library ought to validate GHC with the new library version and only then update the mirror (or the in-place copy in GHC's Git repo). If it is not possible to use a library's latest stable version, the library is too tightly coupled with GHC to live in a darcs repo. Manuel From iavor.diatchki at gmail.com Mon Sep 15 23:56:31 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Mon Sep 15 23:54:01 2008 Subject: GHC version control In-Reply-To: References: <638ABD0A29C8884A91BC5FB5C349B1C32D764A62C5@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <5ab17e790809152056g15fd0a45x91014666968834fb@mail.gmail.com> Hello, The mirroring idea seems complex and fragile. Is there a reason why GHC has to depend on the repository versions of the "external" (i.e., the ones marked with 'darcs') packages? It seems to me that it should be possible (and desirable!) to make GHC depend on particular released versions of those packages, and so the source could be obtained in the same way that it is for other Haskell programs (e.g., hackage). Then, the revision control system used to maintain those packages would not be important from the point of view of GHC. -Iavor On Mon, Sep 15, 2008 at 5:58 PM, Manuel M T Chakravarty wrote: > Simon Peyton-Jones wrote: >> >> In what follows the "Boot Libraries" are the ones required to build GHC. >> >> * So we propose the following: >> - The GHC repo will be in Git >> >> - Each Boot Library will >> (a) either be mastered in Git, with a read-only Darcs mirror >> (b) or be mastered in Darcs, with a read-only Git mirror >> (c) or be mastered in Darcs, with an occasional, manual >> process to copy a snapshot of the library from Darcs >> into GHC's Git repo. (Those Git files should be >> considered read-only.) > > For (b), will the Git-mirror be automatically updated or patches from darcs > be pulled manually? > >> - That means that if we want to modify a Darcs-mastered library >> we'll have to get the Darcs version, make the patch, test it, >> push it, and then the Git mirror will be right. Inconvenient, >> but we can live with that. We might even arrange it to be possible >> for super-developers to use the Darcs repo (rather than the mirror) >> direct from their tree. Ordinary developers can continue to be >> Git-only. > > [..] >> >> * Our specific proposals for the master VCS for each boot library are: >> hsc2hs darcs >> haddock2 either: up to David Waern >> packages/array git >> packages/base git >> packages/base3-compat git >> packages/bytestring darcs >> packages/Cabal darcs >> packages/containers darcs >> packages/directory darcs >> packages/editline darcs >> packages/filepath darcs >> packages/ghc-prim git >> packages/haskell98 darcs >> packages/hpc either: up to Andy Gill >> packages/integer-gmp git >> packages/old-locale darcs >> packages/old-time darcs >> packages/packedstring darcs >> packages/pretty darcs >> packages/process git >> packages/random darcs >> packages/syb either: up to Utrecht >> packages/template-haskell git >> packages/unix git >> packages/Win32 git > > You do not distinguish between (b) and (c) in that list. Personally, I > think, every (b) library is a Bad Thing if the Git-mirror update is > *automatic*. Why? The setup discourages the library developer from > validating their library changes against the GHC build. > > In other words, every single library that is marked as "darcs" above should > be used by ghc at arms length. That is, ghc should not use the bleeding > edge development version, but the latest stable version (or something > similar). When there is a new stable version, the person maintaining the > GHC Git mirror of the library ought to validate GHC with the new library > version and only then update the mirror (or the in-place copy in GHC's Git > repo). If it is not possible to use a library's latest stable version, the > library is too tightly coupled with GHC to live in a darcs repo. > > Manuel > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From judah.jacobson at gmail.com Tue Sep 16 01:14:46 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Tue Sep 16 01:12:16 2008 Subject: Following up on a patch for the network package (trac #2005) Message-ID: <6d74b0d20809152214s36901a05r361f074772dfa50c@mail.gmail.com> Hi all, A few weeks ago I proposed a (1-line) patch to the network package to fix trac bug #2005 (getnameinfo error on OS X): http://www.haskell.org/pipermail/libraries/2008-July/010239.html And then I forgot about it until today; looks like it's been sitting in limbo since I sent it. Any chance of this making it into 6.10.1? Thanks, -Judah From chak at cse.unsw.edu.au Tue Sep 16 02:01:55 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Sep 16 01:59:32 2008 Subject: GHC version control In-Reply-To: <5ab17e790809152056g15fd0a45x91014666968834fb@mail.gmail.com> References: <638ABD0A29C8884A91BC5FB5C349B1C32D764A62C5@EA-EXMSG-C334.europe.corp.microsoft.com> <5ab17e790809152056g15fd0a45x91014666968834fb@mail.gmail.com> Message-ID: <5F41C28B-76E2-4D70-99AF-65006890B7E9@cse.unsw.edu.au> Iavor Diatchki wrote: > The mirroring idea seems complex and fragile. Is there a reason why > GHC has to depend on the repository versions of the "external" (i.e., > the ones marked with 'darcs') packages? It seems to me that it should > be possible (and desirable!) to make GHC depend on particular released > versions of those packages, and so the source could be obtained in the > same way that it is for other Haskell programs (e.g., hackage). Then, > the revision control system used to maintain those packages would not > be important from the point of view of GHC. That is basically what I meant to say, too. Only Iavor says it more clearly! Manuel > On Mon, Sep 15, 2008 at 5:58 PM, Manuel M T Chakravarty > wrote: >> Simon Peyton-Jones wrote: >>> >>> In what follows the "Boot Libraries" are the ones required to >>> build GHC. >>> >>> * So we propose the following: >>> - The GHC repo will be in Git >>> >>> - Each Boot Library will >>> (a) either be mastered in Git, with a read-only Darcs mirror >>> (b) or be mastered in Darcs, with a read-only Git mirror >>> (c) or be mastered in Darcs, with an occasional, manual >>> process to copy a snapshot of the library from Darcs >>> into GHC's Git repo. (Those Git files should be >>> considered read-only.) >> >> For (b), will the Git-mirror be automatically updated or patches >> from darcs >> be pulled manually? >> >>> - That means that if we want to modify a Darcs-mastered library >>> we'll have to get the Darcs version, make the patch, test it, >>> push it, and then the Git mirror will be right. Inconvenient, >>> but we can live with that. We might even arrange it to be >>> possible >>> for super-developers to use the Darcs repo (rather than the >>> mirror) >>> direct from their tree. Ordinary developers can continue to be >>> Git-only. >> >> [..] >>> >>> * Our specific proposals for the master VCS for each boot library >>> are: >>> hsc2hs darcs >>> haddock2 either: up to David Waern >>> packages/array git >>> packages/base git >>> packages/base3-compat git >>> packages/bytestring darcs >>> packages/Cabal darcs >>> packages/containers darcs >>> packages/directory darcs >>> packages/editline darcs >>> packages/filepath darcs >>> packages/ghc-prim git >>> packages/haskell98 darcs >>> packages/hpc either: up to Andy Gill >>> packages/integer-gmp git >>> packages/old-locale darcs >>> packages/old-time darcs >>> packages/packedstring darcs >>> packages/pretty darcs >>> packages/process git >>> packages/random darcs >>> packages/syb either: up to Utrecht >>> packages/template-haskell git >>> packages/unix git >>> packages/Win32 git >> >> You do not distinguish between (b) and (c) in that list. >> Personally, I >> think, every (b) library is a Bad Thing if the Git-mirror update is >> *automatic*. Why? The setup discourages the library developer from >> validating their library changes against the GHC build. >> >> In other words, every single library that is marked as "darcs" >> above should >> be used by ghc at arms length. That is, ghc should not use the >> bleeding >> edge development version, but the latest stable version (or >> something >> similar). When there is a new stable version, the person >> maintaining the >> GHC Git mirror of the library ought to validate GHC with the new >> library >> version and only then update the mirror (or the in-place copy in >> GHC's Git >> repo). If it is not possible to use a library's latest stable >> version, the >> library is too tightly coupled with GHC to live in a darcs repo. >> >> Manuel >> >> _______________________________________________ >> Libraries mailing list >> Libraries@haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries From ross at soi.city.ac.uk Tue Sep 16 04:41:33 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Sep 16 04:39:08 2008 Subject: Splitting SYB from the base package in GHC 6.10 In-Reply-To: <52f14b210809150428w4cd4061bg4b855fc44ac11b28@mail.gmail.com> References: <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> <52f14b210809150428w4cd4061bg4b855fc44ac11b28@mail.gmail.com> Message-ID: <20080916084133.GA2878@soi.city.ac.uk> On Mon, Sep 15, 2008 at 01:28:30PM +0200, Jos? Pedro Magalh?es wrote: > 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. Sounds good. Those that remain in base need no longer be orphans. Regarding Complex, I think your point that it exports (:+) determines that the derived instance is appropriate. > * 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 I'd lean slightly toward keeping with their definitions in base, but it's not a blocker like the others. What shall we call the module defining the Data class? Data.Data? From marlowsd at gmail.com Tue Sep 16 10:21:28 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Sep 16 10:19:12 2008 Subject: GHC version control In-Reply-To: <5F41C28B-76E2-4D70-99AF-65006890B7E9@cse.unsw.edu.au> References: <638ABD0A29C8884A91BC5FB5C349B1C32D764A62C5@EA-EXMSG-C334.europe.corp.microsoft.com> <5ab17e790809152056g15fd0a45x91014666968834fb@mail.gmail.com> <5F41C28B-76E2-4D70-99AF-65006890B7E9@cse.unsw.edu.au> Message-ID: <48CFC0E8.1060606@gmail.com> Manuel M T Chakravarty wrote: > Iavor Diatchki wrote: >> The mirroring idea seems complex and fragile. Is there a reason why >> GHC has to depend on the repository versions of the "external" (i.e., >> the ones marked with 'darcs') packages? It seems to me that it should >> be possible (and desirable!) to make GHC depend on particular released >> versions of those packages, and so the source could be obtained in the >> same way that it is for other Haskell programs (e.g., hackage). Then, >> the revision control system used to maintain those packages would not >> be important from the point of view of GHC. > > That is basically what I meant to say, too. Only Iavor says it more > clearly! Which is basically suggesting that there should be no (b) packages, only (c) (using the classification from Simon's email below). I think that is probably ok, and desirable as it reduces the number of different scenarios that the GHC developer has to think about. For the (c) packages where the GHC git repo contains a snapshot of the package, I can imagine also checking out the darcs repo into the GHC tree in order to work on the library, and as long as git ignores the _darcs directory everything should work fine. We can push changes to darcs, and also commit the new snapshot with git in the same tree. Of course, we don't plan to do this often, because we'll be using released versions of these packages. But I can imagine it being useful sometimes: for example, we'll need to work on Cabal a bit for the new build system, but after that I hope we'll be more decoupled from it. Cheers, Simon > Manuel > >> On Mon, Sep 15, 2008 at 5:58 PM, Manuel M T Chakravarty >> wrote: >>> Simon Peyton-Jones wrote: >>>> >>>> In what follows the "Boot Libraries" are the ones required to build >>>> GHC. >>>> >>>> * So we propose the following: >>>> - The GHC repo will be in Git >>>> >>>> - Each Boot Library will >>>> (a) either be mastered in Git, with a read-only Darcs mirror >>>> (b) or be mastered in Darcs, with a read-only Git mirror >>>> (c) or be mastered in Darcs, with an occasional, manual >>>> process to copy a snapshot of the library from Darcs >>>> into GHC's Git repo. (Those Git files should be >>>> considered read-only.) >>> >>> For (b), will the Git-mirror be automatically updated or patches from >>> darcs >>> be pulled manually? >>> >>>> - That means that if we want to modify a Darcs-mastered library >>>> we'll have to get the Darcs version, make the patch, test it, >>>> push it, and then the Git mirror will be right. Inconvenient, >>>> but we can live with that. We might even arrange it to be possible >>>> for super-developers to use the Darcs repo (rather than the mirror) >>>> direct from their tree. Ordinary developers can continue to be >>>> Git-only. >>> >>> [..] >>>> >>>> * Our specific proposals for the master VCS for each boot library are: >>>> hsc2hs darcs >>>> haddock2 either: up to David Waern >>>> packages/array git >>>> packages/base git >>>> packages/base3-compat git >>>> packages/bytestring darcs >>>> packages/Cabal darcs >>>> packages/containers darcs >>>> packages/directory darcs >>>> packages/editline darcs >>>> packages/filepath darcs >>>> packages/ghc-prim git >>>> packages/haskell98 darcs >>>> packages/hpc either: up to Andy Gill >>>> packages/integer-gmp git >>>> packages/old-locale darcs >>>> packages/old-time darcs >>>> packages/packedstring darcs >>>> packages/pretty darcs >>>> packages/process git >>>> packages/random darcs >>>> packages/syb either: up to Utrecht >>>> packages/template-haskell git >>>> packages/unix git >>>> packages/Win32 git >>> >>> You do not distinguish between (b) and (c) in that list. Personally, I >>> think, every (b) library is a Bad Thing if the Git-mirror update is >>> *automatic*. Why? The setup discourages the library developer from >>> validating their library changes against the GHC build. >>> >>> In other words, every single library that is marked as "darcs" above >>> should >>> be used by ghc at arms length. That is, ghc should not use the bleeding >>> edge development version, but the latest stable version (or something >>> similar). When there is a new stable version, the person maintaining >>> the >>> GHC Git mirror of the library ought to validate GHC with the new library >>> version and only then update the mirror (or the in-place copy in >>> GHC's Git >>> repo). If it is not possible to use a library's latest stable >>> version, the >>> library is too tightly coupled with GHC to live in a darcs repo. >>> >>> Manuel >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries@haskell.org >>> http://www.haskell.org/mailman/listinfo/libraries >>> >> _______________________________________________ >> Libraries mailing list >> Libraries@haskell.org >> http://www.haskell.org/mailman/listinfo/libraries > > _______________________________________________ > Cvs-ghc mailing list > Cvs-ghc@haskell.org > http://www.haskell.org/mailman/listinfo/cvs-ghc From marco-oweber at gmx.de Wed Sep 17 20:32:45 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Wed Sep 17 20:30:11 2008 Subject: (lib network) Should inet_aton be called instead of inet_addr ? Message-ID: <20080918003245.GC25870@gmx.de> Hi @ll Reading http://linux.die.net/man/3/inet_addr I noticed that inet_addr is obsolete and inet_aton should be used because inet_addr indicates error by returning -1 which is a valid address (255.255.255.0) as well. Don't know wether it's worth changing or wether inet_aton is peresent on all systems Marc Weber From marco-oweber at gmx.de Thu Sep 18 09:24:21 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Thu Sep 18 09:21:46 2008 Subject: (lib network) Should inet_aton be called instead of inet_addr ? In-Reply-To: <20080918003245.GC25870@gmx.de> References: <20080918003245.GC25870@gmx.de> Message-ID: <20080918132421.GA18837@gmx.de> On Thu, Sep 18, 2008 at 02:32:45AM +0200, Marc Weber wrote: > Hi @ll > > Reading http://linux.die.net/man/3/inet_addr I noticed that > inet_addr is obsolete and inet_aton should be used because inet_addr > indicates error by returning -1 which is a valid address (255.255.255.0) > as well. > Don't know wether it's worth changing or wether inet_aton is peresent on > all systems I'd also suggest to change inet_addr :: String -> IO HostAddress -- throwing user exception to inet_addr :: String -> IO (Maybe HostAddress) -- not throwing any exception or inet_addr :: String -> IO (Either String HostAddress) -- not throwing any exception because the latter can be type checked the first one not.. The problem with the first one is that using a custom exception (which is easy when extensible extensions become standard) would be a better choice. But changing the exception type would break libraries. Using a return type of Maybe would never ever break things again See also my last post on haskell-cafe Marc From claus.reinke at talk21.com Fri Sep 19 05:31:38 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Fri Sep 19 05:29:08 2008 Subject: please check: are any of these warnings affecting your package? warnings during make (ghc head, windows) Message-ID: <71CC6562994343D695F7DBDE1D97E062@cr3lt> (copying to libraries, because many of these warnings come from extralibs) With the ghc release candidate coming up soon, it might be a good time to look at warnings? In a ghc head build on windows, there are many of them, even though ghc and the core libs have undergone a lot of cleaning. Even if I ignore ghc warnings like 'defined, but not used' 'binding shadowed', 'non-exhaustive match' (!), 'defaulting to', 'orphan instance', 'no type signature', etc., there are plenty of warnings left, some of which slightly worrying, suggesting include/documentation/cabal/deprecation trouble. Starting with only those matching '^Warning:', and listing only examples for each kind of warning, there are things like Warning: 'include-dirs: ../libraries/base/cbits' is a relative path outside of Warning: 'include-dirs: ../libraries/base/include' is a relative path outside Warning: 'include-dirs: stage2plus' directory does not exist. Warning: This package indirectly depends on multiple versions of the same Warning: HUnit.cabal: A package using section syntax should require Warning: defaultUserHooks in Setup script is deprecated. Warning: The documentation for the following packages are not installed. No (this is mostly rts, but also a couple of base-3) Warning: in export list of "GHC.Base": module not found: "GHC.Bool" Warning: in export list of "Data.Generics.Basics": module not found: "Data.Typeable" Warning: base:Control.Monad: could not find link destinations for: Data.Traversable.Id GHC.Arr.Array Data.Traversable.StateL Data.Traversable.StateR Text.ParserCombinators.ReadP.P (these are from a local build of ghc+extralibs on windows, yesterday, but there are also buildbot logs from a successful build: http://darcs.haskell.org/buildbot/head/builders/x86%20Windows%20head/builds/505 ) There are other warnings, too, eg: libtool: link: warning: undefined symbols not allowed in i386-unknown-mingw32 shared libraries ar cru .libs/libffi.a src/debug.o src/prep_cif.o src/types.o src/raw_api.o src/java_raw_api.o src/closures.o src/x86/ffi.o src/x86/win32.o libtool: install: warning: remember to run `libtool --finish /usr/local/lib' (on windows???) warning: implicit declaration of function `reallocf' warning: assignment makes pointer from integer without a cast Should I be worried?-) Claus From haskell at list.mightyreason.com Sat Sep 20 14:06:50 2008 From: haskell at list.mightyreason.com (ChrisK) Date: Sat Sep 20 14:04:09 2008 Subject: ANNOUNCE: protocol-buffers-0.2.9 for Haskell is ready Message-ID: <48D53BBA.10101@list.mightyreason.com> Hello one and all, Amid much rejoicing, my Haskell version of protocol-buffer is now released (version 0.2.9). What is this for? What does it do? Why? Shorter answer: It generates Haskell data types that can be converted back and forth to lazy ByteStrings that interoperate with Google's generated code in C++/Java/python. It is a pure Haskell re-implementation of the Google code at http://code.Google.com/apis/protocolbuffers/docs/overview.html which is "...a language-neutral, platform-neutral, extensible way of serializing structured data for use in communications protocols, data storage, and more." Google's project produces C++, Java, and Python code. This one produces Haskell code. The release tarball (with 3 Haskell packages inside, see README in source) is at http://hackage.haskell.org/cgi-bin/hackage-scripts/package/protocol-buffers The darcs repository has moved to http://darcs.haskell.org/packages/protocol-buffers2/ You will also need a recent ghc compiler, the "binary" package and the "utf8-string" package from hackage.haskell.org (same site as mentioned above). The source compiles to 3 things: 1) the package "protocol-buffers" with the library API 2) the package "protocol-buffers-descriptor" with the descriptor.proto code 3) The 'hprotoc' executable which is a command line program similar to 'protoc'. The "examples" sub-directory in the code has the Haskell version of the "addressbook.proto" example and is compatible with Google's similar example code. The code generated from unittest.proto (and unittest_import.proto) includes messages TestAllTypes and TestAllExtensions which have been extensively tested by QuickCheck to ensure they can be wire encoded and decoded (see the "tests" sub-directory in the code). The user API, as exported by Text.ProtocolBuffers, allows for converting messages back and forth to the lazy ByteString type. And such messages can be merged, and the defaults accessed via the MessageAPI type class. The messages in Haskell as just regular data types and are thus immutable. Required types are simple record fields, optional types are Maybe, and repeated types are Seq (from Data.Sequence). Extensions are supported via Key data that allows access to the extension fields. Extensible messages contain an opaque ext'field entry of type ExtField that contains the map data structure to contain the extension field values. The User API allows for serializing messages as the usual series of fields. It also provides for a length prefix to be written to create delimited messages. It also provides to write a wire tag with any field number before the length and message data. This last form looks like a field on the wire, and there is a special api call to read back just the one message and its field number. This last API is similar to the one that is part of the C# API. No benchmarks have been run yet. Any suggestions? Unsupported for the moment is loading and storing "unknown" fields. It can be added sooner if someone has a use for this. Unsupported indefinitely is code generation for Services and Methods. I have yet to look into how this is presented in the other languages. The API to read a single message field, as mentioned above, might be extended to read any type instead of just messages. optional clever_quote { Perl: "Easy things are easy, hard things are possible" Haskell: "Hard things are easy, the impossible just happened" } Cheers! Chris Kuklewicz From dons at galois.com Sat Sep 20 14:09:15 2008 From: dons at galois.com (Don Stewart) Date: Sat Sep 20 14:06:22 2008 Subject: ANNOUNCE: protocol-buffers-0.2.9 for Haskell is ready In-Reply-To: <48D53BBA.10101@list.mightyreason.com> References: <48D53BBA.10101@list.mightyreason.com> Message-ID: <20080920180915.GB18629@scytale.galois.com> haskell: > Hello one and all, > > Amid much rejoicing, my Haskell version of protocol-buffer is now > released (version 0.2.9). Find it on Arch Linux, http://aur.archlinux.org/packages.php?ID=20080 Go Go Go! -- Don From dons at galois.com Sat Sep 20 15:02:56 2008 From: dons at galois.com (Don Stewart) Date: Sat Sep 20 15:00:05 2008 Subject: Arch Haskell News: Sep 20 2008 Message-ID: <20080920190256.GC18629@scytale.galois.com> Highlights, * 576 packages now, up 13 from last week. Noteworthy, * hmpf:?Haskell binding to MPFR library? * protocol-buffers:?Parse Google Protocol Buffer specifications? * fckeditor:?Server-Side Integration for FCKeditor? * twidge:?Unix Command-Line Twitter and Identica Client? Full update list, http://archhaskell.wordpress.com/2008/09/20/arch-haskell-news-sep-20-2008/ -- Don From kolmodin at dtek.chalmers.se Sun Sep 21 09:36:40 2008 From: kolmodin at dtek.chalmers.se (Lennart Kolmodin) Date: Sun Sep 21 09:21:42 2008 Subject: ANNOUNCE: protocol-buffers-0.2.9 for Haskell is ready In-Reply-To: <20080920180915.GB18629@scytale.galois.com> References: <48D53BBA.10101@list.mightyreason.com> <20080920180915.GB18629@scytale.galois.com> Message-ID: <48D64DE8.90602@dtek.chalmers.se> Don Stewart wrote: > haskell: >> Hello one and all, >> >> Amid much rejoicing, my Haskell version of protocol-buffer is now >> released (version 0.2.9). > > Find it on Arch Linux, > > http://aur.archlinux.org/packages.php?ID=20080 > > Go Go Go! Now also available in Gentoo Linux, along with the bundled lib protocol-buffers-descriptor and the tool hprotoc. Get it from the haskell overlay * dev-haskell/protocol-buffers * dev-haskell/protocol-buffers-descriptor * dev-haskell/hprotoc It's noticeable that we too were required the -fvia-C flag to build protocol-buffers package. I'm using GHC 6.8.3 on amd64. Without it, ghc died with the following error message: /tmp/ghc20461_0/ghc20461_0.s: Assembler messages: /tmp/ghc20461_0/ghc20461_0.s:6993:0: Error: too many memory references for `movzbl' /tmp/ghc20461_0/ghc20461_0.s:6994:0: Error: suffix or operands invalid for `shl' /tmp/ghc20461_0/ghc20461_0.s:6995:0: Error: suffix or operands invalid for `or' We also apply the following (tiny) patch to get hprotoc to compile: http://code.haskell.org/gentoo/gentoo-haskell/dev-haskell/hprotoc/files/hprotoc-0.2.9-genparser.patch diff -rN -u old-protocol-buffers-0.2.9/hprotoc/Text/ProtocolBuffers/ProtoCompile/Parser.hs new-protocol-buffers-0.2.9/hprotoc/Text/ProtocolBuffers/ProtoCompile/Parser.hs --- old-protocol-buffers-0.2.9/hprotoc/Text/ProtocolBuffers/ProtoCompile/Parser.hs 2008-09-21 15:16:08.000000000 +0200 +++ new-protocol-buffers-0.2.9/hprotoc/Text/ProtocolBuffers/ProtoCompile/Parser.hs 2008-09-21 15:16:08.000000000 +0200 @@ -45,7 +45,7 @@ default () -type P = GenParser Lexed +type P a = GenParser Lexed a pbParse :: String -> IO (Either ParseError D.FileDescriptorProto) pbParse filename = fmap (parseProto filename) (LC.readFile filename) Cheers, Lennart Kolmodin From kolmodin at dtek.chalmers.se Sun Sep 21 09:48:25 2008 From: kolmodin at dtek.chalmers.se (Lennart Kolmodin) Date: Sun Sep 21 09:33:22 2008 Subject: ANNOUNCE: protocol-buffers-0.2.9 for Haskell is ready In-Reply-To: <48D64DE8.90602@dtek.chalmers.se> References: <48D53BBA.10101@list.mightyreason.com> <20080920180915.GB18629@scytale.galois.com> <48D64DE8.90602@dtek.chalmers.se> Message-ID: <48D650A9.2080507@dtek.chalmers.se> Lennart Kolmodin wrote: > Don Stewart wrote: >> haskell: >>> Hello one and all, >>> >>> Amid much rejoicing, my Haskell version of protocol-buffer is now >>> released (version 0.2.9). >> >> Find it on Arch Linux, >> >> http://aur.archlinux.org/packages.php?ID=20080 >> >> Go Go Go! > > Now also available in Gentoo Linux, along with the bundled lib > protocol-buffers-descriptor and the tool hprotoc. > > Get it from the haskell overlay > * dev-haskell/protocol-buffers > * dev-haskell/protocol-buffers-descriptor > * dev-haskell/hprotoc Also, sharing the same tarball for different libs and applications makes automation of packaging slightly harder for us. This one I had to do partly by hand. Splitting the tarball into three packages would also allow users to install them directly by using cabal-install. I'd recommend it. Cheers, Lennart K From jeff at nokrev.com Sun Sep 21 11:14:35 2008 From: jeff at nokrev.com (Jeff Wheeler) Date: Sun Sep 21 11:11:49 2008 Subject: HOC Packaging Message-ID: <0E868FD7-5019-40FD-AFF2-B634B8E360EE@nokrev.com> Hey, I've frequently been frustrated by HOC (Haskell Objective-C bindings), and I wonder if it is possible to cabalize it into the few packages (HOC, HOC-*) and put it on Hackage. It seems this is not done now so that the bindings can exactly match the interfaces on the system to which it is installed, which makes sense. However, it seems like on most all the systems (standard, up-to- date OS X machines), these interfaces are identical and do not need to be manually recreated by each individual on their own machine. Is it not possible to upload the packages for the latest OS X, and merely update it on *.0 releases? Jeff Wheeler From haskell at list.mightyreason.com Sun Sep 21 12:37:33 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Sun Sep 21 12:34:48 2008 Subject: ANNOUNCE: protocol-buffers-0.2.9 for Haskell is ready In-Reply-To: <48D650A9.2080507@dtek.chalmers.se> References: <48D53BBA.10101@list.mightyreason.com> <20080920180915.GB18629@scytale.galois.com> <48D64DE8.90602@dtek.chalmers.se> <48D650A9.2080507@dtek.chalmers.se> Message-ID: <48D6784D.7070101@list.mightyreason.com> Lennart Kolmodin wrote: > Lennart Kolmodin wrote: > > It's noticeable that we too were required the -fvia-C flag to build > protocol-buffers package. I'm using GHC 6.8.3 on amd64. Without it, ghc died > with the following error message: [snip] Perhaps an actual bug report should be made. However, I don't have time to reduce the test case at the moment. Also, I tried two tricks: (D# x) <-> (W64# x) which works fine (F# x) <-> (W32# x) which produced garbage, so I had to replace it with alloca/poke/peek. Does anyone have a clue why one works and one does not? > Also, sharing the same tarball for different libs and applications makes > automation of packaging slightly harder for us. This one I had to do > partly by hand. > > Splitting the tarball into three packages would also allow users to > install them directly by using cabal-install. > > I'd recommend it. I'll probable split it for a future release. Hopefully it is possible to have cabal patches contributed to allow ghc 6.6 to work. I have no idea if Hugs could work. Cheers Chris From igloo at earth.li Sun Sep 21 12:57:52 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Sep 21 12:55:04 2008 Subject: ANNOUNCE: protocol-buffers-0.2.9 for Haskell is ready In-Reply-To: <48D6784D.7070101@list.mightyreason.com> References: <48D53BBA.10101@list.mightyreason.com> <20080920180915.GB18629@scytale.galois.com> <48D64DE8.90602@dtek.chalmers.se> <48D650A9.2080507@dtek.chalmers.se> <48D6784D.7070101@list.mightyreason.com> Message-ID: <20080921165752.GA19677@matrix.chaos.earth.li> Hi Chris, On Sun, Sep 21, 2008 at 05:37:33PM +0100, Chris Kuklewicz wrote: > > Also, I tried two tricks: > (D# x) <-> (W64# x) which works fine > (F# x) <-> (W32# x) which produced garbage, so I had to replace it with > alloca/poke/peek. This isn't supported, and I suspect is the cause of the -fasm problems. Please see http://hackage.haskell.org/trac/ghc/ticket/2209 for more details and suggested alternative. Thanks Ian From haskell at list.mightyreason.com Mon Sep 22 06:48:16 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Mon Sep 22 06:45:59 2008 Subject: ANNOUNCE: protocol-buffers-0.2.9 for Haskell is ready In-Reply-To: <20080921165752.GA19677@matrix.chaos.earth.li> References: <48D53BBA.10101@list.mightyreason.com> <20080920180915.GB18629@scytale.galois.com> <48D64DE8.90602@dtek.chalmers.se> <48D650A9.2080507@dtek.chalmers.se> <48D6784D.7070101@list.mightyreason.com> <20080921165752.GA19677@matrix.chaos.earth.li> Message-ID: <48D777F0.7060907@list.mightyreason.com> I am cross-posting this message to several lists. I had learned the trick before the documentation was updated. It seems I have used a very unreliable trick. And the "use castToSTUArray" suggested alternative is a really poor one since I am not using arrays at all. Who can suggest a way to cast from Float to Word32 and Double to Word64 using ghc? The actual task is that I need to write out the Float as a little endian sequence of four bytes and also be able to read it back in. The writing and reading are done in Put and Get monads to ByteString (from the "binary" package). The alloca/poke/peek work around I have looks like castWord32ToFloat :: Word32 -> Float castWord32ToFloat x = unsafePerformIO $ alloca $ \p -> poke p x >> peek (castPtr p) castFloatToWord32 :: Float -> Word32 castFloatToWord32 x = unsafePerformIO $ alloca $ \p -> poke p x >> peek (castPtr p) The unsafeCoerce trick that is no longer working looks like: castWord64ToDouble :: Word64 -> Double castWord64ToDouble (W64# w) = D# (unsafeCoerce# w) castDoubleToWord64 :: Double -> Word64 castDoubleToWord64 (D# d) = W64# (unsafeCoerce# d) Any ideas? Or is the alloca trick the only way to do this? Chris Ian Lynagh wrote: > Hi Chris, > > On Sun, Sep 21, 2008 at 05:37:33PM +0100, Chris Kuklewicz wrote: >> Also, I tried two tricks: >> (D# x) <-> (W64# x) which works fine >> (F# x) <-> (W32# x) which produced garbage, so I had to replace it with >> alloca/poke/peek. > > This isn't supported, and I suspect is the cause of the -fasm problems. > > Please see > http://hackage.haskell.org/trac/ghc/ticket/2209 > for more details and suggested alternative. > > > Thanks > Ian > From gale at sefer.org Mon Sep 22 07:12:57 2008 From: gale at sefer.org (Yitzchak Gale) Date: Mon Sep 22 07:10:17 2008 Subject: [Haskell-cafe] Re: ANNOUNCE: protocol-buffers-0.2.9 for Haskell is ready In-Reply-To: <48D777F0.7060907@list.mightyreason.com> References: <48D53BBA.10101@list.mightyreason.com> <20080920180915.GB18629@scytale.galois.com> <48D64DE8.90602@dtek.chalmers.se> <48D650A9.2080507@dtek.chalmers.se> <48D6784D.7070101@list.mightyreason.com> <20080921165752.GA19677@matrix.chaos.earth.li> <48D777F0.7060907@list.mightyreason.com> Message-ID: <2608b8a80809220412i64a77870ufb58cf2a1f734f0e@mail.gmail.com> Chris Kuklewicz wrote: > Who can suggest a way to cast from Float to Word32 and Double to Word64 > using ghc? The actual task is that I need to write out the Float as a > little endian sequence of four bytes and also be able to read it back in. > The writing and reading are done in Put and Get monads to ByteString (from > the "binary" package). I think alloca-like hacks is really the wrong direction and asking for trouble. You are trying to translate between platform-dependent native floats, and IEEE floats in a specified platform-independent binary format for Google. So use encodeFloat/decodeFloat - fast primitives in GHC - on the native side, and a hand-written Binary instance for the exact format you need on the Google side. My opinion, YMMV. Regards, Yitz From igloo at earth.li Mon Sep 22 14:20:41 2008 From: igloo at earth.li (Ian Lynagh) Date: Mon Sep 22 14:17:54 2008 Subject: Following up on a patch for the network package (trac #2005) In-Reply-To: <6d74b0d20809152214s36901a05r361f074772dfa50c@mail.gmail.com> References: <6d74b0d20809152214s36901a05r361f074772dfa50c@mail.gmail.com> Message-ID: <20080922182041.GA20755@matrix.chaos.earth.li> Hi Judah, On Mon, Sep 15, 2008 at 10:14:46PM -0700, Judah Jacobson wrote: > > A few weeks ago I proposed a (1-line) patch to the network package to > fix trac bug #2005 (getnameinfo error on OS X): > > http://www.haskell.org/pipermail/libraries/2008-July/010239.html > > And then I forgot about it until today; looks like it's been sitting > in limbo since I sent it. Any chance of this making it into 6.10.1? If I understand the #2005 log correctly, another patch has already fixed this problem, so we don't need to apply the above patch. Please let me know if that's wrong. Thanks Ian From igloo at earth.li Mon Sep 22 14:45:48 2008 From: igloo at earth.li (Ian Lynagh) Date: Mon Sep 22 14:42:57 2008 Subject: (lib network) Should inet_aton be called instead of inet_addr ? In-Reply-To: <20080918003245.GC25870@gmx.de> References: <20080918003245.GC25870@gmx.de> Message-ID: <20080922184548.GA21140@matrix.chaos.earth.li> Hi Marc, On Thu, Sep 18, 2008 at 02:32:45AM +0200, Marc Weber wrote: > > Reading http://linux.die.net/man/3/inet_addr I noticed that > inet_addr is obsolete and inet_aton should be used because inet_addr > indicates error by returning -1 which is a valid address (255.255.255.0) > as well. > Don't know wether it's worth changing or wether inet_aton is peresent on > all systems It sounds like we shouldchange, although I too don't know how portable inet_aton is. Could you file a proposal please?: http://www.haskell.org/haskellwiki/Library_submissions Thanks Ian From igloo at earth.li Mon Sep 22 14:46:36 2008 From: igloo at earth.li (Ian Lynagh) Date: Mon Sep 22 14:43:52 2008 Subject: (lib network) Should inet_aton be called instead of inet_addr ? In-Reply-To: <20080918132421.GA18837@gmx.de> References: <20080918003245.GC25870@gmx.de> <20080918132421.GA18837@gmx.de> Message-ID: <20080922184636.GB21140@matrix.chaos.earth.li> Hi Marc, On Thu, Sep 18, 2008 at 03:24:21PM +0200, Marc Weber wrote: > > I'd also suggest to change > inet_addr :: String -> IO HostAddress -- throwing user exception > to > inet_addr :: String -> IO (Maybe HostAddress) -- not throwing any exception > or > inet_addr :: String -> IO (Either String HostAddress) -- not throwing any exception Can you please file this as a library proposal?: http://www.haskell.org/haskellwiki/Library_submissions Thanks Ian From qdunkan at gmail.com Mon Sep 22 14:47:49 2008 From: qdunkan at gmail.com (Evan Laforge) Date: Mon Sep 22 14:44:58 2008 Subject: export toDescList from Data.Map In-Reply-To: <2518b95d0809081546y42f85696h694c1003e82dc5de@mail.gmail.com> References: <2518b95d0809081546y42f85696h694c1003e82dc5de@mail.gmail.com> Message-ID: <2518b95d0809221147i3aa923e3wf2dfa22fe33938a7@mail.gmail.com> > Anyway, is 2-3 weeks ok for discussion period? The library submission > wiki doesn't say how long. So it's been a little while and there hasn't been any objection. What's the next step? Is there any problem with applying the patch as it stands and will it be in 6.10? To re-recap, it exports toDescList, and foldlWithKey. I'm assuming its current level of strictness is ok since no one has said anything. As an aside, it's curious to me that so few people care about Data.Map. In my code, it's the #1 data structure, except for lists, which almost all generated and consumed incrementally and thus take up little space and have simple access patterns. Data.Map does all the heavy lifting. Other people don't use it? From kili at outback.escape.de Mon Sep 22 15:13:41 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Mon Sep 22 15:12:14 2008 Subject: (lib network) Should inet_aton be called instead of inet_addr ? In-Reply-To: <20080922184548.GA21140@matrix.chaos.earth.li> References: <20080918003245.GC25870@gmx.de> <20080922184548.GA21140@matrix.chaos.earth.li> Message-ID: <20080922191341.GA4142@petunia.outback.escape.de> On Mon, Sep 22, 2008 at 07:45:48PM +0100, Ian Lynagh wrote: > > Reading http://linux.die.net/man/3/inet_addr I noticed that > > inet_addr is obsolete and inet_aton should be used because inet_addr > > indicates error by returning -1 which is a valid address (255.255.255.0) > > as well. > > Don't know wether it's worth changing or wether inet_aton is peresent on > > all systems > > It sounds like we shouldchange, although I too don't know how portable > inet_aton is. It isn't POSIX, but it's historically from 4.3BSD, so all the BSDs, MacOS X should support it, too. I also just verified that it's available on a good old IRIX 5.3 ;-) And since Solaris was originally based on BSD, it may have inet_aton, too. No idea about other systems. Ciao, Kili From igloo at earth.li Mon Sep 22 15:46:00 2008 From: igloo at earth.li (Ian Lynagh) Date: Mon Sep 22 15:43:10 2008 Subject: export toDescList from Data.Map In-Reply-To: <2518b95d0809221147i3aa923e3wf2dfa22fe33938a7@mail.gmail.com> References: <2518b95d0809081546y42f85696h694c1003e82dc5de@mail.gmail.com> <2518b95d0809221147i3aa923e3wf2dfa22fe33938a7@mail.gmail.com> Message-ID: <20080922194600.GA22354@matrix.chaos.earth.li> Hi Evan, On Mon, Sep 22, 2008 at 11:47:49AM -0700, Evan Laforge wrote: > > Anyway, is 2-3 weeks ok for discussion period? The library submission > > wiki doesn't say how long. > > So it's been a little while and there hasn't been any objection. > What's the next step? Please see: http://www.haskell.org/haskellwiki/Library_submissions#At_the_end_of_the_discussion_period (and if the concensus was to apply the patch, then you can assign the ticket to igloo). Thanks Ian From igloo at earth.li Mon Sep 22 15:54:49 2008 From: igloo at earth.li (Ian Lynagh) Date: Mon Sep 22 15:51:57 2008 Subject: Splitting SYB from the base package in GHC 6.10 In-Reply-To: <20080916084133.GA2878@soi.city.ac.uk> References: <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> <52f14b210809150428w4cd4061bg4b855fc44ac11b28@mail.gmail.com> <20080916084133.GA2878@soi.city.ac.uk> Message-ID: <20080922195449.GA22526@matrix.chaos.earth.li> Hi Pedro, On Tue, Sep 16, 2008 at 09:41:33AM +0100, Ross Paterson wrote: > On Mon, Sep 15, 2008 at 01:28:30PM +0200, Jos? Pedro Magalh?es wrote: > > 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. > > Sounds good. Those that remain in base need no longer be orphans. > Regarding Complex, I think your point that it exports (:+) determines > that the derived instance is appropriate. > > > * 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 > > I'd lean slightly toward keeping with their definitions in base, but > it's not a blocker like the others. > > What shall we call the module defining the Data class? Data.Data? I'm a little lost as to exactly what changes you want. Can you send a darcs patch against the base and syb repos please?: http://darcs.haskell.org/ghc-6.10/packages/base/ http://darcs.haskell.org/ghc-6.10/packages/syb/ Currently everything is in the syb package. Thanks Ian From qdunkan at gmail.com Mon Sep 22 17:47:35 2008 From: qdunkan at gmail.com (Evan Laforge) Date: Mon Sep 22 17:44:45 2008 Subject: export toDescList from Data.Map In-Reply-To: <20080922194600.GA22354@matrix.chaos.earth.li> References: <2518b95d0809081546y42f85696h694c1003e82dc5de@mail.gmail.com> <2518b95d0809221147i3aa923e3wf2dfa22fe33938a7@mail.gmail.com> <20080922194600.GA22354@matrix.chaos.earth.li> Message-ID: <2518b95d0809221447y486aaceas6452c733c804fb49@mail.gmail.com> >> So it's been a little while and there hasn't been any objection. >> What's the next step? > > Please see: > http://www.haskell.org/haskellwiki/Library_submissions#At_the_end_of_the_discussion_period > (and if the concensus was to apply the patch, then you can assign the > ticket to igloo). Ok. I'm not sure what the consensus was since no one said "looks good", but I'm going to assume it was to apply, since no one said "looks bad" either. I'll add Benedikt's comments to the ticket in case someone later wants to implement his suggestion (viewAssocs). Here's what I added to the ticket when assigning to igloo: So on further thought, it seemed asymmetrical to export foldWithKey and foldlWithKey, so I added foldrWithKey to the export list, keeping foldWithKey to not break existing code. I added a note to the haddock for foldWithKey encouraging the use of foldrWithKey. So we export: toDescList - new, but implementable with foldlWithKey foldlWithKey - new foldrWithKey - the same as foldWithKey, but explicitly the mirror of foldlWithKey There were no other comments. I'm specifically not certain about the laziness of the folds (i.e. will they lead to stack problems like List.foldl), but no one said there was a problem, so maybe it's fine. I'm also not sure if there was some important reason behind the reason the folds were exported, but no one said anything, so maybe it was just arbitrary. --- As another aside, it seems like it would be nice to fix up Map, Set, IntMap, and IntSet, to hopefully give them a consistent API and maybe reduce some of the rampant copy and paste reuse going on in there. Maybe this GSoC thing for tries is doing that... From Christian.Maeder at dfki.de Tue Sep 23 06:47:16 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Sep 23 06:44:21 2008 Subject: export toDescList from Data.Map In-Reply-To: <2518b95d0809221447y486aaceas6452c733c804fb49@mail.gmail.com> References: <2518b95d0809081546y42f85696h694c1003e82dc5de@mail.gmail.com> <2518b95d0809221147i3aa923e3wf2dfa22fe33938a7@mail.gmail.com> <20080922194600.GA22354@matrix.chaos.earth.li> <2518b95d0809221447y486aaceas6452c733c804fb49@mail.gmail.com> Message-ID: <48D8C934.7090709@dfki.de> Hi Evan, sorry for replying so late. I believe, many people are interested in a good Map data structure but do not care much if your proposed patch is applied or not. (The patch does not harm, toDescList is trivial to obtain, and the order of folding does not seem to matter.) (I'm not sure if foldrWithKey should be preferred over foldWithKey.) I've looked into the source and the (giant 338K) patch. The essence is attached below (You've renamed the internal foldr and foldl to foldlWithKey resp. foldrWithKey, which looks ok to me) Actually, Data.Map, Data.IntMap, Data.Set and Data.IntSet do not have an active maintainer and maybe everybody waits for "GSoC thing for tries". Indeed, as you noted yourself "it would be nice to fix up Map, Set, IntMap, and IntSet". I think it is almost mandatory. So would you do this, too? "toDescList" makes sense for sets, too. On the other hand, I was against toAscList as it is identical to toList. That means I always assumed a bias towards "ascending operations". >From a maintainer point of view the module is messy. (Many warnings when compiling.) For example I do not understand why the first pragma is needed: {-# OPTIONS_GHC -fno-bang-patterns #-} Furthermore "foldi" is also defined but not used (but I do not propose it to be foldWithKey). (Other functions are also not exported.) Data.Map contains foldStrict: foldlStrict f z xs = case xs of [] -> z (x:xx) -> let z' = f z x in seq z' (foldlStrict f z' xx) Is there a difference to Data.List.foldl'? #ifdef __GLASGOW_HASKELL__ foldl' f z xs = lgo z xs where lgo z [] = z lgo z (x:xs) = let z' = f z x in z' `seq` lgo z' xs In order to refactor these modules a big test-suite is needed in order to ensure correctness and no performance loss. (So maybe it is wise to never change a running system.) Maybe this explains the little feedback to this ticket, but I would like to encourge you, to improve things, anyway. Cheers Christian Evan Laforge wrote: > Ok. I'm not sure what the consensus was since no one said "looks > good", but I'm going to assume it was to apply, since no one said > "looks bad" either. I'll add Benedikt's comments to the ticket in > case someone later wants to implement his suggestion (viewAssocs). > > Here's what I added to the ticket when assigning to igloo: > > So on further thought, it seemed asymmetrical to export foldWithKey > and foldlWithKey, so I added foldrWithKey to the export list, keeping > foldWithKey to not break existing code. I added a note to the haddock > for foldWithKey encouraging the use of foldrWithKey. > > So we export: > toDescList - new, but implementable with foldlWithKey > foldlWithKey - new > foldrWithKey - the same as foldWithKey, but explicitly the mirror of > foldlWithKey > > There were no other comments. I'm specifically not certain about the > laziness of the folds (i.e. will they lead to stack problems like > List.foldl), but no one said there was a problem, so maybe it's fine. > I'm also not sure if there was some important reason behind the reason > the folds were exported, but no one said anything, so maybe it was > just arbitrary. > > --- > > As another aside, it seems like it would be nice to fix up Map, Set, > IntMap, and IntSet, to hopefully give them a consistent API and maybe > reduce some of the rampant copy and paste reuse going on in there. > Maybe this GSoC thing for tries is doing that... hunk ./Data/Map.hs 106 + , foldrWithKey + , foldlWithKey hunk ./Data/Map.hs 123 + , toDescList hunk ./Data/Map.hs 176 -import Prelude hiding (lookup,map,filter,foldr,foldl,null) +import Prelude hiding (lookup,map,filter,null) hunk ./Data/Map.hs 1431 +-- +-- This is identical to 'foldrWithKey', and you should use that one inste ad of +-- this one. This name is kept for backward compatibility. hunk ./Data/Map.hs 1437 - = foldr f z t + = foldrWithKey f z t hunk ./Data/Map.hs 1448 --- | /O(n)/. Post-order fold. -foldr :: (k -> a -> b -> b) -> b -> Map k a -> b -foldr _ z Tip = z -foldr f z (Bin _ kx x l r) = foldr f (f kx x (foldr f z r)) l +-- | /O(n)/. Post-order fold. The function will be applied from the lowe st +-- value to the highest. +foldrWithKey :: (k -> a -> b -> b) -> b -> Map k a -> b +foldrWithKey _ z Tip = z +foldrWithKey f z (Bin _ kx x l r) = + foldrWithKey f (f kx x (foldrWithKey f z r)) l hunk ./Data/Map.hs 1455 -{- -XXX unused code hunk ./Data/Map.hs 1456 --- | /O(n)/. Pre-order fold. -foldl :: (b -> k -> a -> b) -> b -> Map k a -> b -foldl _ z Tip = z -foldl f z (Bin _ kx x l r) = foldl f (f (foldl f z l) kx x) r --} +-- | /O(n)/. Pre-order fold. The function will be applied from the highe st +-- value to the lowest. +foldlWithKey :: (b -> k -> a -> b) -> b -> Map k a -> b +foldlWithKey _ z Tip = z +foldlWithKey f z (Bin _ kx x l r) = + foldlWithKey f (f (foldlWithKey f z l) kx x) r hunk ./Data/Map.hs 1554 -toAscList t = foldr (\k x xs -> (k,x):xs) [] t +toAscList t = foldrWithKey (\k x xs -> (k,x):xs) [] t hunk ./Data/Map.hs 1556 -{- -XXX unused code - --- | /O(n)/. +-- | /O(n)/. Convert to a descending list. hunk ./Data/Map.hs 1558 -toDescList t = foldl (\xs k x -> (k,x):xs) [] t --} +toDescList t = foldlWithKey (\xs k x -> (k,x):xs) [] t From jpm at cs.uu.nl Tue Sep 23 09:03:19 2008 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Tue Sep 23 09:00:32 2008 Subject: Splitting SYB from the base package in GHC 6.10 In-Reply-To: <20080922195449.GA22526@matrix.chaos.earth.li> References: <1C4AE74FD8C843B1AAC9D92AE067F090@cr3lt> <20080902210637.GA7519@matrix.chaos.earth.li> <20080903081355.GA2149@soi.city.ac.uk> <638ABD0A29C8884A91BC5FB5C349B1C32AE88093CD@EA-EXMSG-C334.europe.corp.microsoft.com> <52f14b210809150428w4cd4061bg4b855fc44ac11b28@mail.gmail.com> <20080916084133.GA2878@soi.city.ac.uk> <20080922195449.GA22526@matrix.chaos.earth.li> Message-ID: <52f14b210809230603n5d7c2fa5ga6a791e48a27bcad@mail.gmail.com> Hello Ian, On Mon, Sep 22, 2008 at 21:54, Ian Lynagh wrote: > I'm a little lost as to exactly what changes you want. Can you send a > darcs patch against the base and syb repos please?: > http://darcs.haskell.org/ghc-6.10/packages/base/ > http://darcs.haskell.org/ghc-6.10/packages/syb/ > Currently everything is in the syb package. That's fine, but do I need to build the entire compiler to be able to compile the base package? Currently if I try to `runhaskell setup.hs configure' on base I get `attempting to use module `Prelude' (Prelude.hs) which is not loaded'... Thanks, Pedro -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20080923/90c3650a/attachment-0001.htm From qdunkan at gmail.com Tue Sep 23 12:09:44 2008 From: qdunkan at gmail.com (Evan Laforge) Date: Tue Sep 23 12:06:51 2008 Subject: export toDescList from Data.Map In-Reply-To: <48D8C934.7090709@dfki.de> References: <2518b95d0809081546y42f85696h694c1003e82dc5de@mail.gmail.com> <2518b95d0809221147i3aa923e3wf2dfa22fe33938a7@mail.gmail.com> <20080922194600.GA22354@matrix.chaos.earth.li> <2518b95d0809221447y486aaceas6452c733c804fb49@mail.gmail.com> <48D8C934.7090709@dfki.de> Message-ID: <2518b95d0809230909q17652d27q647924d2f8062b5a@mail.gmail.com> > sorry for replying so late. I believe, many people are interested in a > good Map data structure but do not care much if your proposed patch is > applied or not. (The patch does not harm, toDescList is trivial to > obtain, and the order of folding does not seem to matter.) That's one of the things I was asking... how do you obtain toDescList without foldlWithKey? And for me, since since the order of the keys is important (say points in time), the order of the fold matters a great deal. > (I'm not sure if foldrWithKey should be preferred over foldWithKey.) Me either. On one hand, it's more api clutter. Once you add it, it never goes away. On the other hand, foldWithKey vs. foldlWithKey is just confusing. But if there was some sort of consensus that default is low to high, then I wouldn't mind so much. The unfortunate presence of both toList and toAscList seems to indicate a lack of consensus though (I think including both is silly too). > Actually, Data.Map, Data.IntMap, Data.Set and Data.IntSet do not have an > active maintainer and maybe everybody waits for "GSoC thing for tries". > > Indeed, as you noted yourself "it would be nice to fix up Map, Set, > IntMap, and IntSet". I think it is almost mandatory. So would you do > this, too? "toDescList" makes sense for sets, too. On the other hand, I > was against toAscList as it is identical to toList. That means I always > assumed a bias towards "ascending operations". I wouldn't mind doing some cleanup, but I'm assuming any backward-incompatible api changes are out of the question. It seems like there should be the maplike equivalent of the IArray interface, or something clever like that. I know there has been a lot of discussion on this topic, and possibly even implementation in Edison. And then some discussion for the trie thing that sounded like a generic typeclass interface. So I feel like I should stick to conservative changes, i.e. just add new functions. It's also galling that IntMap is hardcoded to 32bit ints and writing a 64 bit version would seem to require yet another copy and paste session. And it seems like theoretically patricia should work on doubles too. But I'm not sure how to address all this code sharing. I agree the changes should be made to the other maplike modules, and I even wrote a foldl and toDescList for IntMap, but I was trying to the patch scope small, since I only need Map.toDescList. > In order to refactor these modules a big test-suite is needed in order > to ensure correctness and no performance loss. (So maybe it is wise to > never change a running system.) Yes, no tests (that I could see) is another reason to be conservative making changes. I suppose I could write up some tests, but I remember there was some controversy about whether tests should be included in the ghc libs. And I'd be sort of surprised if someone else hasn't already written some? It would also be nice to have some time, garbage, and sharing (i.e. if you update a value how much of the structure is shared?) graphs generated for each of the operations. This would help evaluate new map implementations as well as check for the ramifications to various changes. > Maybe this explains the little feedback to this ticket, but I would like > to encourge you, to improve things, anyway. Well thanks. It's nice to hear *something* :) From marlowsd at gmail.com Tue Sep 23 15:22:18 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Sep 23 15:19:54 2008 Subject: ANNOUNCE: protocol-buffers-0.2.9 for Haskell is ready In-Reply-To: <48D777F0.7060907@list.mightyreason.com> References: <48D53BBA.10101@list.mightyreason.com> <20080920180915.GB18629@scytale.galois.com> <48D64DE8.90602@dtek.chalmers.se> <48D650A9.2080507@dtek.chalmers.se> <48D6784D.7070101@list.mightyreason.com> <20080921165752.GA19677@matrix.chaos.earth.li> <48D777F0.7060907@list.mightyreason.com> Message-ID: <48D941EA.40207@gmail.com> Chris Kuklewicz wrote: > I am cross-posting this message to several lists. > > I had learned the trick before the documentation was updated. It seems > I have used a very unreliable trick. And the "use castToSTUArray" > suggested alternative is a really poor one since I am not using arrays > at all. castSTUArray is the way GHC does it - the idea is to allocate a small array, store the Float/Double in it, cast the type of the array to Word32 or whatever, and then read out the contents. It's more or less equivalent to the peek/poke solution, except that it doesn't need unsafePerformIO. GHC's code is here: (look for floatToWord): http://darcs.haskell.org/ghc/compiler/cmm/PprC.hs Cheers, Simon From allbery at ece.cmu.edu Wed Sep 24 00:07:47 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Sep 24 00:05:06 2008 Subject: (lib network) Should inet_aton be called instead of inet_addr ? In-Reply-To: <20080922191341.GA4142@petunia.outback.escape.de> References: <20080918003245.GC25870@gmx.de> <20080922184548.GA21140@matrix.chaos.earth.li> <20080922191341.GA4142@petunia.outback.escape.de> Message-ID: On 2008 Sep 22, at 15:13, Matthias Kilian wrote: > On Mon, Sep 22, 2008 at 07:45:48PM +0100, Ian Lynagh wrote: >>> Reading http://linux.die.net/man/3/inet_addr I noticed that >>> inet_addr is obsolete and inet_aton should be used because inet_addr >>> indicates error by returning -1 which is a valid address >>> (255.255.255.0) >>> as well. >>> Don't know wether it's worth changing or wether inet_aton is >>> peresent on >>> all systems >> >> It sounds like we shouldchange, although I too don't know how >> portable >> inet_aton is. > > It isn't POSIX, but it's historically from 4.3BSD, so all the BSDs, > MacOS X should support it, too. I also just verified that it's > available on a good old IRIX 5.3 ;-) > > And since Solaris was originally based on BSD, it may have inet_aton, > too. No idea about other systems. Solaris 10+ probably does, but our Solaris 9 machines don't. Linux and OSX have inet_aton. (Solaris 2 is not based on BSD, but on AT&T System V. For example, it didn't get real sockets until 2.6; before that they were emulated on top of System V streams.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From Christian.Maeder at dfki.de Wed Sep 24 04:46:18 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Sep 24 04:43:20 2008 Subject: export toDescList from Data.Map In-Reply-To: <2518b95d0809230956i42978560sb9bb8589cb1e7c58@mail.gmail.com> References: <2518b95d0809081546y42f85696h694c1003e82dc5de@mail.gmail.com> <2518b95d0809221147i3aa923e3wf2dfa22fe33938a7@mail.gmail.com> <20080922194600.GA22354@matrix.chaos.earth.li> <2518b95d0809221447y486aaceas6452c733c804fb49@mail.gmail.com> <48D8C934.7090709@dfki.de> <2518b95d0809230909q17652d27q647924d2f8062b5a@mail.gmail.com> <48D91996.5050906@dfki.de> <2518b95d0809230956i42978560sb9bb8589cb1e7c58@mail.gmail.com> Message-ID: <48D9FE5A.7000908@dfki.de> Hallo Evan, If it is really such a performance difference the functions should be exported by all means. (Another work-around might by to inverse the order of the keys, but that'll be unnatural at least for Int keys.) Obviously, I rarely have 1 million elements in my maps. Evan Laforge wrote: >>> That's one of the things I was asking... how do you obtain toDescList >>> without foldlWithKey? And for me, since since the order of the keys >>> is important (say points in time), the order of the fold matters a >>> great deal. >> I thought of "reverse . toList". Maybe the folding functions are not >> needed at all (or only short cuts): > > Ah, well if I really didn't care about performance, then I wouldn't > use Map at all, just an unsorted [(k, v)]. But it's sort of awkward > for the GUI to freeze for a second (yes, it really does take that > long) while haskell reverses a 1 million element list just to get the > first 3 elements (and does so many times)... findMax (deleteFinMax) for the highest 3 elements would be faster then. >> foldlWithKey f z = foldl (\ b (k, v) -> f b k v) z . toList > > This is equivalent to reverse, isn't it? It also takes a second or so > (well, once I add a prime of course, without the prime it sends the > whole system into OOM molasses). Yes, but folding is linear anyway (if the whole result is needed). Cheers Christian From haskell at list.mightyreason.com Wed Sep 24 05:06:13 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Wed Sep 24 05:03:19 2008 Subject: export toDescList from Data.Map In-Reply-To: <2518b95d0809230909q17652d27q647924d2f8062b5a@mail.gmail.com> References: <2518b95d0809081546y42f85696h694c1003e82dc5de@mail.gmail.com> <2518b95d0809221147i3aa923e3wf2dfa22fe33938a7@mail.gmail.com> <20080922194600.GA22354@matrix.chaos.earth.li> <2518b95d0809221447y486aaceas6452c733c804fb49@mail.gmail.com> <48D8C934.7090709@dfki.de> <2518b95d0809230909q17652d27q647924d2f8062b5a@mail.gmail.com> Message-ID: <48DA0305.8080306@list.mightyreason.com> > Me either. On one hand, it's more api clutter. Once you add it, it > never goes away. On the other hand, foldWithKey vs. foldlWithKey is > just confusing. But if there was some sort of consensus that default > is low to high, then I wouldn't mind so much. The unfortunate > presence of both toList and toAscList seems to indicate a lack of > consensus though (I think including both is silly too). I conjecture that the logic, if any exists, behind having the two names is so that the Data.Map API can be applied to several implementations. And in another implementation it may be most efficient or most lazy to return elements in unsorted order. So there is a "toList" which asks for the easiest conversion to a list, and a "toAscList" which asks for the sorted version. As for this proposal, I vote to have toDescList and foldlWithKey. This would likely simplify one of my uses of Data.Map. -- Chris From Christian.Maeder at dfki.de Wed Sep 24 06:15:48 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Sep 24 06:12:49 2008 Subject: export toDescList from Data.Map In-Reply-To: <48DA0305.8080306@list.mightyreason.com> References: <2518b95d0809081546y42f85696h694c1003e82dc5de@mail.gmail.com> <2518b95d0809221147i3aa923e3wf2dfa22fe33938a7@mail.gmail.com> <20080922194600.GA22354@matrix.chaos.earth.li> <2518b95d0809221447y486aaceas6452c733c804fb49@mail.gmail.com> <48D8C934.7090709@dfki.de> <2518b95d0809230909q17652d27q647924d2f8062b5a@mail.gmail.com> <48DA0305.8080306@list.mightyreason.com> Message-ID: <48DA1354.8030507@dfki.de> Chris Kuklewicz wrote: > I conjecture that the logic, if any exists, behind having the two names > is so that the Data.Map API can be applied to several implementations. > And in another implementation it may be most efficient or most lazy to > return elements in unsorted order. So there is a "toList" which asks > for the easiest conversion to a list, and a "toAscList" which asks for > the sorted version. if "toList" returned "elements in unsorted order" it would break the abstraction: equal maps could return different list. So toList must either be toAscList or toDescList. > > As for this proposal, I vote to have toDescList and foldlWithKey. This > would likely simplify one of my uses of Data.Map. +1 and foldrWithKey. Christian From marlowsd at gmail.com Wed Sep 24 10:59:12 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Sep 24 10:56:34 2008 Subject: instance visibility (was: Re: The base library and GHC 6.10) In-Reply-To: <2D93D24B65084422832AF68B82EF4106@cr3lt> References: <20080828111232.GA15998@matrix.chaos.earth.li><404396ef0808280428j5f8ce984q904f5f0e2b0e61ee@mail.gmail.com><20080830120134.GA3741@matrix.chaos.earth.li><20080831121055.GA5326@soi.city.ac.uk><20080831121633.GA17919@matrix.chaos.earth.li> <48BE480C.5050308@gmail.com> <2D93D24B65084422832AF68B82EF4106@cr3lt> Message-ID: <48DA55C0.2090406@gmail.com> (sorry for the delay in replying to this...) Claus Reinke wrote: >> This raises the more general issue of instance-visibility. Since >> instances are automatically re-exported and therefore break >> abstraction barriers, the only sensible way to think about instances >> is as global properties. > > I've heard this fatalistic view expressed before, and even for > impoverished Haskell 98, it just isn't true. Perhaps it has come about > from years of being bitten by either #2182, by attempts > to avoid "orphan" instances, by carelessly designed libraries, or > by careless instance imports, all of which make combining libraries > that provide instances of the same class for the same type a pain? No, it has nothing to do with bugs or misfeatures in GHC, it's a fact of Haskell 98. > A type class specifies a relation between types. Both the types > and the class are named, and if instances are placed in separate > modules, the modules are named as well. The combination of > module, class and type names gives quite a bit of control over instance > import/export, even if it is terribly cumbersome and > limited (and easily defeated by just one library importing all > instances "for convenience"). Neither the relation (class), nor > its domain (types), nor its extent (instances) are "global". The point is that instances are unconditionally re-exported, which exposes knowledge about the import structure underneath a module. If we consider instances to be part of the API of a module, then the API of a module is changed simply by changing what is imported. This is clarly an abstraction failure, because we want a module to be able to control its API independently of its implementation. This is even worse at the level of packages. We can hide modules that are used internally to a package's implementation, but we can't hide the fact that a package used some non-standard instances internally, and furthermore we can't change this aspect of its implementation without changing the API. So thinking of instances as part of the API of a module is wrong, because it leads to the aforementioned abstraction failures. The only sensible way to think of instances is as global properties - one instance per class/type pair. Orphan instances are usually wrong unless the orphans are also exported via the standard API for either the class or the type. That is, orphans are ok in the implementation of a package, but not in the exposed API, because that makes it possible for a client to import both the class and type without getting the instance, which is what we have to avoid. Cheers, Simon From ross at soi.city.ac.uk Wed Sep 24 11:13:38 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Sep 24 11:10:46 2008 Subject: instance visibility (was: Re: The base library and GHC 6.10) In-Reply-To: <48DA55C0.2090406@gmail.com> References: <48BE480C.5050308@gmail.com> <2D93D24B65084422832AF68B82EF4106@cr3lt> <48DA55C0.2090406@gmail.com> Message-ID: <20080924151338.GA4135@soi.city.ac.uk> On Wed, Sep 24, 2008 at 03:59:12PM +0100, Simon Marlow wrote: > Claus Reinke wrote: >>> This raises the more general issue of instance-visibility. Since >>> instances are automatically re-exported and therefore break >>> abstraction barriers, the only sensible way to think about instances >>> is as global properties. >> >> I've heard this fatalistic view expressed before, and even for >> impoverished Haskell 98, it just isn't true. Perhaps it has come about >> from years of being bitten by either #2182, by attempts >> to avoid "orphan" instances, by carelessly designed libraries, or >> by careless instance imports, all of which make combining libraries >> that provide instances of the same class for the same type a pain? > > No, it has nothing to do with bugs or misfeatures in GHC, it's a fact of > Haskell 98. Except for #2356, which some people think is a feature. (Not me, though) From claus.reinke at talk21.com Wed Sep 24 12:30:27 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Sep 24 12:27:37 2008 Subject: instance visibility (was: Re: The base library and GHC 6.10) References: <20080828111232.GA15998@matrix.chaos.earth.li><404396ef0808280428j5f8ce984q904f5f0e2b0e61ee@mail.gmail.com><20080830120134.GA3741@matrix.chaos.earth.li><20080831121055.GA5326@soi.city.ac.uk><20080831121633.GA17919@matrix.chaos.earth.li> <48BE480C.5050308@gmail.com> <2D93D24B65084422832AF68B82EF4106@cr3lt> <48DA55C0.2090406@gmail.com> Message-ID: <77766447D98E4243A6B4B87A3FC61A03@cr3lt> > (sorry for the delay in replying to this...) No problem, though you seem to be restating your opinion intead of addressing my concrete points? For those who, like me, have lost the thread in the meantime, here is a link to the message you reply to: http://www.haskell.org/pipermail/libraries/2008-September/010623.html >>> .., the only sensible way to think about instances is as global properties. > ..it has nothing to do with bugs or misfeatures in GHC, it's a > fact of Haskell 98. I thought my example demonstrated quite clearly that instances are *not* global in Haskell. >> A type class specifies a relation between types. Both the types >> and the class are named, and if instances are placed in separate >> modules, the modules are named as well. The combination of >> module, class and type names gives quite a bit of control over instance >> import/export, even if it is terribly cumbersome and >> limited (and easily defeated by just one library importing all >> instances "for convenience"). Neither the relation (class), nor >> its domain (types), nor its extent (instances) are "global". > > The point is that instances are unconditionally re-exported, Yes, and I'm not disputing that point. What I am disputing are its consequences/interpretation. As I said, instances accumulate upwards along the import hierarchy. But they do not propagate downwards, so they do not have global scope, and one can exert some control over all of type relation (class), domain (types), and extent (instances). What one cannot do (in Haskell 98) is to have two instances of the same class, for the same types, in the same import hierarchy. > If we consider instances to be part of the API of a module, then the > API of a module is changed simply by changing what is imported. That is true, whether we like it or not. The language does not give the programmer a way to control this part of the API by limiting re-export of locally visible instances. The programmers may not like it, but those instances are visible to importers even if they distribute warning labels stating "these instances are not part of our intended API". > This is even worse at the level of packages. We can hide modules that > are used internally to a package's implementation, but we can't hide the > fact that a package used some non-standard instances internally, and > furthermore we can't change this aspect of its implementation without > changing the API. How do packages make a difference here? As long as I don't import base:Control.Monad.Error, the base:Control.Monad.Instances instances of Functor, say, are not visible in base:Control.Monad. > So thinking of instances as part of the API of a module is wrong, > because it leads to the aforementioned abstraction failures. The only > sensible way to think of instances is as global properties - one > instance per class/type pair. I'm afraid that is the wrong way round: the abstracton failures occur because of lack of control over the API - trying to wish away the offending instances ("don't think of them as part of the API") won't help. And trying to think of instances as global fails to account for the limited control we do have, by arranging code inside the import hierarchy, as in the example I gave. So this interpretation is unhelpful, demonstrably wrong, and prevents more detailed analysis. There may be real theory reasons why the extent of type relations has to increase monotonically as one walks up the import hierarchy, and such reasons might invalidate the proposal I made about providing more control over instance re-export. I'd certainly be interested in hearing about such real arguments (the fact that moving code downwards in the import hierarchy, away from the branch that provides the instances, has the same effect, suggests that such reasons either do not exist or already point to issues with the current language definition). But simply jumping from "we don't have full control" to "we don't have any control, and we never will" is unhelpful. We need to understand these issues better, so that we can discuss whether the language can be improved, and so that we can see what needs to change so that Ghc and Haddock start supporting the existing language. Clarity of language precedes better understanding, I hope. > Orphan instances are usually wrong unless the orphans are also exported > via the standard API for either the class or the type. That is, orphans > are ok in the implementation of a package, but not in the exposed API, > because that makes it possible for a client to import both the class and > type without getting the instance, which is what we have to avoid. Sadly, that has all been discussed to death already, and again, it is a matter of being precise. "Orphan" instances are not wrong per se - they encode and name the extent of type relations via modules, but one needs to think carefully about their intended use and whether that use is really supported by the language or just an illusion. Of the top of my head, I can think of two uses: (a) having two instances of the same class for the same types in the same program only works by "virtue" of #2356, so should be avoided unless and until the positive aspects of #2356 are moved from accident to design decision (b) giving clients control over which instances they want to use (eg, use set A or set B, or neither) should work, and mostly does, but may run into ghc #2182 and haddock #54. Also, it is advisable only for client applications, not for client libraries, as long as their users might run into unresolved aspect of (a). My preference would be to see ghc #2182, #2356 (for Haskell 98 mode) and haddock #54 fixed. #2356 (for Ghc mode) is documented behaviour, I believe, inherited from Ghc's handling of overlapping instances, but there is no LANGUAGE extension specifying this behaviour, so it isn't portable. Next, I'd like to see whether more control over instance re-export is permissible in theory and -if yes- would like to see it implemented and standardised. Currently, I see no reason why we couldn't support (a) and (b). Claus From jonathanccast at fastmail.fm Wed Sep 24 12:28:04 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Sep 24 12:31:15 2008 Subject: instance visibility (was: Re: The base library and GHC 6.10) In-Reply-To: <77766447D98E4243A6B4B87A3FC61A03@cr3lt> References: <20080828111232.GA15998@matrix.chaos.earth.li> <404396ef0808280428j5f8ce984q904f5f0e2b0e61ee@mail.gmail.com> <20080830120134.GA3741@matrix.chaos.earth.li> <20080831121055.GA5326@soi.city.ac.uk> <20080831121633.GA17919@matrix.chaos.earth.li> <48BE480C.5050308@gmail.com> <2D93D24B65084422832AF68B82EF4106@cr3lt> <48DA55C0.2090406@gmail.com> <77766447D98E4243A6B4B87A3FC61A03@cr3lt> Message-ID: <1222273684.20785.1.camel@jcchost> On Wed, 2008-09-24 at 17:30 +0100, Claus Reinke wrote: > > (sorry for the delay in replying to this...) > > No problem, though you seem to be restating your opinion > intead of addressing my concrete points? For those who, like > me, have lost the thread in the meantime, here is a link to the > message you reply to: > > http://www.haskell.org/pipermail/libraries/2008-September/010623.html > > >>> .., the only sensible way to think about instances is as global properties. > > ..it has nothing to do with bugs or misfeatures in GHC, it's a > > fact of Haskell 98. > > I thought my example demonstrated quite clearly that instances > are *not* global in Haskell. > > >> A type class specifies a relation between types. Both the types > >> and the class are named, and if instances are placed in separate > >> modules, the modules are named as well. The combination of > >> module, class and type names gives quite a bit of control over instance > >> import/export, even if it is terribly cumbersome and > >> limited (and easily defeated by just one library importing all > >> instances "for convenience"). Neither the relation (class), nor > >> its domain (types), nor its extent (instances) are "global". > > > > The point is that instances are unconditionally re-exported, > > Yes, and I'm not disputing that point. What I am disputing are > its consequences/interpretation. As I said, instances accumulate > upwards along the import hierarchy. But they do not propagate > downwards, so they do not have global scope, and one can exert > some control over all of type relation (class), domain (types), and > extent (instances). > > What one cannot do (in Haskell 98) is to have two instances of > the same class, for the same types, in the same import hierarchy. Of course, when you consider that Main, by definition, imports every module in the program directly or indirectly, this is pretty close to saying `instances are global'. Isn't it? jcc From sedillard at gmail.com Wed Sep 24 12:50:02 2008 From: sedillard at gmail.com (Scott Dillard) Date: Wed Sep 24 12:47:06 2008 Subject: export toDescList from Data.Map Message-ID: > Date: Tue, 23 Sep 2008 09:09:44 -0700 > From: "Evan Laforge" > Subject: Re: export toDescList from Data.Map > > > > Actually, Data.Map, Data.IntMap, Data.Set and Data.IntSet do not have an > > active maintainer and maybe everybody waits for "GSoC thing for tries". > > > > Indeed, as you noted yourself "it would be nice to fix up Map, Set, > > IntMap, and IntSet". I think it is almost mandatory. So would you do > > this, too? "toDescList" makes sense for sets, too. On the other hand, I > > was against toAscList as it is identical to toList. That means I always > > assumed a bias towards "ascending operations". > > I wouldn't mind doing some cleanup... I use Map, Set, IntMap and IntSet very much, and I'm very interested in seeing to it that these important libraries are maintained and improved. However, short of a major API change, like what's going on with generalized tries and what's already been done with Edison, I don't think there is much work left to be done with these libraries at the API level. Just minor changes like the one you've proposed. There are some things that could be done though... - I'm not sure what Benedikt Huber meant by 'view', but I think he means exposing the tree structure, in a read-only way, to users. I think its a shame that the Map/Set libraries do not expose this. The simplest solution would be to have toTree functions that convert it to a Data.Tree, but I don't think anybody actually likes that data type. A specialized binary tree data type would be more elegant, but there is an issue of how data is stored in the tree. Map/Set store keys and values in internal nodes and use null leaves. IntMap/IntSet store all keys/values in non-null leaves. So maybe this TreeView type would have to be specific to either Map or IntMap. The idea here is that the algorithms and data structures used for these trees are well-known. The papers are linked from the documentation. So the library should expose this to users, in a safe way. - Since someone raised the issue of test suites for performance and correctness, I think it would also be interesting to investigate what effect the strictness annotations in the tree constructors have on performance. Everyone takes for granted that bangs=faster, but I've noticed, as have others, that removing these strictness annotations actually make things run faster. Instead, the tree construction _functions_ should be made strict using seq. The Map construction functions are already strict enough on account of the balancing. Try it for yourself, remove the bangs from the sub-tree fields in the Bin constructor, and run a little benchmark. This would open up the possibility for lazy versions of functions like mapWithKey and mapKeysMonotonic. I had mentioned this previously, but few seemed to care, so I just made the change locally. http://www.haskell.org/pipermail/libraries/2008-August/010371.html . If we we're going to start a little Map/Set/IntMap/IntSet working group, then I'd like to throw that idea back into the mix. > It's also galling that IntMap is hardcoded to 32bit ints and writing a > 64 bit version would seem to require yet another copy and paste > session. And it seems like theoretically patricia should work on > doubles too. But I'm not sure how to address all this code sharing. > IntMap is hard coded to Int, which is 32 bits on a 32 bit architecture, and 64 bits on a 64 bit architecture. I think the main reason for this is so that the key can be unpacked/specialized for extra performance, since that is the primary purpose of the library. If you just need sublinear insert/lookup/delete then use a Map. Are you galled that the key type is not hardcoded to Int64, or that the key is not allowed to be any instance of the Bits class? In the former case, you'd inflate the size of the tree and take a small speed hit on 32bit archs, and in the latter I think you'd have even worse performance. I think the choice of Int is wise because it is the fastest, and that is the point of the library, and if you think about it you're not going to be dealing with more that 2^32 Ints on a 32 bit computer. (What would they be referencing? Not array positions or file offsets.) If you're trying to optimize, say, "Map (Int32,Int32) a" into "IntMap64 a", there are other ways to accomplish that: import qualified Data.IntMap as IM import Data.IntMap (IntMap) newtype IntTrie = IntTrie (IntMap IntTrie) empty :: IntTrie empty = IntTrie IM.empty insert :: [Int] -> IntTrie -> IntTrie insert [] t = t insert (x:xs) (IntTrie t) = IntTrie t' where (y,t') = IM.insertLookupWithKey (const union) x y' t y' = case y of Just y -> insert xs y; Nothing -> insert xs empty delete :: [Int] -> IntTrie -> IntTrie delete [] t = empty delete (x:xs) (IntTrie t) = IntTrie (IM.update f x t) where f y = case IM.delete x (case delete xs y of IntTrie t -> t) of t' | IM.null t' -> Nothing | otherwise -> Just (IntTrie t') And so forth. This is an IntSet for arbitrarily long integers represented as [Int]. An IntMap is probably not much more work. > > Maybe this explains the little feedback to this ticket, but I would like > > to encourge you, to improve things, anyway. > > Well thanks. It's nice to hear *something* :) > > For my $0.02 your proposal is good. toDescList is very important to have in many situations. I've had it un-hidden locally for a while now. It's silly that it wasn't exported in the first place. Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20080924/6a5106a7/attachment.htm From droundy at darcs.net Wed Sep 24 13:10:03 2008 From: droundy at darcs.net (David Roundy) Date: Wed Sep 24 13:06:59 2008 Subject: instance visibility (was: Re: The base library and GHC 6.10) In-Reply-To: <77766447D98E4243A6B4B87A3FC61A03@cr3lt> References: <48BE480C.5050308@gmail.com> <2D93D24B65084422832AF68B82EF4106@cr3lt> <48DA55C0.2090406@gmail.com> <77766447D98E4243A6B4B87A3FC61A03@cr3lt> Message-ID: <20080924171002.GP1961@darcs.net> On Wed, Sep 24, 2008 at 05:30:27PM +0100, Claus Reinke wrote: >> Orphan instances are usually wrong unless the orphans are also exported >> via the standard API for either the class or the type. That is, >> orphans are ok in the implementation of a package, but not in the >> exposed API, because that makes it possible for a client to import both >> the class and type without getting the instance, which is what we have >> to avoid. > > Sadly, that has all been discussed to death already, and again, it is a > matter of being precise. "Orphan" instances are not wrong per se - they > encode and name the extent of type relations via modules, but one needs > to think carefully about their intended use and whether that use is > really supported by the language or just an illusion. Of the top of my > head, I can think of two uses: > > (a) having two instances of the same class for the same types in the > same program only works by "virtue" of #2356, so should be > avoided unless and until the positive aspects of #2356 are moved > from accident to design decision > > (b) giving clients control over which instances they want to use (eg, > use set A or set B, or neither) should work, and mostly does, > but may run into ghc #2182 and haddock #54. Also, it is advisable > only for client applications, not for client libraries, as long as > their users might run into unresolved aspect of (a). In the interest of providing a concrete example, see the darcs bug: http://bugs.darcs.net/issue387 It's a wishlist bug that we can't implement because the Show instance for Control.Exception.Exception is *not* an orphan (and thus we cannot define a duplicate instance). If it were an orphan, we could define a second show instance and then we'd get an error message if anyone ever calls show on an exception (which is always a bug). Alas, we cannot do this, and so we're stuck perpetually auditing our code to ensure that noone calls this pernicious function. Admittedly, we only want this orphan instance as a workaround for a poor API. Nevertheless, I think it illustrates your point that orphan instances could be useful, *particularly* because we have very little control over instance propogation. David From droundy at darcs.net Wed Sep 24 13:13:29 2008 From: droundy at darcs.net (David Roundy) Date: Wed Sep 24 13:10:23 2008 Subject: instance visibility (was: Re: The base library and GHC 6.10) In-Reply-To: <1222273684.20785.1.camel@jcchost> References: <20080830120134.GA3741@matrix.chaos.earth.li> <20080831121055.GA5326@soi.city.ac.uk> <20080831121633.GA17919@matrix.chaos.earth.li> <48BE480C.5050308@gmail.com> <2D93D24B65084422832AF68B82EF4106@cr3lt> <48DA55C0.2090406@gmail.com> <77766447D98E4243A6B4B87A3FC61A03@cr3lt> <1222273684.20785.1.camel@jcchost> Message-ID: <20080924171328.GQ1961@darcs.net> On Wed, Sep 24, 2008 at 09:28:04AM -0700, Jonathan Cast wrote: > On Wed, 2008-09-24 at 17:30 +0100, Claus Reinke wrote: > > > (sorry for the delay in replying to this...) > > > > No problem, though you seem to be restating your opinion > > intead of addressing my concrete points? For those who, like > > me, have lost the thread in the meantime, here is a link to the > > message you reply to: > > > > http://www.haskell.org/pipermail/libraries/2008-September/010623.html > > > > >>> .., the only sensible way to think about instances is as global properties. > > > ..it has nothing to do with bugs or misfeatures in GHC, it's a > > > fact of Haskell 98. > > > > I thought my example demonstrated quite clearly that instances > > are *not* global in Haskell. > > > > >> A type class specifies a relation between types. Both the types > > >> and the class are named, and if instances are placed in separate > > >> modules, the modules are named as well. The combination of > > >> module, class and type names gives quite a bit of control over instance > > >> import/export, even if it is terribly cumbersome and > > >> limited (and easily defeated by just one library importing all > > >> instances "for convenience"). Neither the relation (class), nor > > >> its domain (types), nor its extent (instances) are "global". > > > > > > The point is that instances are unconditionally re-exported, > > > > Yes, and I'm not disputing that point. What I am disputing are > > its consequences/interpretation. As I said, instances accumulate > > upwards along the import hierarchy. But they do not propagate > > downwards, so they do not have global scope, and one can exert > > some control over all of type relation (class), domain (types), and > > extent (instances). > > > > What one cannot do (in Haskell 98) is to have two instances of > > the same class, for the same types, in the same import hierarchy. > > Of course, when you consider that Main, by definition, imports every > module in the program directly or indirectly, this is pretty close to > saying `instances are global'. Isn't it? No, because the Main module has a choice to only import certain modules. Thus when orphan instances are defined, we may have a choice of which instances we want to use. David From igloo at earth.li Wed Sep 24 13:38:35 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Sep 24 13:35:37 2008 Subject: instance visibility (was: Re: The base library and GHC 6.10) In-Reply-To: <77766447D98E4243A6B4B87A3FC61A03@cr3lt> References: <48BE480C.5050308@gmail.com> <2D93D24B65084422832AF68B82EF4106@cr3lt> <48DA55C0.2090406@gmail.com> <77766447D98E4243A6B4B87A3FC61A03@cr3lt> Message-ID: <20080924173835.GA2089@matrix.chaos.earth.li> On Wed, Sep 24, 2008 at 05:30:27PM +0100, Claus Reinke wrote: > > What one cannot do (in Haskell 98) is to have two instances of > the same class, for the same types, in the same import hierarchy. What do you mean by "in the same import hierarchy"? Do you mean "in the same program"? I've put an example showing how multiple instances can cause Data.Set to go wrong here: http://hackage.haskell.org/trac/ghc/ticket/2356#comment:8 Do you think that that behaviour is OK? > >This is even worse at the level of packages. > > How do packages make a difference here? Generally, you control what other modules in your program do, but not what the packages that you depend on do. So if a package you use starts using an instance that you don't want, then you are stuck. Thanks Ian From claus.reinke at talk21.com Wed Sep 24 14:21:19 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Sep 24 14:18:26 2008 Subject: instance visibility (was: Re: The base library and GHC 6.10) References: <48BE480C.5050308@gmail.com> <2D93D24B65084422832AF68B82EF4106@cr3lt> <48DA55C0.2090406@gmail.com> <77766447D98E4243A6B4B87A3FC61A03@cr3lt> <20080924173835.GA2089@matrix.chaos.earth.li> Message-ID: <581247585D1840B0BD0DF8FC4FE8B109@cr3lt> >> What one cannot do (in Haskell 98) is to have two instances of >> the same class, for the same types, in the same import hierarchy. > > What do you mean by "in the same import hierarchy"? > Do you mean "in the same program"? Actually, I was thinking of any import hierarchy with a common root, but it doesn't make much difference; Haskell'98 only rules this out for the whole program, but sub-hierarchies (libraries) with duplicate instances can thus never become part of any Haskell'98 program. > I've put an example showing how multiple instances can cause Data.Set to > go wrong here: > http://hackage.haskell.org/trac/ghc/ticket/2356#comment:8 > > Do you think that that behaviour is OK? Note that I submitted that ticket;-) I think that the behaviour, the Haskell'98 vs Ghc discrepancy, the comments, and this thread, show that the rules need to be specified carefully and clearly, and that the current situation is not satisfactory. Such an investigation might have one of several consequences, including: 1 your example is accepted (*), and causes no problem, because noone is making assumptions about the instance being the same everywhere (one instance implying the absence of others) 2 your example is rejected (*), and alternative solutions are found for people who rely on this Ghc behaviour for overlapping and other instances (late resolution of overlaps, omitting errors if "late" can be pushed after full program compilation) 3 your example generates a warning (*), indicating that Ghc's interpretation is at odds with what people might expect from the Haskell'98 subset (I would tend to prefer this as an interim workaround, until one of 1/2/3 can be decided on) (*) in Ghc mode; in Haskell'98 mode, it should always cause an error message >> How do packages make a difference here? > Generally, you control what other modules in your program do, but not > what the packages that you depend on do. So if a package you use starts > using an instance that you don't want, then you are stuck. Ah, ok. I was assuming that problem for any modules supplied by others, so packages don't make the situation worse for me (packages seem neither necessary nor sufficient to worsen the situation: I might provide my own package, which I could change; or I might use package-less modules that I can't change directly - we had that issue with Programatica and Strafunski a while back;-). Claus From marlowsd at gmail.com Wed Sep 24 14:22:32 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Sep 24 14:20:01 2008 Subject: instance visibility In-Reply-To: <77766447D98E4243A6B4B87A3FC61A03@cr3lt> References: <20080828111232.GA15998@matrix.chaos.earth.li><404396ef0808280428j5f8ce984q904f5f0e2b0e61ee@mail.gmail.com><20080830120134.GA3741@matrix.chaos.earth.li><20080831121055.GA5326@soi.city.ac.uk><20080831121633.GA17919@matrix.chaos.earth.li> <48BE480C.5050308@gmail.com> <2D93D24B65084422832AF68B82EF4106@cr3lt> <48DA55C0.2090406@gmail.com> <77766447D98E4243A6B4B87A3FC61A03@cr3lt> Message-ID: <48DA8568.90002@gmail.com> Claus Reinke wrote: >>>> .., the only sensible way to think about instances is as global >>>> properties. >> ..it has nothing to do with bugs or misfeatures in GHC, it's a fact of >> Haskell 98. > > I thought my example demonstrated quite clearly that instances are *not* > global in Haskell. Yes, I know that you can limit the visibilty of instances by using orphans in Haskell 98. My point was that it is a mistake to design libraries this way, because it leads to a loss of abstraction. >> This is even worse at the level of packages. We can hide modules that >> are used internally to a package's implementation, but we can't hide >> the fact that a package used some non-standard instances internally, >> and furthermore we can't change this aspect of its implementation >> without changing the API. > > How do packages make a difference here? As long as I don't import > base:Control.Monad.Error, the base:Control.Monad.Instances instances > of Functor, say, are not visible in base:Control.Monad. If I write a package that uses Control.Monad.Instances internally, that becomes visible via its API, and I cannot abstract away from this aspect of the implementation of my package. This is an absolute failure of abstraction, and if we value abstraction (which we surely do?) then we should look for ways to fix the problem. So one way is to look at changing the language, perhaps by supporting explicit re-export of instances. Certainly that's a worthwhile direction to explore, but since our current language doesn't have this extension, we have to look for other ways to avoid the problem in the meantime. The only solution is to not have orphan instances in the original library API, which is what I'm arguing for. I think you misunderstood my point before (but you recognised that I repeated it :-). I'm not trying to say that Haskell 98 only supports global instances, rather I'm saying we should think of it that way and design our libraries with global instances in mind, because otherwise we have serious problems with abstraction. We agree that this is a failure of the language. You seem to be arguing that we should pretend that the language is not broken in the hope that it gets fixed in the future - I think that's the wrong approach. > Sadly, that has all been discussed to death already, and again, it is a > matter of being precise. "Orphan" instances are not wrong per se - they > encode and name the extent of type relations via modules, but one needs > to think carefully about their intended use and whether that use is > really supported by the language or just an illusion. Of the top of my > head, I can think of two uses: > > (a) having two instances of the same class for the same types in the > same program only works by "virtue" of #2356, so should be > avoided unless and until the positive aspects of #2356 are moved > from accident to design decision Right, agreed. > (b) giving clients control over which instances they want to use (eg, > use set A or set B, or neither) should work, and mostly does, > but may run into ghc #2182 and haddock #54. Also, it is advisable > only for client applications, not for client libraries, as long as > their users might run into unresolved aspect of (a). I'm not sure what "client libraries" are, but I think I agree, if what you're saying is that orphan instances should be kept out of library APIs. I'd also argue that they shouldn't be used in application code either, but the reasons are less compelling there. > My preference would be to see ghc #2182, #2356 (for Haskell 98 > mode) and haddock #54 fixed. #2356 (for Ghc mode) is documented > behaviour, I believe, inherited from Ghc's handling of overlapping > instances, but there is no LANGUAGE extension specifying this > behaviour, so it isn't portable. I'll just point out that if we stop using orphan instances in library APIs, then #2182 is much less of an issue. > Next, I'd like to see whether more > control over instance re-export is permissible in theory and -if yes- > would like to see it implemented and standardised. Sure, please do! Cheers, Simon From marlowsd at gmail.com Wed Sep 24 14:48:06 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Sep 24 14:45:28 2008 Subject: instance visibility In-Reply-To: <20080924171002.GP1961@darcs.net> References: <48BE480C.5050308@gmail.com> <2D93D24B65084422832AF68B82EF4106@cr3lt> <48DA55C0.2090406@gmail.com> <77766447D98E4243A6B4B87A3FC61A03@cr3lt> <20080924171002.GP1961@darcs.net> Message-ID: <48DA8B66.7020108@gmail.com> David Roundy wrote: > In the interest of providing a concrete example, see the darcs bug: > > http://bugs.darcs.net/issue387 Nice motivation for wanting to *not* import an instance. The first thing that occurs to me is to avoid using UserError - is that feasible? Cheers, Simon From droundy at darcs.net Wed Sep 24 15:09:29 2008 From: droundy at darcs.net (David Roundy) Date: Wed Sep 24 15:06:22 2008 Subject: instance visibility In-Reply-To: <48DA8B66.7020108@gmail.com> References: <48BE480C.5050308@gmail.com> <2D93D24B65084422832AF68B82EF4106@cr3lt> <48DA55C0.2090406@gmail.com> <77766447D98E4243A6B4B87A3FC61A03@cr3lt> <20080924171002.GP1961@darcs.net> <48DA8B66.7020108@gmail.com> Message-ID: <20080924190928.GR1961@darcs.net> On Wed, Sep 24, 2008 at 07:48:06PM +0100, Simon Marlow wrote: > David Roundy wrote: > >> In the interest of providing a concrete example, see the darcs bug: >> >> http://bugs.darcs.net/issue387 > > Nice motivation for wanting to *not* import an instance. > > The first thing that occurs to me is to avoid using UserError - is that > feasible? It's feasible, but extremely ugly, and it seems almost impossible to audit the code for this, as we'd have to look at every instance of fail to see if it might happen to be used in the IO monad. And, of course, we'd have to write our own version of error. Either of these sounds very tricky. fail is a great function (albeit much maligned), and I'd hate to have to replace it throughout the code. Now, if we could avoid importing the Monad instance of IO from the Prelude, then we could write our own instance that would have a fail such as fail = throw . AssertionFailed David From magnus at therning.org Wed Sep 24 15:47:44 2008 From: magnus at therning.org (Magnus Therning) Date: Wed Sep 24 15:44:50 2008 Subject: Proposal: fix iso8601 date in old-time Message-ID: <48DA9960.4060104@therning.org> I just raised http://hackage.haskell.org/trac/ghc/ticket/2626 /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus?therning?org Jabber: magnus?therning?org http://therning.org/magnus Haskell is an even 'redder' pill than Lisp or Scheme. -- PaulPotts -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/libraries/attachments/20080924/c8c29819/signature-0001.bin From claus.reinke at talk21.com Wed Sep 24 13:48:15 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Sep 24 16:49:50 2008 Subject: instance visibility (was: Re: The base library and GHC 6.10) References: <20080828111232.GA15998@matrix.chaos.earth.li> <404396ef0808280428j5f8ce984q904f5f0e2b0e61ee@mail.gmail.com> <20080830120134.GA3741@matrix.chaos.earth.li> <20080831121055.GA5326@soi.city.ac.uk> <20080831121633.GA17919@matrix.chaos.earth.li> <48BE480C.5050308@gmail.com> <2D93D24B65084422832AF68B82EF4106@cr3lt> <48DA55C0.2090406@gmail.com> <77766447D98E4243A6B4B87A3FC61A03@cr3lt> <1222273684.20785.1.camel@jcchost> Message-ID: <789F2E8B18BA4E1B8478A2A1EAA35F23@cr3lt> >> http://www.haskell.org/pipermail/libraries/2008-September/010623.html .. >> What one cannot do (in Haskell 98) is to have two instances of >> the same class, for the same types, in the same import hierarchy. > > Of course, when you consider that Main, by definition, imports every > module in the program directly or indirectly, this is pretty close to > saying `instances are global'. Isn't it? Close, but no cigar!-) The global view accepts strictly more programs than the Haskell 98 view (see the mesage I linked to for an example). It would also refuse some programs that Ghc (in non-Haskell 98 mode) accepts. And would stand in the way of looking for more precise instance import/export control (see both of my messages;-). Claus From jonathanccast at fastmail.fm Wed Sep 24 17:18:28 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Sep 24 17:21:39 2008 Subject: instance visibility (was: Re: The base library and GHC 6.10) In-Reply-To: <789F2E8B18BA4E1B8478A2A1EAA35F23@cr3lt> References: <20080828111232.GA15998@matrix.chaos.earth.li> <404396ef0808280428j5f8ce984q904f5f0e2b0e61ee@mail.gmail.com> <20080830120134.GA3741@matrix.chaos.earth.li> <20080831121055.GA5326@soi.city.ac.uk> <20080831121633.GA17919@matrix.chaos.earth.li> <48BE480C.5050308@gmail.com> <2D93D24B65084422832AF68B82EF4106@cr3lt> <48DA55C0.2090406@gmail.com> <77766447D98E4243A6B4B87A3FC61A03@cr3lt> <1222273684.20785.1.camel@jcchost> <789F2E8B18BA4E1B8478A2A1EAA35F23@cr3lt> Message-ID: <1222291108.20785.39.camel@jcchost> On Wed, 2008-09-24 at 18:48 +0100, Claus Reinke wrote: > >> http://www.haskell.org/pipermail/libraries/2008-September/010623.html > .. > >> What one cannot do (in Haskell 98) is to have two instances of > >> the same class, for the same types, in the same import hierarchy. > > > > Of course, when you consider that Main, by definition, imports every > > module in the program directly or indirectly, this is pretty close to > > saying `instances are global'. Isn't it? > > Close, but no cigar!-) The global view accepts strictly more > programs than the Haskell 98 view (see the mesage I linked > to for an example). Right. I (of course) take the global view as axiomatic, and I view Haskell 98's implementation something like this: If an instance is defined (somewhere in existence), then it should be in scope everywhere. This is indistinguishable, in practice, from being in scope everywhere the class and type are both in scope. However, implementing this would require the implementation to search *every* module with an orphan instance when looking for instances. (Conceptually, this should include all of Hackage; if you use an instance from a package, but nothing else, under --make (or -e or -i) that package should (in principle) still be found and linked in.) Presumably, it's easier to only search the modules you've imported for instances. So a compromise is adopted: modules imported (directly or indirectly) have to be searched, but other modules can safely be ignored. So I view refusing to import one module so you can define/import a conflicting instance as deliberate exploitation of a mis-feature/limitation of the language. > It would also refuse some programs that > Ghc (in non-Haskell 98 mode) accepts. And would stand in > the way of looking for more precise instance import/export > control (see both of my messages;-). Intentionally. I see type class systems where the dictionary type is not intended to be a singleton as a substantively different language feature than what Haskell type classes are intended to be. Both are useful, IMHO; at least, adopting named instances (or what have you) should be viewed as removing one feature from the language and adding another. It's not just an enhancement/strengthening of the language. jcc From dave at zednenem.com Wed Sep 24 17:32:10 2008 From: dave at zednenem.com (David Menendez) Date: Wed Sep 24 17:29:12 2008 Subject: instance visibility (was: Re: The base library and GHC 6.10) In-Reply-To: <1222291108.20785.39.camel@jcchost> References: <20080828111232.GA15998@matrix.chaos.earth.li> <48BE480C.5050308@gmail.com> <2D93D24B65084422832AF68B82EF4106@cr3lt> <48DA55C0.2090406@gmail.com> <77766447D98E4243A6B4B87A3FC61A03@cr3lt> <1222273684.20785.1.camel@jcchost> <789F2E8B18BA4E1B8478A2A1EAA35F23@cr3lt> <1222291108.20785.39.camel@jcchost> Message-ID: <49a77b7a0809241432u53b326b4p4f4d3995dace4dc5@mail.gmail.com> On Wed, Sep 24, 2008 at 5:18 PM, Jonathan Cast wrote: > > Right. I (of course) take the global view as axiomatic, and I view > Haskell 98's implementation something like this: > > If an instance is defined (somewhere in existence), then it should be in > scope everywhere. This is indistinguishable, in practice, from being in > scope everywhere the class and type are both in scope. However, > implementing this would require the implementation to search *every* > module with an orphan instance when looking for instances. > (Conceptually, this should include all of Hackage; if you use an > instance from a package, but nothing else, under --make (or -e or -i) > that package should (in principle) still be found and linked in.) > Presumably, it's easier to only search the modules you've imported for > instances. So a compromise is adopted: modules imported (directly or > indirectly) have to be searched, but other modules can safely be > ignored. > > So I view refusing to import one module so you can define/import a > conflicting instance as deliberate exploitation of a > mis-feature/limitation of the language. Another reason to prefer the global interpretation of instances is that it allows for more efficient, non-dictionary-passing implementations of type classes. Both JHC's type-case and Mark Jones's partial evaluation techniques require instances that are the same everywhere. -- Dave Menendez From igloo at earth.li Thu Sep 25 11:58:36 2008 From: igloo at earth.li (Ian Lynagh) Date: Thu Sep 25 11:55:37 2008 Subject: Splitting SYB from the base package in GHC 6.10 In-Reply-To: <52f14b210809230603n5d7c2fa5ga6a791e48a27bcad@mail.gmail.com> References: <1C4AE74FD8C843B1AAC9D92AE067F090@cr3lt> <20080902210637.GA7519@matrix.chaos.earth.li> <20080903081355.GA2149@soi.city.ac.uk> <638ABD0A29C8884A91BC5FB5C349B1C32AE88093CD@EA-EXMSG-C334.europe.corp.microsoft.com> <52f14b210809150428w4cd4061bg4b855fc44ac11b28@mail.gmail.com> <20080916084133.GA2878@soi.city.ac.uk> <20080922195449.GA22526@matrix.chaos.earth.li> <52f14b210809230603n5d7c2fa5ga6a791e48a27bcad@mail.gmail.com> Message-ID: <20080925155836.GA30388@matrix.chaos.earth.li> Hi Pedro, On Tue, Sep 23, 2008 at 03:03:19PM +0200, Jos? Pedro Magalh?es wrote: > > On Mon, Sep 22, 2008 at 21:54, Ian Lynagh wrote: > > > I'm a little lost as to exactly what changes you want. Can you send a > > darcs patch against the base and syb repos please?: > > http://darcs.haskell.org/ghc-6.10/packages/base/ > > http://darcs.haskell.org/ghc-6.10/packages/syb/ > > Currently everything is in the syb package. > > That's fine, but do I need to build the entire compiler to be able to > compile the base package? If you want to move the Data class then you'll definitely have to rebuild GHC, and to change the line gENERICS = mkSybModule (fsLit "Data.Generics.Basics") to gENERICS = mkBaseModule (fsLit "") in compiler/prelude/PrelNames.lhs > Currently if I try to `runhaskell setup.hs > configure' on base I get `attempting to use module `Prelude' (Prelude.hs) > which is not loaded'... You can't compile programs (like Setup.hs) in a base tree, as it will try to use the modules from the base tree rather than those from the installed base package. Thanks Ian From claus.reinke at talk21.com Thu Sep 25 12:58:58 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Sep 25 12:56:11 2008 Subject: instance visibility References: <20080828111232.GA15998@matrix.chaos.earth.li><404396ef0808280428j5f8ce984q904f5f0e2b0e61ee@mail.gmail.com><20080830120134.GA3741@matrix.chaos.earth.li><20080831121055.GA5326@soi.city.ac.uk><20080831121633.GA17919@matrix.chaos.earth.li> <48BE480C.5050308@gmail.com> <2D93D24B65084422832AF68B82EF4106@cr3lt> <48DA55C0.2090406@gmail.com> <77766447D98E4243A6B4B87A3FC61A03@cr3lt> <48DA8568.90002@gmail.com> Message-ID: <101F6137BA874BDDB349DFF07667A945@cr3lt> > .. I'm not trying to say that Haskell 98 only supports > global instances, rather I'm saying we should think of it that way and > design our libraries with global instances in mind, because otherwise we > have serious problems with abstraction. Thinking of it that way still doesn't make it so. If you want instances to be global, you have to change Haskell 98, by propagating instances through the whole program. Also, you don't mean "global", you mean "at most one per program". The latter matches what Haskell'98 does, but not what Ghc does. The former matches neither, so will lead to trouble in use (just because one user follows your rule, that doesn't mean everyone does, so anytime your user imports a not-invented-here library, his model breaks down). > We agree that this is a failure of the language. You seem to be arguing > that we should pretend that the language is not broken in the hope that > it gets fixed in the future - I think that's the wrong approach. I have been arguing that we need to be more precise and explicit about what is going on, so that we can see exactly in what ways the language or its implementations are broken and so that we can avoid errors arising from mismatched implicit interpretations. >> (b) giving clients control over which instances they want to use (eg, >> use set A or set B, or neither) should work, and mostly does, >> but may run into ghc #2182 and haddock #54. Also, it is advisable >> only for client applications, not for client libraries, as long as >> their users might run into unresolved aspect of (a). > > I'm not sure what "client libraries" are, but I think I agree, if what > you're saying is that orphan instances should be kept out of library > APIs. I'd also argue that they shouldn't be used in application code > either, but the reasons are less compelling there. Assuming that LT, LC, and LIa/LIb, are libraries that provide type, class, and two sets of instances, respectively, then using any combination of these libraries that does not include both LIs in an application A is fine, using LT/LC in a library L is fine, but using any LI in another library is likely to cause trouble later (because the LI instances are implicitly re-exported from L, while L's clients might also have other instances for LT/LC's type and class). >> Next, I'd like to see whether more control over instance re-export is >> permissible in theory and -if yes- would like to see it implemented and >> standardised. > > Sure, please do! Once #2182 is fixed, you will need to implement the basics of this anyway, for ghci sessions (where :m -M should remove access to M's instances), then we just need to provide some syntax for your implementation!-) Claus From claus.reinke at talk21.com Thu Sep 25 13:13:42 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Sep 25 13:10:47 2008 Subject: instance visibility (was: Re: The base library and GHC 6.10) References: <20080828111232.GA15998@matrix.chaos.earth.li> <48BE480C.5050308@gmail.com> <2D93D24B65084422832AF68B82EF4106@cr3lt> <48DA55C0.2090406@gmail.com> <77766447D98E4243A6B4B87A3FC61A03@cr3lt> <1222273684.20785.1.camel@jcchost> <789F2E8B18BA4E1B8478A2A1EAA35F23@cr3lt> <1222291108.20785.39.camel@jcchost> <49a77b7a0809241432u53b326b4p4f4d3995dace4dc5@mail.gmail.com> Message-ID: > Another reason to prefer the global interpretation of instances is > that it allows for more efficient, non-dictionary-passing > implementations of type classes. Both JHC's type-case and Mark Jones's > partial evaluation techniques require instances that are the same > everywhere. Why would partial evaluation require global instances? Mark's prototype implementation ignored separate compilation issues by requiring all modules to be available at specialisation time. But that does not imply that specialisation is limited to a one instance-per-program view, it just has to be clear which instance to specialise at any point. That needs to be clear for any implementation of type classes, with or without dictionaries, but the consequences differ slighly: in a dictionary-based implementation, undecided instances mean dictionaries parameters, to be supplied at usage points; in a dictionary-free implementation, undecided instances mean general code, to be specialised at usage points. Right? Claus From igloo at earth.li Thu Sep 25 14:34:44 2008 From: igloo at earth.li (Ian Lynagh) Date: Thu Sep 25 14:31:45 2008 Subject: instance visibility (was: Re: The base library and GHC 6.10) In-Reply-To: <581247585D1840B0BD0DF8FC4FE8B109@cr3lt> References: <48BE480C.5050308@gmail.com> <2D93D24B65084422832AF68B82EF4106@cr3lt> <48DA55C0.2090406@gmail.com> <77766447D98E4243A6B4B87A3FC61A03@cr3lt> <20080924173835.GA2089@matrix.chaos.earth.li> <581247585D1840B0BD0DF8FC4FE8B109@cr3lt> Message-ID: <20080925183444.GA24247@matrix.chaos.earth.li> Hi Claus, On Wed, Sep 24, 2008 at 07:21:19PM +0100, Claus Reinke wrote: > > >I've put an example showing how multiple instances can cause Data.Set to > >go wrong here: > > http://hackage.haskell.org/trac/ghc/ticket/2356#comment:8 > > > >Do you think that that behaviour is OK? I'm not sure from your reply what your answer to this is. Is it "I don't know whether I think that that behaviour is OK or not"? > Note that I submitted that ticket;-) I think that the behaviour, the > Haskell'98 vs Ghc discrepancy, the comments, and this thread, > show that the rules need to be specified carefully and clearly, While that would be helpful, I think that the behaviour you are interested in only works because it would be expensive to fix it (at least, that's how I understand Simon's "So I'm not sure what to do; and the only thing that comes to mind isn't cheap." comment), not because of any unclarity. I'd be interested to see a design that allows for local instances, in a way that doesn't cause problems like in the URL above, but as far as I know none exist yet. Thanks Ian From claus.reinke at talk21.com Thu Sep 25 17:10:36 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Sep 25 17:07:43 2008 Subject: instance visibility (was: Re: The base library and GHC 6.10) References: <48BE480C.5050308@gmail.com> <2D93D24B65084422832AF68B82EF4106@cr3lt> <48DA55C0.2090406@gmail.com> <77766447D98E4243A6B4B87A3FC61A03@cr3lt> <20080924173835.GA2089@matrix.chaos.earth.li> <581247585D1840B0BD0DF8FC4FE8B109@cr3lt> <20080925183444.GA24247@matrix.chaos.earth.li> Message-ID: <60272DEEE255449B8F29B8DA43F06D6E@cr3lt> Hi Ian, >> > http://hackage.haskell.org/trac/ghc/ticket/2356#comment:8 >> >Do you think that that behaviour is OK? > I'm not sure from your reply what your answer to this is. > > Is it "I don't know whether I think that that behaviour is OK or not"? Your example is a variation of the one that opened the ticket, so no, I do not think this behaviour is OK. But I also think that the situation is too complex for a straightforward answer, hence my less-than-straightforward answer, which perhaps I can expand: (a) it is clearly not ok in Haskell'98 mode (that is the bug) (b) it seems to be an unavoidable consequence of a feature of Ghc's non-Haskell'98 mode (specifically Ghc's interpretation of allow-overlapping-instances) that actual code relies on, so one cannot simply change this behaviour in that mode People starting from viewpoint (a) have completely different expectations than people starting from viewpoint (b), for the same example. And that is clearly not good, so: (c) this issue highlights the need for a better specification, to reduce the confusion (d) the Ghc feature itself is only a work-around for Haskell's limited control over instance visibility. In particular, one cannot prevent re-export of instances in Haskell, so Ghc tries to ensure that such re-export only hurts those who actually try to use such re-exported instances. Haskellers using overlapping instances need to know what they are doing anyway, and Haskellers not using overlapping instances, but using libraries that use overlapping instances, are less likely to run into trouble this way. Therefore, my recommendation was: - follow the Haskell'98 report in Haskell'98 mode (solves (a)) - issue a warning whenever a program contains multiple conflicting or duplicate instances in non-Haskell'98 mode, so that (a)-people don't get hurt by a feature that (b)-people depend on (that warning will confuse, but not hurt, third-party users of (b)-people libraries - the ones meant to be helped by (d)) [this should be done anyway] - look for a real solution to instance re-export (that would avoid (b) by making (d) superfluous) - whatever plan is adopted, document it, as it is likely to be different from Haskell'98, and confusion (c) can lead to hard to find bugs. The new warning should point to this documentation, so that people know what they are being warned about. Is that any clearer?-) >> Note that I submitted that ticket;-) I think that the behaviour, the >> Haskell'98 vs Ghc discrepancy, the comments, and this thread, >> show that the rules need to be specified carefully and clearly, > > While that would be helpful, I think that the behaviour you are > interested in only works because it would be expensive to fix it (at > least, that's how I understand Simon's > "So I'm not sure what to do; and the only thing that comes to mind > isn't cheap." > comment), not because of any unclarity. Well, you could rule out this Ghc feature for any program not using allow-overlapping-instances, but then you get back to the traditional problem (a library uses overlapping instances, a library client doesn't; and the feature is meant to help users who do not want to know which of their libraries use overlapping instances). You can definitely rule it out for Haskell'98 programs, but that won't help much. You could argue that duplicate instances aren't overlapping instances, but that only introduces another special case, and the issue remains for overlapping instances. You cannot rule out this behaviour for overlapping instances, unless you fix instance re-export control first (that is the reason this behaviour was introduced in the first place). Simon's "not cheap" fix refers to the effort implied by fixing the issue for the special case of no-overlapping-instances (same comment, two paragraphs up). There is a righteous approach ("this shouldn't happen. forbid it!"), there is a pragmatic approach ("this does happen. help users somehow!"), but I don't know of any right approach unless the instance re-export control issue is fixed. So I assume fixing that is the right approach!-) > I'd be interested to see a design that allows for local instances, in a > way that doesn't cause problems like in the URL above, but as far as I > know none exist yet. While this has come up now and then, most recently here http://www.haskell.org/pipermail/haskell-prime/2008-May/002601.html http://www.haskell.org/pipermail/libraries/2008-September/010623.html I'm also not aware of a proper design. As I mention in my reply to Simon M, there will actually be an implementation of it in ghci if #2182 is fixed, and it doesn't look too difficult to come up with a syntax, but a proper design would have to look at the theory (does it make sense to have modular logic over types? my guess is yes; if not, we better change Haskell'98 to propagate all instances through the whole program!) and practical consequences (and those tend to be unexpected;-). Simon PJ said that fixing #2182 will need some effort. But after that, perhaps Ghc can experiment with a simple syntax for instance import/ export control (I was thinking of something similar to .hs-boot file syntax, bare 'instance C t' to permit export/import of any matching instances, which would rely on being able to hide items that may not exist), so that users can help figuring out any of those unwanted consequences that are never obvious in theory. Claus From claus.reinke at talk21.com Thu Sep 25 17:49:27 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Sep 25 17:46:47 2008 Subject: instance visibility (was: Re: The base library and GHC 6.10) References: <48BE480C.5050308@gmail.com><2D93D24B65084422832AF68B82EF4106@cr3lt><48DA55C0.2090406@gmail.com><77766447D98E4243A6B4B87A3FC61A03@cr3lt><20080924173835.GA2089@matrix.chaos.earth.li><581247585D1840B0BD0DF8FC4FE8B109@cr3lt><20080925183444.GA24247@matrix.chaos.earth.li> <60272DEEE255449B8F29B8DA43F06D6E@cr3lt> Message-ID: >> I'd be interested to see a design that allows for local instances, in a >> way that doesn't cause problems like in the URL above, but as far as I >> know none exist yet. > > While this has come up now and then, most recently here > > http://www.haskell.org/pipermail/haskell-prime/2008-May/002601.html > http://www.haskell.org/pipermail/libraries/2008-September/010623.html of course, as soon as I hit send I recalled: Wolfram Kahl and Kahl Scheffczyk, Named Instances for Haskell Type Classes http://www.cs.uni-bonn.de/~ralf/hw2001/4.pdf Derek Dreyer, Robert Harper, and Manuel M. T. Chakravarty Modular Type Classes http://www.cse.unsw.edu.au/~chak/papers/DHC07.html while searching for those urls, I also discovered that Paul replied to the 2001 paper in a 1992 email: http://www.cse.unsw.edu.au/~dons/haskell-1990-2000/msg00727.html That's what I call foresight!-) Claus Ps. there have also been encodings of named instances, iirc. From bertram.felgenhauer at googlemail.com Thu Sep 25 20:12:13 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Thu Sep 25 20:09:16 2008 Subject: darcs patch: Fix build with ghc-6.10 Message-ID: <1222387933.10112@zombie> Hi, with the patch below, the head version[1] of bytestring compiles in the ghc tree (replacing libraries/bytestring) and passes validate. No code had to be changed, just the base dependency and a few OPTIONS_GHC pragmas because of orphan instances. enjoy, Bertram [1] http://darcs.haskell.org/bytestring/ not http://darcs.haskell.org/ghc-6.10/packages/bytestring/ or http://darcs.haskell.org/packages/bytestring/ P.S. why does it list libraries@h.o as the maintainer? But never mind, Don reads this list. Tue Sep 23 05:49:33 CEST 2008 Bertram Felgenhauer * Fix build with ghc-6.10 Also fix build with -Werror. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 30641 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/libraries/attachments/20080926/a16fc570/attachment-0001.bin From marcot at riseup.net Fri Sep 26 10:04:29 2008 From: marcot at riseup.net (Marco =?ISO-8859-1?Q?T=FAlio?= Gontijo e Silva) Date: Fri Sep 26 10:01:34 2008 Subject: Some things about haskell-src Message-ID: <1222437869.9985.7.camel@quindinho.domain.invalid> Hello, I'm using haskell-src, and I noticed that the data types defined in Language.Haskell.Syntax don't derive Ord. It makes sense, cause there's no logical way to ordenate them, but it makes it impossible to use with Data.Set functions, such as fromList. It would be good to be possible to use Data.Set with these types, so maybe including deriving Ord to the data types is a good idea. Some other thing I've thought is using operators as type constructors for some types, such as: (:.) = Qual (:$) = HsApp I don't know how much this is possible for other cases, but I think it could make the look of a parsed code clearer. Greetings. -- marcot P?gina: http://marcotmarcot.iaaeee.org/ Blog: http://marcotmarcot.blogspot.com/ Correio: marcot@riseup.net XMPP: marcot@jabber.org IRC: marcot@irc.freenode.net Telefone: 25151920 Celular: 98116720 Endere?o: Rua Turfa, 639/701 Prado 30410-370 Belo Horizonte/MG Brasil From benjovi at gmx.net Fri Sep 26 10:12:17 2008 From: benjovi at gmx.net (Benedikt Huber) Date: Fri Sep 26 10:09:43 2008 Subject: export toDescList from Data.Map In-Reply-To: References: Message-ID: <48DCEDC1.3080401@gmx.net> Hi, Scott Dillard schrieb: > > - I'm not sure what Benedikt Huber meant by 'view', but I think he > means exposing the tree structure, in a read-only way, to users. I think > its a shame that the Map/Set libraries do not expose this. The simplest > solution would be to have toTree functions that convert it to a > Data.Tree, but I don't think anybody actually likes that data type. A > specialized binary tree data type would be more elegant, but there is an > issue of how data is stored in the tree. Map/Set store keys and values > in internal nodes and use null leaves. IntMap/IntSet store all > keys/values in non-null leaves. So maybe this TreeView type would have > to be specific to either Map or IntMap. The idea here is that the > algorithms and data structures used for these trees are well-known. The > papers are linked from the documentation. So the library should expose > this to users, in a safe way. I think that having a function > treeView :: Map k v -> T (k,v) s.t. T is an instance of Foldable, supports efficient left and right folds, and additional operations like subrange queries (all pairs (k,v) s.t. l <= k <= u) would be useful. I'd like to have all functions from Data.Foldable available for folds with key, e.g fold[lr]MWithKey. Supporting toTree (e.g. using a binary tree as you suggested) would be great as well, but I think T (k,v) does not need to be build an intermediate representation for supporting queries/folds, so a newtype should do as well. > - Since someone raised the issue of test suites for performance and > correctness, I think it would also be interesting to investigate what > effect the strictness annotations in the tree constructors have on > performance. > ... > http://www.haskell.org/pipermail/libraries/2008-August/010371.html Did you also measure the effect of removing strictness annotations on space performance ? > For my $0.02 your proposal is good. toDescList is very important to have > in many situations. I've had it un-hidden locally for a while now. It's > silly that it wasn't exported in the first place. +1 for toDescList foldrWithKey is certainly useful as well, but I think one should also think about monadic folds (and the other stuff from Data.Foldable), as explained above. benedikt From qdunkan at gmail.com Fri Sep 26 10:20:02 2008 From: qdunkan at gmail.com (Evan Laforge) Date: Fri Sep 26 10:16:59 2008 Subject: export toDescList from Data.Map In-Reply-To: References: Message-ID: <2518b95d0809260720h6ecd9a7pd6eadbad0ed5b0d6@mail.gmail.com> > - Since someone raised the issue of test suites for performance and > correctness, I think it would also be interesting to investigate what effect > the strictness annotations in the tree constructors have on performance. > Everyone takes for granted that bangs=faster, but I've noticed, as have > others, that removing these strictness annotations actually make things run > faster. Instead, the tree construction _functions_ should be made strict > using seq. The Map construction functions are already strict enough on > account of the balancing. Try it for yourself, remove the bangs from the > sub-tree fields in the Bin constructor, and run a little benchmark. This > would open up the possibility for lazy versions of functions like mapWithKey > and mapKeysMonotonic. I had mentioned this previously, but few seemed to > care, so I just made the change locally. > http://www.haskell.org/pipermail/libraries/2008-August/010371.html . If we > we're going to start a little Map/Set/IntMap/IntSet working group, then I'd > like to throw that idea back into the mix. Of course, anything that boosts performance is a win. Does anyone know of any Map benchmarks? I suppose I could write some, but I'd be sort of surprised if someone else hasn't already done that. Then we could throw in all the various avl / redblack / whatever map variants in there and see how they stack up. > IntMap is hard coded to Int, which is 32 bits on a 32 bit architecture, and > 64 bits on a 64 bit architecture. I think the main reason for this is so > that the key can be > unpacked/specialized for extra performance, since that is the primary > purpose of the library. If you just need sublinear insert/lookup/delete then > use a Map. To be honest, I had no particular rational reason for wanting IntMap (and in fact I'm not using it). I just heard some mumbling on the list about "Data.Map so slow, IntMap so much faster especially for unions". Though to be honest, probably what most matters to me is how much garbage an insert generates (and similarly how much the resulting structures will share). I didn't run any tests or anything, so I wasn't that upset to not be able to use IntMap :) > Are you galled that the key type is not hardcoded to Int64, or that the key > is not allowed to be any instance of the Bits class? In the former case, > you'd inflate the size of the tree and take a small speed hit on 32bit > archs, and in the latter I think you'd have even worse performance. I think > the choice of Int is wise because it is the fastest, and that is the point > of the library, and if you think about it you're not going to be dealing > with more that 2^32 Ints on a 32 bit computer. (What would they be > referencing? Not array positions or file offsets.) If you're trying to Points in time. I was using Int64 at the time, but I'm actually using Doubles now. Plain Data.Map is working fine in practice. > optimize, say, "Map (Int32,Int32) a" into "IntMap64 a", there are other ways > to accomplish that: Ah yes, splitting the numbers would work for 64 bit words. From ross at soi.city.ac.uk Fri Sep 26 10:36:46 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Fri Sep 26 10:33:45 2008 Subject: export toDescList from Data.Map In-Reply-To: <48DCEDC1.3080401@gmx.net> References: <48DCEDC1.3080401@gmx.net> Message-ID: <20080926143646.GA11395@soi.city.ac.uk> On Fri, Sep 26, 2008 at 04:12:17PM +0200, Benedikt Huber wrote: > I think that having a function > > > treeView :: Map k v -> T (k,v) > > s.t. T is an instance of Foldable, supports efficient left and right > folds, and additional operations like subrange queries (all pairs (k,v) > s.t. l <= k <= u) would be useful. > I'd like to have all functions from Data.Foldable available for folds > with key, e.g fold[lr]MWithKey. Map has split and splitLookup for subrange queries, and you could get the folds with mapWithKey (,) :: Map k v -> Map k (k,v) From marlowsd at gmail.com Fri Sep 26 11:33:14 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Sep 26 11:30:36 2008 Subject: instance visibility In-Reply-To: <101F6137BA874BDDB349DFF07667A945@cr3lt> References: <20080828111232.GA15998@matrix.chaos.earth.li><404396ef0808280428j5f8ce984q904f5f0e2b0e61ee@mail.gmail.com><20080830120134.GA3741@matrix.chaos.earth.li><20080831121055.GA5326@soi.city.ac.uk><20080831121633.GA17919@matrix.chaos.earth.li> <48BE480C.5050308@gmail.com> <2D93D24B65084422832AF68B82EF4106@cr3lt> <48DA55C0.2090406@gmail.com> <77766447D98E4243A6B4B87A3FC61A03@cr3lt> <48DA8568.90002@gmail.com> <101F6137BA874BDDB349DFF07667A945@cr3lt> Message-ID: <48DD00BA.5040302@gmail.com> Claus Reinke wrote: >> .. I'm not trying to say that Haskell 98 only supports global >> instances, rather I'm saying we should think of it that way and design >> our libraries with global instances in mind, because otherwise we have >> serious problems with abstraction. > > Thinking of it that way still doesn't make it so. If you want instances > to be global, you have to change Haskell 98, by propagating instances > through the whole program. Sigh. I'm not having much luck convincing you, so let me try a different tack. Here's a scenario I'd like your opinion on: We have a test in GHC's test suite called instance-leak, which tests that none of the Haskell 98 libraries exports the Functor instance for (->). I broke this test recently by accident. How did I break it? By using Data.Map internally in System.Process. The Functor instance for (->) is exported from Control.Monad.Instances, makes its way into Data.Map, then into System.Process and thereby into System, which is a Haskell 98 module. In your opinion, who or what is at fault for this test failure? Think carefully about the ramifications of your answer. Oh, and "Haskell 98" is not a valid answer, because we can't change that. Cheers, Simon From claus.reinke at talk21.com Fri Sep 26 13:44:09 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Fri Sep 26 13:41:13 2008 Subject: instance visibility References: <20080828111232.GA15998@matrix.chaos.earth.li><404396ef0808280428j5f8ce984q904f5f0e2b0e61ee@mail.gmail.com><20080830120134.GA3741@matrix.chaos.earth.li><20080831121055.GA5326@soi.city.ac.uk><20080831121633.GA17919@matrix.chaos.earth.li> <48BE480C.5050308@gmail.com> <2D93D24B65084422832AF68B82EF4106@cr3lt> <48DA55C0.2090406@gmail.com> <77766447D98E4243A6B4B87A3FC61A03@cr3lt> <48DA8568.90002@gmail.com> <101F6137BA874BDDB349DFF07667A945@cr3lt> <48DD00BA.5040302@gmail.com> Message-ID: <9F15806E5F3D4CF09FB497268B55E2D7@cr3lt> > Sigh. I'm not having much luck convincing you, so let me try a And there I thought the goal of this discussion was to reach a common understanding, not to convince anyone of anything.. > different tack. Here's a scenario I'd like your opinion on: > > We have a test in GHC's test suite called instance-leak, which tests > that none of the Haskell 98 libraries exports the Functor instance for > (->). I broke this test recently by accident. How did I break it? By > using Data.Map internally in System.Process. The Functor instance for > (->) is exported from Control.Monad.Instances, makes its way into > Data.Map, then into System.Process and thereby into System, which is a > Haskell 98 module. > > In your opinion, who or what is at fault for this test failure? You, of course:-p But seriously: I can't see easily how the instance even gets into Data.Map, but since Data.Map doesn't seem to be using either Functor or fmap (other than defining an instance itself), it has no business importing (and thus re-exporting) the instance. If it is actually using any of the other instances (is it?), then perhaps Control.Monad.Instances needs to be split up. That is the approach taken for Data.Generics.Instances, which also has no business being imported in Data.Map. Btw, it would be useful to have a tool for tracing instances (not just final export and original definition, but the import path in between). And it would be useful to see exported instances for each module in Haddock (not just alongside class and type). > Think carefully about the ramifications of your answer. That was my quick answer. Do you think it will change?-) Claus From sedillard at gmail.com Fri Sep 26 13:57:01 2008 From: sedillard at gmail.com (Scott Dillard) Date: Fri Sep 26 13:53:58 2008 Subject: Map / IntMap laziness (was: export toDescList from Data.Map) Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: IBench1.hs Type: text/x-haskell Size: 2034 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20080926/033a06ac/IBench1-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: IntMapLazy.hs Type: text/x-haskell Size: 69889 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20080926/033a06ac/IntMapLazy-0001.bin From sedillard at gmail.com Fri Sep 26 14:00:16 2008 From: sedillard at gmail.com (Scott Dillard) Date: Fri Sep 26 13:57:17 2008 Subject: Map / IntMap laziness (was: export toDescList from Data.Map) In-Reply-To: References: Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: IBench1.hs Type: text/x-haskell Size: 2034 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20080926/90a06a1b/IBench1-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: IntMapLazy.hs Type: text/x-haskell Size: 69889 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20080926/90a06a1b/IntMapLazy-0001.bin From sedillard at gmail.com Fri Sep 26 14:01:48 2008 From: sedillard at gmail.com (Scott Dillard) Date: Fri Sep 26 13:58:45 2008 Subject: Fwd: Map / IntMap laziness (was: export toDescList from Data.Map) In-Reply-To: References: Message-ID: (Sorry for the spam, but I don't understand why the body of my messages is being stripped. Something to do with the attachments?) ---------- Forwarded message ---------- From: Scott Dillard Date: Fri, Sep 26, 2008 at 11:57 AM Subject: Map / IntMap laziness (was: export toDescList from Data.Map) To: Evan Laforge Cc: libraries@haskell.org On Fri, Sep 26, 2008 at 8:20 AM, Evan Laforge wrote: > Of course, anything that boosts performance is a win. Does anyone > know of any Map benchmarks? I suppose I could write some, but I'd be > sort of surprised if someone else hasn't already done that. Then we > could throw in all the various avl / redblack / whatever map variants > in there and see how they stack up. I'm sure everyone has a benchmark floating around. I've attached the one I've been using. As we all know from following the shootout rankings, a single benchmark is pointless and misleading. Better to have targeted benchmarks for specific use patterns. The problem is that search trees are used in so many ways. I've divided it up into two domains: inputs and queries. Then you get a single micro-benchmark by picking one thing in each domain. Here's what I've got Inputs : - Random - Random with duplicates - Sequential - The union of many small (100 or so) random sets Queries : - Sum all keys (or values) - Sum a random subset of keys (may or may not be present in the map) That last query takes an additional parameter, how large of a subset to search for. This is important to capture the case when you build a map but only query it a few times. I can't think of when I've done this, but laziness is a big win here, just as in "take n . sort" for big lists and small n. I've made an optionally-lazy IntMap (attached). I removed the bangs from the tree node constructors and replaced them with seqs in the functions. I've only added strictness to the "one-at-a-time" functions: insert, delete, update, etc. I've let all the functions of type Map -> Map -> Map become lazy. Here is the speedup I get for performing a single lookup on the result of the union 10000 lists, each of size 100. STRICT: 976,823,060 bytes allocated in the heap 572,439,796 bytes copied during GC (scavenged) 3,426,580 bytes copied during GC (not scavenged) 31,641,600 bytes maximum residency (21 sample(s)) 1864 collections in generation 0 ( 2.76s) 21 collections in generation 1 ( 1.76s) 84 Mb total memory in use MUT time 3.70s ( 3.79s elapsed) GC time 4.52s ( 4.58s elapsed) Total time 8.22s ( 8.38s elapsed) %GC time 55.0% (54.7% elapsed) Productivity 45.0% of total user, 44.1% of total elapsed real 0m8.391s user 0m8.217s sys 0m0.172s LAZY: 740,632,056 bytes allocated in the heap 147,902,632 bytes copied during GC (scavenged) 3,316,016 bytes copied during GC (not scavenged) 32,079,872 bytes maximum residency (7 sample(s)) 1412 collections in generation 0 ( 0.60s) 7 collections in generation 1 ( 0.42s) 66 Mb total memory in use MUT time 1.96s ( 2.02s elapsed) GC time 1.02s ( 1.09s elapsed) Total time 2.98s ( 3.10s elapsed) %GC time 34.2% (35.0% elapsed) Productivity 65.8% of total user, 63.3% of total elapsed real 0m3.114s user 0m2.984s sys 0m0.132s This difference quickly disappears as the size of the query set increases, but I've not been able to get the lazy version to go slower. In all use-cases that I've tried, lazy IntMaps and Maps performed no worse than the current strict implementations. The difference between lazy and strict tree constructors is less pronounced with Data.Map. I can't get it to make much of a difference. Using seq instead of bangs seems to speed things up a little, but I think this is spurious compiler behavior. Keeping the tree balanced limits how much work you can put off, so really the only benefit for Data.Map is in functions like mapKeysMonotonic and mapWithKey, but I still think it would be useful to have lazy versions of those functions. The trie on which IntMap is based allows for a lot more laziness because its structure only changes along the path between the root and the point of operation. This is why lazy unioning works so well. This will become even more useful as we all start writing parallel code (which of course we all plan to start doing Real Soon Now) because "foldr insert" doesn't parallelize but "unions . map singleton" does. The issue then is how to expose this laziness. I think the semantics (lazy or strict) of the currently exported functions should not be changed. Instead there should be lazy functions, either named like unionL, or put in a Lazy submodule. The submodule approach seems better to me but it would necessitate splitting up the library into more than 2 files. Data.Map.Base, Data.Map.Strict, Data.Map.Lazy, etc. The current interface would be rexported from Data.Map, unchanged. To be honest, I had no particular rational reason for wanting IntMap > (and in fact I'm not using it). I just heard some mumbling on the > list about "Data.Map so slow, IntMap so much faster especially for > unions". Though to be honest, probably what most matters to me is how > much garbage an insert generates (and similarly how much the resulting > structures will share). I didn't run any tests or anything, so I > wasn't that upset to not be able to use IntMap :) > They are currently the best option for pure, persistent arrays. Better even than Data.Sequence. (I'm told.) I use them a lot. You heard right about unioning. The above mentioned benchmark takes 18 seconds with a Map. They generate much less garbage because less of the tree is mutated after an insert/delete. > Points in time. I was using Int64 at the time, but I'm actually using > Doubles now. Plain Data.Map is working fine in practice. Yeah for that use-case I don't think you'll beat a good balanced binary tree, not in any language. A bit-trie won't really work because you could have duplicate entries (+/- 0) and they wouldn't be stored in sorted order. Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20080926/be31bc25/attachment.htm From sedillard at ucdavis.edu Fri Sep 26 14:27:40 2008 From: sedillard at ucdavis.edu (Scott Dillard) Date: Fri Sep 26 14:24:37 2008 Subject: Libraries Digest, Vol 61, Issue 23 In-Reply-To: <20080926175401.C1F9832497A@www.haskell.org> References: <20080926175401.C1F9832497A@www.haskell.org> Message-ID: > Date: Fri, 26 Sep 2008 15:36:46 +0100 > From: Ross Paterson > > On Fri, Sep 26, 2008 at 04:12:17PM +0200, Benedikt Huber wrote: > > I think that having a function > > > > > treeView :: Map k v -> T (k,v) > > > > s.t. T is an instance of Foldable, supports efficient left and right > > folds, and additional operations like subrange queries (all pairs (k,v) > > s.t. l <= k <= u) would be useful. > > I'd like to have all functions from Data.Foldable available for folds > > with key, e.g fold[lr]MWithKey. > > Map has split and splitLookup for subrange queries, and you could get > the folds with > > mapWithKey (,) :: Map k v -> Map k (k,v) > > I don't follow FP research, but has anyone formalized the "divide and conquer" strategy into a type class? I guess it would be something like MapReduce, but I don't know what the details of that framework are. Something like... class DivideAndConquer t where mapReduce :: (a -> b) -> (b -> b -> b) -> t a -> b splitLookup can get you close, but the user does not know a good split position, so he has to guess something like halfway between min and max. I think in a many-core setting this would be a heavily used method. Data.Map and Data.Sequence would be very good at implementing it because they are balanced, but Data.Tree and Data.IntMap can also do it, just not with good load-balancing guarantees. The other option, related to this thread, is to just have a BinTree data type, like Data.Tree but strictly binary, and have the various balanced-tree libraries provide views of that type. Then one needs to write mapReduce for only one data type. Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20080926/6646d781/attachment.htm From benjovi at gmx.net Fri Sep 26 14:29:48 2008 From: benjovi at gmx.net (Benedikt Huber) Date: Fri Sep 26 14:26:46 2008 Subject: export toDescList from Data.Map In-Reply-To: <20080926143646.GA11395@soi.city.ac.uk> References: <48DCEDC1.3080401@gmx.net> <20080926143646.GA11395@soi.city.ac.uk> Message-ID: <48DD2A1C.5040004@gmx.net> Ross Paterson schrieb: > On Fri, Sep 26, 2008 at 04:12:17PM +0200, Benedikt Huber wrote: >> I think that having a function >> >>> treeView :: Map k v -> T (k,v) >> s.t. T is an instance of Foldable, supports efficient left and right >> folds, and additional operations like subrange queries (all pairs (k,v) >> s.t. l <= k <= u) would be useful. >> I'd like to have all functions from Data.Foldable available for folds >> with key, e.g fold[lr]MWithKey. > > Map has split and splitLookup for subrange queries, and you could get > the folds with > > mapWithKey (,) :: Map k v -> Map k (k,v) Thanks for the pointing this out. While browsing Data.Map I noted that the Foldable instance only defines foldMap - it is notably slower to use Data.Map - Foldable.foldr compared to Map.fold. Adding > instance Foldable (Map k) where > foldMap = ... > foldr f = foldr (const f) > foldl f = foldl (\b _ a -> f b a) really helps. There is also a notable performance penalty using mapWithKey as you suggested, but otherwise it does the job. I still think that toTree or treeView would be interesting, but others might disagree of course. For range queries, split should indeed be sufficient, though a specialized function might be faster. Finally I've attached a (very simple) microbenchmark to demonstrate the need for adding foldr,foldl to the Foldable instance of Data.Map. best regards, benedikt -- Timings {without additional Foldable definitions}/{with foldl,foldr definitions for foldable} -- fold asc-list -- {1.35} testFold_1 = foldr (uncurry f) 0 . M.toAscList -- foldWithKey (foldWithKey) -- {1.45} testFold_2 = M.foldWithKey f 0 -- fold M.mapWithKey (,) -- {9.0 / 3.25} testFold_3 = foldr (uncurry f) 0 . M.mapWithKey (,) -- fold without key (Foldable.foldr) -- {5.06 / 1.35} testFold_4 = foldr (f 0) 0 -- fold (elems.mapWithKey) -- {3.75} testFold_6 = foldr (uncurry f) 0 . M.elems . M.mapWithKey (,) f k v b = b*7+k+2*v main = go testFold_1 0 (M.empty) where go f 5000 = putStrLn "" go f k m = putStr (show (f m) ++ " ") >> go f (succ k) (M.insert k (2*k) m) From claus.reinke at talk21.com Fri Sep 26 14:37:24 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Fri Sep 26 14:34:33 2008 Subject: instance visibility References: <20080828111232.GA15998@matrix.chaos.earth.li><404396ef0808280428j5f8ce984q904f5f0e2b0e61ee@mail.gmail.com><20080830120134.GA3741@matrix.chaos.earth.li><20080831121055.GA5326@soi.city.ac.uk><20080831121633.GA17919@matrix.chaos.earth.li> <48BE480C.5050308@gmail.com><2D93D24B65084422832AF68B82EF4106@cr3lt><48DA55C0.2090406@gmail.com><77766447D98E4243A6B4B87A3FC61A03@cr3lt> <48DA8568.90002@gmail.com><101F6137BA874BDDB349DFF07667A945@cr3lt><48DD00BA.5040302@gmail.com> <9F15806E5F3D4CF09FB497268B55E2D7@cr3lt> Message-ID: >> We have a test in GHC's test suite called instance-leak, which tests that none of the Haskell 98 >> libraries exports the Functor instance for (->). I broke this test recently by accident. How >> did I break it? By using Data.Map internally in System.Process. The Functor instance for (->) >> is exported from Control.Monad.Instances, makes its way into Data.Map, then into System.Process >> and thereby into System, which is a Haskell 98 module. >> >> In your opinion, who or what is at fault for this test failure? > > You, of course:-p > But seriously: I can't see easily how the instance even gets into Data.Map, but since Data.Map > doesn't seem to be using either > Functor or fmap (other than defining an instance itself), it has no business importing (and thus > re-exporting) the instance. If it is > actually using any of the other instances (is it?), then perhaps > Control.Monad.Instances needs to be split up. It seems that the ultimate offender is Control.Applicative, which imports Control.Monad.Instances() for no other reason than to infect its importers. That then propagates all over the place. I assume the rationale is "convenience" again? Saving one import in importers at the price of limiting the modules that can afford to import Control.Applicative in the first place? Since libraries@ is the maintainer for Control.Applicative, may I suggest to add Control.Applicative.Alt, differing from the original only in omitting the import of Control.Monad.Instances? Then all importers of Control.Applicative should be checked for whether import of Control.Applicative.Alt is sufficient, and be switched to that if possible. Or am I on the wrong track?-) Claus From allbery at ece.cmu.edu Fri Sep 26 15:31:22 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Sep 26 15:28:23 2008 Subject: Map / IntMap laziness (was: export toDescList from Data.Map) In-Reply-To: References: Message-ID: On Sep 26, 2008, at 14:01 , Scott Dillard wrote: > (Sorry for the spam, but I don't understand why the body of my > messages is being stripped. Something to do with the attachments?) At a guess, your mailer is configured to use "rich text" or "HTML" mail; the mailing list will only handle text/plain messages, either as the only content or as part of a multipart/alternative. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20080926/62efeff9/attachment.htm From apfelmus at quantentunnel.de Fri Sep 26 16:43:11 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Fri Sep 26 16:40:17 2008 Subject: Fwd: Map / IntMap laziness (was: export toDescList from Data.Map) In-Reply-To: References: Message-ID: Scott Dillard wrote: > (Sorry for the spam, but I don't understand why the body of my messages is > being stripped. Something to do with the attachments?) I'm reading it through gmane and it works for me... > ---------- Forwarded message ---------- > From: Scott Dillard > Date: Fri, Sep 26, 2008 at 11:57 AM > Subject: Map / IntMap laziness (was: export toDescList from Data.Map) > To: Evan Laforge > Cc: libraries@haskell.org > > > > On Fri, Sep 26, 2008 at 8:20 AM, Evan Laforge wrote: > >> Of course, anything that boosts performance is a win. Does anyone >> know of any Map benchmarks? I suppose I could write some, but I'd be >> sort of surprised if someone else hasn't already done that. Then we >> could throw in all the various avl / redblack / whatever map variants >> in there and see how they stack up. > > > I'm sure everyone has a benchmark floating around. I've attached the one > I've been using. As we all know from following the shootout rankings, a > single benchmark is pointless and misleading. Better to have targeted > benchmarks for specific use patterns. The problem is that search trees are > used in so many ways. I've divided it up into two domains: inputs and > queries. Then you get a single micro-benchmark by picking one thing in each > domain. Here's what I've got > > Inputs : > - Random > - Random with duplicates > - Sequential > - The union of many small (100 or so) random sets > > Queries : > - Sum all keys (or values) > - Sum a random subset of keys (may or may not be present in the map) > [etc] > > Yeah for that use-case I don't think you'll beat a good balanced binary > tree, not in any language. A bit-trie won't really work because you could > have duplicate entries (+/- 0) and they wouldn't be stored in sorted order. > > Scott From marlowsd at gmail.com Fri Sep 26 16:51:07 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Sep 26 16:48:28 2008 Subject: instance visibility In-Reply-To: References: <20080828111232.GA15998@matrix.chaos.earth.li><404396ef0808280428j5f8ce984q904f5f0e2b0e61ee@mail.gmail.com><20080830120134.GA3741@matrix.chaos.earth.li><20080831121055.GA5326@soi.city.ac.uk><20080831121633.GA17919@matrix.chaos.earth.li> <48BE480C.5050308@gmail.com><2D93D24B65084422832AF68B82EF4106@cr3lt><48DA55C0.2090406@gmail.com><77766447D98E4243A6B4B87A3FC61A03@cr3lt> <48DA8568.90002@gmail.com><101F6137BA874BDDB349DFF07667A945@cr3lt><48DD00BA.5040302@gmail.com> <9F15806E5F3D4CF09FB497268B55E2D7@cr3lt> Message-ID: <48DD4B3B.3040504@gmail.com> Claus Reinke wrote: >>> We have a test in GHC's test suite called instance-leak, which tests that none of the Haskell 98 >>> libraries exports the Functor instance for (->). I broke this test recently by accident. How >>> did I break it? By using Data.Map internally in System.Process. The Functor instance for (->) >>> is exported from Control.Monad.Instances, makes its way into Data.Map, then into System.Process >>> and thereby into System, which is a Haskell 98 module. >>> >>> In your opinion, who or what is at fault for this test failure? >> You, of course:-p >> But seriously: I can't see easily how the instance even gets into Data.Map, but since Data.Map >> doesn't seem to be using either >> Functor or fmap (other than defining an instance itself), it has no business importing (and thus >> re-exporting) the instance. If it is >> actually using any of the other instances (is it?), then perhaps >> Control.Monad.Instances needs to be split up. > > It seems that the ultimate offender is Control.Applicative, which > imports Control.Monad.Instances() for no other reason than to > infect its importers. That then propagates all over the place. Good! I completely disagree. Control.Monad.Instances is at fault for exposing an orphan instance in the first place. Every other answer to the question leads to problems, I claim. Why is it wrong to say that Control.Applicative, or Data.Map, or my use of Data.Map in System.Process, are at fault? Because all of these modules just happen to be importing something that exports an orphan instance, and they can't be held responsible for re-exposing the orphan instance because they have no control over that. You will argue that they have control over what they import, and can thereby control whether they export the instance. This is certainly true, but it ignores the need for module abstraction: the need to be able to change the implementation of a module without changing its API. We must have the property that the imports of a module do not affect its API - and the only way to have this property is to avoid orphan instances in library APIs. (hmm, I finally feel like I've explained this clearly. I hope it comes across that way.) There are basically only two sensible choices for the Functor instance for (->): (a) don't define one at all (b) define one in Control.Monad, and give up on Haskell 98 compliance The current situation, namely (c) define it as an orphan, and give up on module abstraction is not a sensible choice. Incedentally, Iavor Diatchki pointed out to me today a nice way to provide "optional" instances for things in libraries. In your library if you have an abstract type T and want to suggest, but not mandate, a Functor instance, then you could export a function fmapT :: (a->b) -> T a -> T b so that a client can easily say instance Functor T where fmap = fmapT if they want. (but not in a library! A library would have to wrap T in a newtype to avoid an orphan instance.) > I assume the rationale is "convenience" again? Saving one import > in importers at the price of limiting the modules that can afford to > import Control.Applicative in the first place? > > Since libraries@ is the maintainer for Control.Applicative, may > I suggest to add Control.Applicative.Alt, differing from the original > only in omitting the import of Control.Monad.Instances? Then all > importers of Control.Applicative should be checked for whether > import of Control.Applicative.Alt is sufficient, and be switched > to that if possible. That justs moves the problem around, and doesn't fix it. Cheers, Simon From dave at zednenem.com Fri Sep 26 17:26:41 2008 From: dave at zednenem.com (David Menendez) Date: Fri Sep 26 17:23:37 2008 Subject: instance visibility In-Reply-To: References: <20080828111232.GA15998@matrix.chaos.earth.li> <48BE480C.5050308@gmail.com> <2D93D24B65084422832AF68B82EF4106@cr3lt> <48DA55C0.2090406@gmail.com> <77766447D98E4243A6B4B87A3FC61A03@cr3lt> <48DA8568.90002@gmail.com> <101F6137BA874BDDB349DFF07667A945@cr3lt> <48DD00BA.5040302@gmail.com> <9F15806E5F3D4CF09FB497268B55E2D7@cr3lt> Message-ID: <49a77b7a0809261426h5ecbd213re99fdc49c11b56ac@mail.gmail.com> On Fri, Sep 26, 2008 at 2:37 PM, Claus Reinke wrote: > It seems that the ultimate offender is Control.Applicative, which > imports Control.Monad.Instances() for no other reason than to > infect its importers. That then propagates all over the place. Control.Applicative defines Applicative instances for (->) and (,). Doing so requires Functor instances for (->) and (,), which are defined in Control.Monad.Instances. I suppose one solution would be to move the Applicative instances for (->) and (,) to Control.Monad.Instances. -- Dave Menendez From claus.reinke at talk21.com Fri Sep 26 17:31:15 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Fri Sep 26 17:28:16 2008 Subject: instance visibility References: <20080828111232.GA15998@matrix.chaos.earth.li><404396ef0808280428j5f8ce984q904f5f0e2b0e61ee@mail.gmail.com><20080830120134.GA3741@matrix.chaos.earth.li><20080831121055.GA5326@soi.city.ac.uk><20080831121633.GA17919@matrix.chaos.earth.li> <48BE480C.5050308@gmail.com><2D93D24B65084422832AF68B82EF4106@cr3lt><48DA55C0.2090406@gmail.com><77766447D98E4243A6B4B87A3FC61A03@cr3lt> <48DA8568.90002@gmail.com><101F6137BA874BDDB349DFF07667A945@cr3lt><48DD00BA.5040302@gmail.com> <9F15806E5F3D4CF09FB497268B55E2D7@cr3lt> <48DD4B3B.3040504@gmail.com> Message-ID: > Good! I completely disagree. Ok. Since we now agree to disagree on the solution, but seem to agree on the problem, if not the language used to describe it (sigh:), it might be useful to note that our suggested approaches are somewhat dual: A every instance should be available as widely as possible B no instance should be available more widely than necessary One consequence of following A is that it doesn't matter whether an imported module exports instances, because anyone possibly affected by them will have them anyway. That is less flexible than B, as A doesn't allow for localised instances, but that limitation is in line with Haskell'98 and means that the only trouble that can arise from conflicting instances is that a program doesn't compile. This means that some code can't be written, because missing instances can't be added to external libraries, which also means that there can't be two libraries providing or using different instances for a shared class/type. One consequence of following B is that very fine control over instance import and export needs to be exercised, with the benefit that localised instances become thinkable (they have been possible in Ghc for some time, but could be put on a less adhoc basis), at the expense of having to think carefully about possible conflicts arising from different libraries providing or using different instances for a shared class/type. This means that the current language limitations become very visible, as they interfere with the fine control of instance re-export, which also means that it is easy to mess up. As for orphan instances, approach A forbids them entirely, while approach B forbids importing them into libraries (in the present context, a library module is a module that can be imported). So, in B, orphan instances can only be imported into applications (modules that aren't themselves imported). If one absolutely needs to combine a library L with some orphan instance module O, one should provide two versions of L, one with and one without importing O. As for language limitations, approach A tends to adapt to them, while approach B tends to highlight them. I hope that summary isn't too biased?-) > instance Functor T where fmap = fmapT Providing default instance method implementations instead of instances is indeed used in practice, eg Data.Traversable. >> Since libraries@ is the maintainer for Control.Applicative, may >> I suggest to add Control.Applicative.Alt, differing from the original >> only in omitting the import of Control.Monad.Instances? Then all >> importers of Control.Applicative should be checked for whether >> import of Control.Applicative.Alt is sufficient, and be switched >> to that if possible. > > That justs moves the problem around, and doesn't fix it. While giving up Haskell'98 compatibility, as in your suggestion, cuts the Gordian Knot? I don't think so, but then we tend to disagree on such things;-) Would anyone else like to venture an opinion? Claus From duncan.coutts at worc.ox.ac.uk Fri Sep 26 17:41:27 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Sep 26 17:38:24 2008 Subject: instance visibility In-Reply-To: <48DD4B3B.3040504@gmail.com> References: <20080828111232.GA15998@matrix.chaos.earth.li> <404396ef0808280428j5f8ce984q904f5f0e2b0e61ee@mail.gmail.com> <20080830120134.GA3741@matrix.chaos.earth.li> <20080831121055.GA5326@soi.city.ac.uk> <20080831121633.GA17919@matrix.chaos.earth.li> <48BE480C.5050308@gmail.com> <2D93D24B65084422832AF68B82EF4106@cr3lt><48DA55C0.2090406@gmail.com> <77766447D98E4243A6B4B87A3FC61A03@cr3lt> <48DA8568.90002@gmail.com> <101F6137BA874BDDB349DFF07667A945@cr3lt><48DD00BA.5040302@gmail.com> <9F15806E5F3D4CF09FB497268B55E2D7@cr3lt> <48DD4B3B.3040504@gmail.com> Message-ID: <1222465287.4242.28.camel@dell.linuxdev.us.dell.com> On Fri, 2008-09-26 at 21:51 +0100, Simon Marlow wrote: > You will argue that they have control over what they import, and can > thereby control whether they export the instance. This is certainly > true, but it ignores the need for module abstraction: the need to be > able to change the implementation of a module without changing its API. > We must have the property that the imports of a module do not affect > its API - and the only way to have this property is to avoid orphan > instances in library APIs. > > (hmm, I finally feel like I've explained this clearly. I hope it comes > across that way.) Yes, I think that's a clear explanation and one I think is quite convincing. > There are basically only two sensible choices for the Functor instance > for (->): > > (a) don't define one at all > (b) define one in Control.Monad, and give up on Haskell 98 compliance > > The current situation, namely > > (c) define it as an orphan, and give up on module abstraction > > is not a sensible choice. Right. No orphan instances in libraries. Duncan From claus.reinke at talk21.com Fri Sep 26 17:46:52 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Fri Sep 26 17:43:53 2008 Subject: instance visibility References: <20080828111232.GA15998@matrix.chaos.earth.li> <48BE480C.5050308@gmail.com> <2D93D24B65084422832AF68B82EF4106@cr3lt> <48DA55C0.2090406@gmail.com> <77766447D98E4243A6B4B87A3FC61A03@cr3lt> <48DA8568.90002@gmail.com> <101F6137BA874BDDB349DFF07667A945@cr3lt> <48DD00BA.5040302@gmail.com> <9F15806E5F3D4CF09FB497268B55E2D7@cr3lt> <49a77b7a0809261426h5ecbd213re99fdc49c11b56ac@mail.gmail.com> Message-ID: <4908908539C74CD0AC571F6276F0070C@cr3lt> > On Fri, Sep 26, 2008 at 2:37 PM, Claus Reinke wrote: >> It seems that the ultimate offender is Control.Applicative, which >> imports Control.Monad.Instances() for no other reason than to >> infect its importers. That then propagates all over the place. > > Control.Applicative defines Applicative instances for (->) and (,). > Doing so requires Functor instances for (->) and (,), which are > defined in Control.Monad.Instances. Wouldn't it be possible just to delay the instance selection? instance Applicative ((->) a) where would become instance Functor ((->)a) => Applicative ((->) a) where But, that code doesn't seem to require the instances? Only I just noticed that Control.Applicative imports Control.Arrow, which imports Control.Monad.Fix, which imports Control.Monad.Instances. We can apply the constraint delay in Control.Monad.Fix, making instance Functor ((->)r) => MonadFix ((->)r) but that requires {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE FlexibleContexts #-} (the need for the former highlights another language limitation..) Claus > I suppose one solution would be to move the Applicative instances for > (->) and (,) to Control.Monad.Instances. > > -- > Dave Menendez > From kahl at cas.mcmaster.ca Fri Sep 26 21:25:44 2008 From: kahl at cas.mcmaster.ca (kahl@cas.mcmaster.ca) Date: Fri Sep 26 21:22:45 2008 Subject: instance visibility In-Reply-To: <48DD4B3B.3040504@gmail.com> (message from Simon Marlow on Fri, 26 Sep 2008 21:51:07 +0100) References: <20080828111232.GA15998@matrix.chaos.earth.li><404396ef0808280428j5f8ce984q904f5f0e2b0e61ee@mail.gmail.com><20080830120134.GA3741@matrix.chaos.earth.li><20080831121055.GA5326@soi.city.ac.uk><20080831121633.GA17919@matrix.chaos.earth.li> <48BE480C.5050308@gmail.com><2D93D24B65084422832AF68B82EF4106@cr3lt><48DA55C0.2090406@gmail.com><77766447D98E4243A6B4B87A3FC61A03@cr3lt> <48DA8568.90002@gmail.com><101F6137BA874BDDB349DFF07667A945@cr3lt><48DD00BA.5040302@gmail.com> <9F15806E5F3D4CF09FB497268B55E2D7@cr3lt> <48DD4B3B.3040504@gmail.com> Message-ID: <20080927012544.10225.qmail@schroeder.cas.mcmaster.ca> Simon Marlow wrote: > We must have the property that the imports of a module do not affect > its API - and the only way to have this property is to avoid orphan > instances in library APIs. To be more precise, I would say that each orphan instance in a library API must be the only export of a dedicated visible module, and only exported by that module. (The only importers of orphan instances are typically Main modules, or ``almost-Main'' modules.) > > There are basically only two sensible choices for the Functor instance > for (->): > > (a) don't define one at all > (b) define one in Control.Monad, and give up on Haskell 98 compliance > > The current situation, namely > > (c) define it as an orphan, and give up on module abstraction > > is not a sensible choice. I would say that there should the a separate module Data.Function.Functor () exporting only that instance. (And I find it a surprising decision of Haskell98 that something that is so obviously a functor in so obviously only one way must not be a Functor instance...) Wolfram From marlowsd at gmail.com Sat Sep 27 08:47:22 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Sat Sep 27 08:44:41 2008 Subject: instance visibility In-Reply-To: <20080927012544.10225.qmail@schroeder.cas.mcmaster.ca> References: <20080828111232.GA15998@matrix.chaos.earth.li><404396ef0808280428j5f8ce984q904f5f0e2b0e61ee@mail.gmail.com><20080830120134.GA3741@matrix.chaos.earth.li><20080831121055.GA5326@soi.city.ac.uk><20080831121633.GA17919@matrix.chaos.earth.li> <48BE480C.5050308@gmail.com><2D93D24B65084422832AF68B82EF4106@cr3lt><48DA55C0.2090406@gmail.com><77766447D98E4243A6B4B87A3FC61A03@cr3lt> <48DA8568.90002@gmail.com><101F6137BA874BDDB349DFF07667A945@cr3lt><48DD00BA.5040302@gmail.com> <9F15806E5F3D4CF09FB497268B55E2D7@cr3lt> <48DD4B3B.3040504@gmail.com> <20080927012544.10225.qmail@schroeder.cas.mcmaster.ca> Message-ID: <48DE2B5A.5070605@gmail.com> kahl@cas.mcmaster.ca wrote: > Simon Marlow wrote: > > > We must have the property that the imports of a module do not affect > > its API - and the only way to have this property is to avoid orphan > > instances in library APIs. > > To be more precise, I would say that each orphan instance in a library API > must be the only export of a dedicated visible module, > and only exported by that module. > > (The only importers of orphan instances are typically Main modules, > or ``almost-Main'' modules.) Why do you believe that? We seem to have evidence to the contrary, with Control.Monad.Instances being imported by library modules. Cheers, Simon From jgbailey at gmail.com Sat Sep 27 14:46:00 2008 From: jgbailey at gmail.com (Justin Bailey) Date: Sat Sep 27 14:42:53 2008 Subject: Cabal 1.4.0.2 won't configure on Vista Message-ID: As I posted in ticket #360 (http://hackage.haskell.org/trac/hackage/ticket/360), the latest Cabal on hackage won't configure on Vista. Using GHC 6.8.3, when I run the "configure" command, I get this error: "During interactive linking, GHCi couldn't find the following symbol: SHGetFolderPathA@20 This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line" Any ideas? Justin From kahl at cas.mcmaster.ca Sat Sep 27 16:06:54 2008 From: kahl at cas.mcmaster.ca (kahl@cas.mcmaster.ca) Date: Sat Sep 27 16:03:52 2008 Subject: instance visibility In-Reply-To: <48DE2B5A.5070605@gmail.com> (message from Simon Marlow on Sat, 27 Sep 2008 13:47:22 +0100) References: <20080828111232.GA15998@matrix.chaos.earth.li><404396ef0808280428j5f8ce984q904f5f0e2b0e61ee@mail.gmail.com><20080830120134.GA3741@matrix.chaos.earth.li><20080831121055.GA5326@soi.city.ac.uk><20080831121633.GA17919@matrix.chaos.earth.li> <48BE480C.5050308@gmail.com><2D93D24B65084422832AF68B82EF4106@cr3lt><48DA55C0.2090406@gmail.com><77766447D98E4243A6B4B87A3FC61A03@cr3lt> <48DA8568.90002@gmail.com><101F6137BA874BDDB349DFF07667A945@cr3lt><48DD00BA.5040302@gmail.com> <9F15806E5F3D4CF09FB497268B55E2D7@cr3lt> <48DD4B3B.3040504@gmail.com> <20080927012544.10225.qmail@schroeder.cas.mcmaster.ca> <48DE2B5A.5070605@gmail.com> Message-ID: <20080927200654.12316.qmail@schroeder.cas.mcmaster.ca> Simon Marlow wrote: > kahl@cas.mcmaster.ca wrote: > > Simon Marlow wrote: > > > > > We must have the property that the imports of a module do not affect > > > its API - and the only way to have this property is to avoid orphan > > > instances in library APIs. > > > > To be more precise, I would say that each orphan instance in a library API > > must be the only export of a dedicated visible module, > > and only exported by that module. > > > > > (The only importers of orphan instances are typically Main modules, > > or ``almost-Main'' modules.) > > Why do you believe that? Sorry, I was being idealistic. ;-) I mean: The only importers of orphan instances should typically be Main modules, or ``almost-Main'' modules. That does of course require conscious effort... And it also assumes that orphan instances are in dedicated modules, so they are imported only intentionally. (I would propose to never warn about orphan instances in modules that export only a single orphan instance.) > We seem to have evidence to the contrary, with > Control.Monad.Instances being imported by library modules. That's because at least some of its instances are not ``truly orphan'', but should, and reasonably can, be in scope whenever both type and class are in scope. (Yes, for Functor ((->) a) this means that Haskell98 is wrong.) A counterexample to that is a Read instance that pulls in a major dependency, for example Parsec --- that should not be automatically in scope wherever both type and class are in scope, but only where it is actually needed. Haskell software architecture can be quite tricky... Wolfram From duncan.coutts at worc.ox.ac.uk Sat Sep 27 17:09:01 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Sep 27 17:05:58 2008 Subject: Cabal 1.4.0.2 won't configure on Vista In-Reply-To: References: Message-ID: <1222549741.4242.40.camel@dell.linuxdev.us.dell.com> On Sat, 2008-09-27 at 11:46 -0700, Justin Bailey wrote: > As I posted in ticket #360 > (http://hackage.haskell.org/trac/hackage/ticket/360), the latest Cabal > on hackage won't configure on Vista. Using GHC 6.8.3, when I run the > "configure" command, I get this error: > > "During interactive linking, GHCi couldn't find the following symbol: > > SHGetFolderPathA@20 > Any ideas? The README file in the Cabal-1.4.0.2 tarball suggests: ghc --make Setup ./Setup configure --user ./Setup build ./Setup install The reason it imports SHGetFolderPath is to find the location of the Program Files directory. Unfortunately that is not provided by either System.Directory or anything in the Win32 binding package so we have to directly FFI import that ourselves. Unfortunately ghci does not know to link in the appropriate dll (and there's no automatic way for us to tell it) so Cabal will not work in ghci by default. You can either compile it (because gcc does link in the lib by default) or add something like -lshell32 when invoking ghci/runghc. If anyone would like to comment on this issue, please use ticket #325: http://hackage.haskell.org/trac/hackage/ticket/325 Duncan From marcot at riseup.net Sat Sep 27 19:01:02 2008 From: marcot at riseup.net (Marco =?ISO-8859-1?Q?T=FAlio?= Gontijo e Silva) Date: Sat Sep 27 18:58:02 2008 Subject: Some things about haskell-src In-Reply-To: <1222437869.9985.7.camel@quindinho.domain.invalid> References: <1222437869.9985.7.camel@quindinho.domain.invalid> Message-ID: <1222556462.22763.1.camel@quindinho.domain.invalid> Hello, Op vrijdag 26-09-2008 om 11:04 uur [tijdzone -0300], schreef Marco T?lio Gontijo e Silva: > I'm using haskell-src, and I noticed that the data types defined in > Language.Haskell.Syntax don't derive Ord. It makes sense, cause there's > no logical way to ordenate them, but it makes it impossible to use with > Data.Set functions, such as fromList. It would be good to be possible > to use Data.Set with these types, so maybe including deriving Ord to the > data types is a good idea. I've made a patch to haskell-src 1.0.1.2 that makes all types instance of Ord. Greetings. -- marcot P?gina: http://marcotmarcot.iaaeee.org/ Blog: http://marcotmarcot.blogspot.com/ Correio: marcot@riseup.net XMPP: marcot@jabber.org IRC: marcot@irc.freenode.net Telefone: 25151920 Celular: 98116720 Endere?o: Rua Turfa, 639/701 Prado 30410-370 Belo Horizonte/MG Brasil -------------- next part -------------- A non-text attachment was scrubbed... Name: ord.patch Type: text/x-patch Size: 7029 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20080927/a5fd3a25/ord-0001.bin From dons at galois.com Sun Sep 28 02:43:26 2008 From: dons at galois.com (Don Stewart) Date: Sun Sep 28 02:40:29 2008 Subject: Arch Haskell News: Sep 27 2008 Message-ID: <20080928064326.GC15485@scytale.galois.com> Highlights, * 590 Haskell packages now in Arch Linux, up 14 from last week. Noteworthy, * garsia-wachs :?A Functional Implementation of the Garsia-Wachs Algorithm * datapacker :?Tool to help pack files into the minimum number of CDs/DVDs/etc? * simple-sessions :?A simple implementation of session types? * QuickCheck 2 released * xml updated. Full details: http://archhaskell.wordpress.com/2008/09/28/arch-haskell-news-sep-27-2008/ For more information about Haskell on Arch Linux, see the wiki page, or join us online, on IRC, #arch-haskell @ freenode. From bart at cs.pdx.edu Sun Sep 28 03:49:07 2008 From: bart at cs.pdx.edu (Bart Massey) Date: Sun Sep 28 03:46:12 2008 Subject: Proposal #2629: Data.List: Replace nub; add nubOrd, nubInt, nubWith Message-ID: http://hackage.haskell.org/trac/ghc/ticket/2629 Everyone always complains about nub, but nobody ever does anything about it except (map head . group . sort), which isn't lazy and isn't always faster. :-) I've implemented a new function nubWith that takes a "stop list" as an argument and filters its target list against the stop list. I've then re-implemented nub and implemented nubOrd and nubInt in terms of nubWith: the stop list is a typeclass, so these implementations are trivial and new implementations are easily added. nubBy is left alone, since there's nothing obvious to be done about it. All of the nubs are still fully lazy. Basic QuickCheck tests are provided, and pass. Performance benchmarking code is provided. The performance of my nub implementation is quite comparable to that of the standard one. My nubOrd and nubInt implementations are dramatically faster, since they use a Set and IntSet respectively for the stop list. In particular, they are performant on long lists with long nubs, unlike the basic nub. My implementation is available via git at git://svcs.cs.pdx.edu/git/nub.git or can be browsed at http://svcs.cs.pdx.edu/gitweb?p=nub.git;a=tree and has a maybe-outdated tarball at http://svcs.cs.pdx.edu/haskell/nub.tar.gz The Nub.hs file itself is attached to the proposal. If the proposal is accepted, I will prepare a patch against current GHC library top-of-tree, but for now it seems easier for everyone to just look at the bits in their current natural habitat. From haskell at list.mightyreason.com Sun Sep 28 10:44:48 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Sun Sep 28 10:41:44 2008 Subject: Announce: Haskell protocol-buffers version 0.3.1 Message-ID: <48DF9860.2060606@list.mightyreason.com> And now it is much more complete. The 'hprotoc' compiler for proto files to Haskell source code now takes a "-u" command-line option. When given, this turns on code generation to support loading, storing, and saving unknown fields. The master source code archive has been broken up into the three corresponding Haskell packages: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/protocol-buffers http://hackage.haskell.org/cgi-bin/hackage-scripts/package/protocol-buffers-descriptor http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hprotoc The latest version is 0.3.1. They must be installed in the order given above (and all have been tested with the "cabal-install" command). In addition the new unknown field support, a few small bugs were fixed. In the future I will look at the new extensible proto file option and see how such support could be added to this Haskell project. Cheers, Chris From alexander.dunlap at gmail.com Sun Sep 28 14:05:42 2008 From: alexander.dunlap at gmail.com (Alexander Dunlap) Date: Sun Sep 28 14:02:33 2008 Subject: Proposal #2629: Data.List: Replace nub; add nubOrd, nubInt, nubWith In-Reply-To: References: Message-ID: <57526e770809281105if142137p8e5473b13d4ce71f@mail.gmail.com> On Sun, Sep 28, 2008 at 12:49 AM, Bart Massey wrote: > http://hackage.haskell.org/trac/ghc/ticket/2629 > > Everyone always complains about nub, but nobody ever does > anything about it except (map head . group . sort), which > isn't lazy and isn't always faster. :-) > > I've implemented a new function nubWith that takes a > "stop list" as an argument and filters its target list > against the stop list. I've then re-implemented nub and > implemented nubOrd and nubInt in terms of nubWith: the stop > list is a typeclass, so these implementations are trivial > and new implementations are easily added. nubBy is left > alone, since there's nothing obvious to be done about it. > All of the nubs are still fully lazy. > > Basic QuickCheck tests are provided, and pass. > > Performance benchmarking code is provided. The performance > of my nub implementation is quite comparable to that of > the standard one. My nubOrd and nubInt implementations > are dramatically faster, since they use a Set and IntSet > respectively for the stop list. In particular, they > are performant on long lists with long nubs, unlike the > basic nub. > > My implementation is available via git at > git://svcs.cs.pdx.edu/git/nub.git > or can be browsed at > http://svcs.cs.pdx.edu/gitweb?p=nub.git;a=tree > and has a maybe-outdated tarball at > http://svcs.cs.pdx.edu/haskell/nub.tar.gz > The Nub.hs file itself is attached to the proposal. > If the proposal is accepted, I will prepare a patch > against current GHC library top-of-tree, but for now it > seems easier for everyone to just look at the bits in > their current natural habitat. > > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > Hi all, This seems like a good idea but it's kind of strange to have three different exposed versions of nub. Would it be possible to hide them, hide the StopList typeclass and use {-# RULES #-} pragmas to use the faster versions when possible? Alex From kr.angelov at gmail.com Sun Sep 28 14:48:01 2008 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Sun Sep 28 14:44:51 2008 Subject: Proposal #2629: Data.List: Replace nub; add nubOrd, nubInt, nubWith In-Reply-To: <57526e770809281105if142137p8e5473b13d4ce71f@mail.gmail.com> References: <57526e770809281105if142137p8e5473b13d4ce71f@mail.gmail.com> Message-ID: I also think that it is better to use RULES and to hide at least nubInt. For nubOrd I am not sure whether it should be exported or hidden because it requires different type class. Isn't the usage of multi-parameter type class with functional dependencies and flexible instances an overkill for such a simple job? I would write nubWith in this way: nubWith :: (e -> s -> Maybe s) -> s -> [e] -> [e] nubWith _ _ [] = [] nubWith f s (e : es) case f e s of Just s -> e : nubWith f s es Nothing -> nubWith f s es It is portable and perhaps more flexible. With your type class you assume that it is efficient and possible to have separated memberS and insertS which might not be the case. If you have only one function then you leave the decision to the implementor. Regards, Krasimir On Sun, Sep 28, 2008 at 8:05 PM, Alexander Dunlap wrote: > On Sun, Sep 28, 2008 at 12:49 AM, Bart Massey wrote: >> http://hackage.haskell.org/trac/ghc/ticket/2629 >> >> Everyone always complains about nub, but nobody ever does >> anything about it except (map head . group . sort), which >> isn't lazy and isn't always faster. :-) >> >> I've implemented a new function nubWith that takes a >> "stop list" as an argument and filters its target list >> against the stop list. I've then re-implemented nub and >> implemented nubOrd and nubInt in terms of nubWith: the stop >> list is a typeclass, so these implementations are trivial >> and new implementations are easily added. nubBy is left >> alone, since there's nothing obvious to be done about it. >> All of the nubs are still fully lazy. >> >> Basic QuickCheck tests are provided, and pass. >> >> Performance benchmarking code is provided. The performance >> of my nub implementation is quite comparable to that of >> the standard one. My nubOrd and nubInt implementations >> are dramatically faster, since they use a Set and IntSet >> respectively for the stop list. In particular, they >> are performant on long lists with long nubs, unlike the >> basic nub. >> >> My implementation is available via git at >> git://svcs.cs.pdx.edu/git/nub.git >> or can be browsed at >> http://svcs.cs.pdx.edu/gitweb?p=nub.git;a=tree >> and has a maybe-outdated tarball at >> http://svcs.cs.pdx.edu/haskell/nub.tar.gz >> The Nub.hs file itself is attached to the proposal. >> If the proposal is accepted, I will prepare a patch >> against current GHC library top-of-tree, but for now it >> seems easier for everyone to just look at the bits in >> their current natural habitat. >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries@haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> > > Hi all, > > This seems like a good idea but it's kind of strange to have three > different exposed versions of nub. Would it be possible to hide them, > hide the StopList typeclass and use {-# RULES #-} pragmas to use the > faster versions when possible? > > Alex > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From jeremy at n-heptane.com Sun Sep 28 15:40:59 2008 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Sun Sep 28 15:31:09 2008 Subject: Proposal #2629: Data.List: Replace nub; add nubOrd, nubInt, nubWith In-Reply-To: <57526e770809281105if142137p8e5473b13d4ce71f@mail.gmail.com> References: <57526e770809281105if142137p8e5473b13d4ce71f@mail.gmail.com> Message-ID: <87hc80m52s.wl%jeremy@n-heptane.com> At Sun, 28 Sep 2008 11:05:42 -0700, Alexander Dunlap wrote: > This seems like a good idea but it's kind of strange to have three > different exposed versions of nub. Would it be possible to hide them, > hide the StopList typeclass and use {-# RULES #-} pragmas to use the > faster versions when possible? The RULES pragma is GHC-specific. Would it make sense to export the faster versions so that people targeting alternative compilers could use them? Additionally, I think RULES only take effect if you are compiling with optimizations, but not if you just load the files into GHCi. I have written programs which run fine with nubOrd but are unacceptable with nubEq. So, I would certainly want the option to force the use of nubOrd at all times, rather than rely on the compiler to sometimes make the required optimization for me. j. From isaacdupree at charter.net Sun Sep 28 17:09:57 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Sun Sep 28 17:06:55 2008 Subject: Proposal #2629: Data.List: Replace nub; add nubOrd, nubInt, nubWith In-Reply-To: <87hc80m52s.wl%jeremy@n-heptane.com> References: <57526e770809281105if142137p8e5473b13d4ce71f@mail.gmail.com> <87hc80m52s.wl%jeremy@n-heptane.com> Message-ID: <48DFF2A5.8080303@charter.net> Jeremy Shaw wrote: > Additionally, I think RULES only take effect if you are compiling with > optimizations, but not if you just load the files into GHCi. I have > written programs which run fine with nubOrd but are unacceptable with > nubEq. So, I would certainly want the option to force the use of > nubOrd at all times, rather than rely on the compiler to sometimes > make the required optimization for me. indeed! Could we provide a function named "nubEq" too, so that you can be explicit about only requiring (Eq) when needed, if you want to get rid of all the "deprecated" (word-ambiguous and aesthetically too enticingly short) uses of "nub". -Isaac From lemming at henning-thielemann.de Mon Sep 29 05:57:54 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Sep 29 05:54:44 2008 Subject: instance visibility In-Reply-To: <1222465287.4242.28.camel@dell.linuxdev.us.dell.com> References: <20080828111232.GA15998@matrix.chaos.earth.li> <404396ef0808280428j5f8ce984q904f5f0e2b0e61ee@mail.gmail.com> <20080830120134.GA3741@matrix.chaos.earth.li> <20080831121055.GA5326@soi.city.ac.uk> <20080831121633.GA17919@matrix.chaos.earth.li> <48BE480C.5050308@gmail.com> <2D93D24B65084422832AF68B82EF4106@cr3lt> <48DA55C0.2090406@gmail.com> <77766447D98E4243A6B4B87A3FC61A03@cr3lt> <48DA8568.90002@gmail.com> <101F6137BA874BDDB349DFF07667A945@cr3lt> <48DD00BA.5040302@gmail.com> <9F15806E5F3D4CF09FB497268B55E2D7@cr3lt> <48DD4B3B.3040504@gmail.com> <1222465287.4242.28.camel@dell.linuxdev.us.dell.com> Message-ID: On Fri, 26 Sep 2008, Duncan Coutts wrote: > On Fri, 2008-09-26 at 21:51 +0100, Simon Marlow wrote: > >> There are basically only two sensible choices for the Functor instance >> for (->): >> >> (a) don't define one at all >> (b) define one in Control.Monad, and give up on Haskell 98 compliance >> >> The current situation, namely >> >> (c) define it as an orphan, and give up on module abstraction >> >> is not a sensible choice. > > Right. > > No orphan instances in libraries. Me too. Although I'm afraid some of my packages still contain orphan instances. When I need a new instance to an existing class+type I ask the library author for that instance and in the meantime I use a 'newtype'. Frequently a newtype turns out to be better anyway. From apfelmus at quantentunnel.de Mon Sep 29 12:40:39 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Mon Sep 29 12:37:37 2008 Subject: Proposal #2629: Data.List: Replace nub; add nubOrd, nubInt, nubWith In-Reply-To: <57526e770809281105if142137p8e5473b13d4ce71f@mail.gmail.com> References: <57526e770809281105if142137p8e5473b13d4ce71f@mail.gmail.com> Message-ID: Alexander Dunlap wrote: > > This seems like a good idea but it's kind of strange to have three > different exposed versions of nub. Would it be possible to hide them, > hide the StopList typeclass and use {-# RULES #-} pragmas to use the > faster versions when possible? I don't think that using RULES pragmas is a good solution to the problem. Instead, there's an old-fashioned way to use the name nub for all cases: make it a member of the Eq typeclass! class Eq a where (==) :: a -> a -> Bool (/=) :: a -> a -> Bool nub :: [a] -> [a] nub = -- default definition Now, nub can be specialized at will. Changing the default definition of nub to use Set if we have an Ord class is tricky, though. Basically, we would need this proposal: http://www.haskell.org/haskellwiki/Class_system_extension_proposal#Allowing_superclass_methods_to_be_overridden_in_derived_classes Does it have a formal definition yet and guarantees that it works? In any case, consider nub to be another example for the usefulness of this proposal. Regards, apfelmus From alexander.dunlap at gmail.com Mon Sep 29 18:55:23 2008 From: alexander.dunlap at gmail.com (Alexander Dunlap) Date: Mon Sep 29 18:52:10 2008 Subject: Proposal #2629: Data.List: Replace nub; add nubOrd, nubInt, nubWith In-Reply-To: References: <57526e770809281105if142137p8e5473b13d4ce71f@mail.gmail.com> Message-ID: <57526e770809291555h73953b08p15aac52f2e48dc8f@mail.gmail.com> On Mon, Sep 29, 2008 at 9:40 AM, apfelmus wrote: > Alexander Dunlap wrote: >> >> This seems like a good idea but it's kind of strange to have three >> different exposed versions of nub. Would it be possible to hide them, >> hide the StopList typeclass and use {-# RULES #-} pragmas to use the >> faster versions when possible? > > I don't think that using RULES pragmas is a good solution to the problem. Why not? I thought that was the major purpose of RULES - to implement transformations that don't affect semantics. It seems silly to clutter up classes with extra functions just for efficiency or to have to change programs every time the types change. The fact that RULES don't work in GHCi is admittedly a downside; is there any plan to change that? Alex From allbery at ece.cmu.edu Mon Sep 29 19:06:41 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Sep 29 19:03:41 2008 Subject: Proposal #2629: Data.List: Replace nub; add nubOrd, nubInt, nubWith In-Reply-To: <57526e770809291555h73953b08p15aac52f2e48dc8f@mail.gmail.com> References: <57526e770809281105if142137p8e5473b13d4ce71f@mail.gmail.com> <57526e770809291555h73953b08p15aac52f2e48dc8f@mail.gmail.com> Message-ID: <8FE31656-4891-4333-97F9-35631D0E2AAD@ece.cmu.edu> On 2008 Sep 29, at 18:55, Alexander Dunlap wrote: > On Mon, Sep 29, 2008 at 9:40 AM, apfelmus > wrote: >> Alexander Dunlap wrote: >>> This seems like a good idea but it's kind of strange to have three >>> different exposed versions of nub. Would it be possible to hide >>> them, >>> hide the StopList typeclass and use {-# RULES #-} pragmas to use the >>> faster versions when possible? >> >> I don't think that using RULES pragmas is a good solution to the >> problem. > > Why not? I thought that was the major purpose of RULES - to implement > transformations that don't affect semantics. It seems silly to clutter So what of yhc, nhc98, jhc? ghc is not the be-all and end-all of Haskell. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From alexander.dunlap at gmail.com Mon Sep 29 19:40:20 2008 From: alexander.dunlap at gmail.com (Alexander Dunlap) Date: Mon Sep 29 19:37:09 2008 Subject: Proposal #2629: Data.List: Replace nub; add nubOrd, nubInt, nubWith In-Reply-To: <8FE31656-4891-4333-97F9-35631D0E2AAD@ece.cmu.edu> References: <57526e770809281105if142137p8e5473b13d4ce71f@mail.gmail.com> <57526e770809291555h73953b08p15aac52f2e48dc8f@mail.gmail.com> <8FE31656-4891-4333-97F9-35631D0E2AAD@ece.cmu.edu> Message-ID: <57526e770809291640h25321c8cgb2835bf01542049c@mail.gmail.com> On Mon, Sep 29, 2008 at 4:06 PM, Brandon S. Allbery KF8NH wrote: > On 2008 Sep 29, at 18:55, Alexander Dunlap wrote: >> >> On Mon, Sep 29, 2008 at 9:40 AM, apfelmus >> wrote: >>> >>> Alexander Dunlap wrote: >>>> >>>> This seems like a good idea but it's kind of strange to have three >>>> different exposed versions of nub. Would it be possible to hide them, >>>> hide the StopList typeclass and use {-# RULES #-} pragmas to use the >>>> faster versions when possible? >>> >>> I don't think that using RULES pragmas is a good solution to the problem. >> >> Why not? I thought that was the major purpose of RULES - to implement >> transformations that don't affect semantics. It seems silly to clutter > > So what of yhc, nhc98, jhc? ghc is not the be-all and end-all of Haskell. > Well, yes, but presumably different compilers could optimize in different ways. (Perhaps they could use some class behind the scenes, or their own optimizing mechanism?) My point is that we shouldn't have multiple exposed functions for _exactly_ the same semantic operation. Alex From allbery at ece.cmu.edu Mon Sep 29 19:53:14 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Sep 29 19:50:10 2008 Subject: Proposal #2629: Data.List: Replace nub; add nubOrd, nubInt, nubWith In-Reply-To: <57526e770809291640h25321c8cgb2835bf01542049c@mail.gmail.com> References: <57526e770809281105if142137p8e5473b13d4ce71f@mail.gmail.com> <57526e770809291555h73953b08p15aac52f2e48dc8f@mail.gmail.com> <8FE31656-4891-4333-97F9-35631D0E2AAD@ece.cmu.edu> <57526e770809291640h25321c8cgb2835bf01542049c@mail.gmail.com> Message-ID: <4F843739-FC0A-407D-BDBE-976A74F2E9FA@ece.cmu.edu> On 2008 Sep 29, at 19:40, Alexander Dunlap wrote: > On Mon, Sep 29, 2008 at 4:06 PM, Brandon S. Allbery KF8NH > wrote: >> On 2008 Sep 29, at 18:55, Alexander Dunlap wrote: >>> On Mon, Sep 29, 2008 at 9:40 AM, apfelmus >>> >>> wrote: >>>> Alexander Dunlap wrote: >>>>> >>>>> This seems like a good idea but it's kind of strange to have three >>>>> different exposed versions of nub. Would it be possible to hide >>>>> them, >>>>> hide the StopList typeclass and use {-# RULES #-} pragmas to use >>>>> the >>>>> faster versions when possible? >>>> >>>> I don't think that using RULES pragmas is a good solution to the >>>> problem. >>> >>> Why not? I thought that was the major purpose of RULES - to >>> implement >>> transformations that don't affect semantics. It seems silly to >>> clutter >> >> So what of yhc, nhc98, jhc? ghc is not the be-all and end-all of >> Haskell. > > Well, yes, but presumably different compilers could optimize in > different ways. (Perhaps they could use some class behind the scenes, > or their own optimizing mechanism?) My point is that we shouldn't have > multiple exposed functions for _exactly_ the same semantic operation. Tell it to the Prelude. (^), (^^), (**) anyone? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From bart at cs.pdx.edu Tue Sep 30 01:46:23 2008 From: bart at cs.pdx.edu (Bart Massey) Date: Tue Sep 30 01:43:23 2008 Subject: Proposal #2629: Data.List: Replace nub; add nubOrd, nubInt, nubWith References: Message-ID: Bart Massey cs.pdx.edu> writes: > http://hackage.haskell.org/trac/ghc/ticket/2629 > > Everyone always complains about nub, but nobody ever does > anything about it except (map head . group . sort), which > isn't lazy and isn't always faster. Just thought I'd post a note to thank you all for the informative and interesting discussion of my proposal so far. Thanks much to all who are helping to figure out what we should do! It looks to me like there's consensus on at least one point so far. If someone is really not agreeing with this, please post. (1) The StopList class is too "heavyweight" to naturally live in Data.List and should not be exported. Given this, the obvious choices are (a) to drop nubWith from the interface altogether, or (b) to replace it with a version that takes a stoplist function and value as an argument, as suggested by Krasimir Angelov earlier: nubWith :: (a -> b -> Maybe b) -> b -> [a] -> [a] I've implemented and benchmarked (b), and it seems to perform fine. You can get it from git://svcs.cs.pdx.edu/git/nub.git in the branch nubWith-function if you want to look for yourself. (Another possibility which hasn't been discussed is (c1) to include a new module with StopList and some related functions in it, and make Data.List depend on it, or (c2) to throw StopLists into some other existing base module such as Data.Function. Why Data.Function? Because the other thing I want them for is a later proposal to add transitiveClosure and reflexiveTransitiveClosure of functions to the libraries, and this is the natural place to put those.) Areas that still need discussion include: (2) It's probably reasonable to drop nubInt from the interface. It has roughly the same complexity as nubOrd, and thus should just be an optimization rule, since we want to avoid nubX for an arbitrarily long list X of typeclasses. (3) Since nubOrd has a dramatically different asymptotic time complexity than nub, enough so that many programs that need the former effectively won't work with the latter, we should expose nubOrd separately and not rely on optimizer magic to pick it. (At least I *hope* there's some consensus here, since I strongly agree with those who feel this way :-). Time and space usage are, in practical terms, that part of the semantics that distinguish a programming language from a mathematical notation. I'm a programmer.) Note, though, that one can easily imagine a nubAscii that is linear-time rather than the n log n time of nubOrd / nubInt, using a small bit vector to track the Chars. Certainly nubBool has this property. Hmm. What's our criterion for when the performance difference between two functions constitutes a practical semantic difference? I'm claiming it's asymptotic complexity class, in which case (a) we should probably figure out how to expose some kind of nubFinite. Or we could just take the position that in the vast universe of possible functions, our library cannot provide them all. In which case (1b) nubWith is back in. I guess I tend toward (1b). (4) Should (a) the StopList class and friends also be banned from the *implementation*? Or is it (b) OK to use them internally in the source code of Data.List? I'm actually more inclined toward (a), ironically. It makes for simpler and more portable code, and since we're not going to give the user the StopLists, we can avoid being so clever. (5) Isaac Dupree proposes nubEq as a synonym for nub, for use in cleaning up code. Is this a good idea? In particular, would we deprecate nub at this point? I'll roll a new proposal draft soon based on current and near future feedback. Again, thanks to all. Bart Massey bart cs.pdx.edu [Is there really an address miner anywhere in the world that's still really fooled by the above?] From dan.doel at gmail.com Tue Sep 30 02:20:12 2008 From: dan.doel at gmail.com (Dan Doel) Date: Tue Sep 30 02:09:49 2008 Subject: Proposal #2629: Data.List: Replace nub; add nubOrd, nubInt, nubWith In-Reply-To: References: Message-ID: <200809300220.13140.dan.doel@gmail.com> On Tuesday 30 September 2008 1:46:23 am Bart Massey wrote: > Just thought I'd post a note to thank you all for the informative and > interesting discussion of my proposal so far. Thanks much to all who are > helping to figure out what we should do! One additional issue: Data.List is in the base package. Data.Set is in containers. Data.Set also imports Data.List, so using sets in the latter creates a circular dependency. The latter isn't as big a deal, but circular package dependences sounds like a problem to me (as I imagine containers depends on base). Something else to discuss. :) -- Dan P.S.: On point 4, I'd probably lean away from StopList as well. Requiring fundeps seems undesirable for a rather core, H98-esque module. From waldmann at imn.htwk-leipzig.de Tue Sep 30 04:03:44 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Tue Sep 30 04:02:56 2008 Subject: Proposal #2629: Data.List: Replace nub; add nubOrd, nubInt, nubWith In-Reply-To: References: Message-ID: <48E1DD60.9060409@imn.htwk-leipzig.de> > The StopList class [...] BTW, that is a horrible name for what is simply a *set* (look at the methods you wrote: empty, insert, member) The design problem here is that you don't want to use Data.Set because currently it is an implementation, not an interface. J.W. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/libraries/attachments/20080930/74fad362/signature.bin From marlowsd at gmail.com Tue Sep 30 05:50:59 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Sep 30 05:47:52 2008 Subject: instance visibility In-Reply-To: <20080924190928.GR1961@darcs.net> 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> Message-ID: <48E1F683.7000702@gmail.com> David Roundy wrote: > On Wed, Sep 24, 2008 at 07:48:06PM +0100, Simon Marlow wrote: >> David Roundy wrote: >> >>> In the interest of providing a concrete example, see the darcs bug: >>> >>> http://bugs.darcs.net/issue387 >> Nice motivation for wanting to *not* import an instance. >> >> The first thing that occurs to me is to avoid using UserError - is that >> feasible? > > It's feasible, but extremely ugly, and it seems almost impossible to > audit the code for this, as we'd have to look at every instance of > fail to see if it might happen to be used in the IO monad. And, of > course, we'd have to write our own version of error. Either of these > sounds very tricky. fail is a great function (albeit much maligned), > and I'd hate to have to replace it throughout the code. > > Now, if we could avoid importing the Monad instance of IO from the > Prelude, then we could write our own instance that would have a fail > such as > > fail = throw . AssertionFailed I'd strongly urge you *not* to use error (or anything with value _|_) for reporting errors to the user. The reason being that GHC (or indeed Haskell) doesn't guarantee that your program will report the error message that you think it will - all it guarantees is that you'll get *some* error message. As GHC gets more clever, we're seeing more an more cases of this. If GHC can prove that your program has value _|_, then it is free to explore different orders of evaluation that also produce _|_ and pick one of them. See http://hackage.haskell.org/trac/ghc/ticket/1171 now GHC doesn't follow the imprecise exception semantics as described in the paper, but that is because the semantics in the paper isn't liberal enough (in our opinion). Of course it's fine to use error for things that are bugs in your program, and perhaps that's the way it's used in darcs. Cheers, Simon 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:23 2008 Subject: 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/libraries/attachments/20080930/bbc11239/attachment.htm From lemming at henning-thielemann.de Tue Sep 30 10:09:51 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Sep 30 10:06:36 2008 Subject: Proposal #2629: Data.List: Replace nub; add nubOrd, nubInt, nubWith In-Reply-To: <4F843739-FC0A-407D-BDBE-976A74F2E9FA@ece.cmu.edu> References: <57526e770809281105if142137p8e5473b13d4ce71f@mail.gmail.com> <57526e770809291555h73953b08p15aac52f2e48dc8f@mail.gmail.com> <8FE31656-4891-4333-97F9-35631D0E2AAD@ece.cmu.edu> <57526e770809291640h25321c8cgb2835bf01542049c@mail.gmail.com> <4F843739-FC0A-407D-BDBE-976A74F2E9FA@ece.cmu.edu> Message-ID: On Mon, 29 Sep 2008, Brandon S. Allbery KF8NH wrote: > On 2008 Sep 29, at 19:40, Alexander Dunlap wrote: >> >> Well, yes, but presumably different compilers could optimize in >> different ways. (Perhaps they could use some class behind the scenes, >> or their own optimizing mechanism?) My point is that we shouldn't have >> multiple exposed functions for _exactly_ the same semantic operation. > > Tell it to the Prelude. (^), (^^), (**) anyone? I don't see the relation between the different kind of powers and the different implementations of 'nub'. As far as I understand 'nubInt' is just an optimization of the generic 'nub'. In contrast to that, the three power operators denote really different operations: http://www.haskell.org/haskellwiki/Power_function I think it is reasonable to drop in an optimized 'nub' for certain types by an optimizer rule, just like it is legitimate to drop in a special GSL function for (GSLMatrix.map sin), or a determinant algorithm for Double matrices which uses division, whereas the generic determinant computation does not need divisions. From ross at soi.city.ac.uk Tue Sep 30 10:11:45 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Sep 30 10:08:33 2008 Subject: instance visibility In-Reply-To: <52f14b210809300652t6c79d354nf59ed0d7b8c651b4@mail.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> <52f14b210809300652t6c79d354nf59ed0d7b8c651b4@mail.gmail.com> Message-ID: <20080930141145.GA5529@soi.city.ac.uk> On Tue, Sep 30, 2008 at 03:52:37PM +0200, Jos? Pedro Magalh?es wrote: > 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. I would expect that the uncontested instances (except for the derived Complex instance) would be in the same module as the Data class. The container modules would thus bring these instances into scope, but would not import modules from the syb package, and thus not bring the dubious instances into scope. From marlowsd at gmail.com Tue Sep 30 10:33:10 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Sep 30 10:29:59 2008 Subject: instance visibility In-Reply-To: <52f14b210809300652t6c79d354nf59ed0d7b8c651b4@mail.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> <52f14b210809300652t6c79d354nf59ed0d7b8c651b4@mail.gmail.com> Message-ID: <48E238A6.2060302@gmail.com> Jos? Pedro Magalh?es wrote: > 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.) My suggestion would be that yes, Data.Generics.Instances should be folded into Data.Generics.Basics. If there are orphans to be moved to the syb package, then I think we ought to export the methods rather than defining instances, so that clients can define the instances themselves if they wish (although applications only, not libraries - a library would have to use a newtype). This also means you don't have to break the API later by removing the orphans. Cheers, Simon From bart at cs.pdx.edu Tue Sep 30 11:55:58 2008 From: bart at cs.pdx.edu (Bart Massey) Date: Tue Sep 30 11:53:00 2008 Subject: Proposal #2629: Data.List: Replace nub; add nubOrd, nubInt, nubWith References: <48E1DD60.9060409@imn.htwk-leipzig.de> Message-ID: Johannes Waldmann imn.htwk-leipzig.de> writes: > > The StopList class [...] > > BTW, that is a horrible name for what is simply a *set* > (look at the methods you wrote: empty, insert, member). I originally called the typeclass Set, but it isn't, so I changed it. It omits some Set functionality. One couldn't write an implementation of union or intersect with it, because there's no way to enumerate its elements. In any case, it's moot, because we're ditching StopLists. :-) > The design problem here is that you don't want to use Data.Set > because currently it is an implementation, not an interface. If by that you mean that it would be nice if Set was a typeclass, and there was a [] implementation as well as the current OrdSet implementation, I tend to agree. C'est la vie. From daveroundy at gmail.com Tue Sep 30 11:58:07 2008 From: daveroundy at gmail.com (David Roundy) Date: Tue Sep 30 11:54:51 2008 Subject: Proposal #2629: Data.List: Replace nub; add nubOrd, nubInt, nubWith In-Reply-To: References: Message-ID: <117f2cc80809300858o71f85ef3tdcde00d3c4859b17@mail.gmail.com> On Tue, Sep 30, 2008 at 1:46 AM, Bart Massey wrote: > Note, though, that one can easily imagine a nubAscii > that is linear-time rather than the n log n time of > nubOrd / nubInt, using a small bit vector to track the > Chars. Certainly nubBool has this property. Hmm. > What's our criterion for when the performance difference > between two functions constitutes a practical semantic > difference? I'm claiming it's asymptotic complexity > class, in which case (a) we should probably figure out how > to expose some kind of nubFinite. Or we could just take > the position that in the vast universe of possible > functions, our library cannot provide them all. In > which case (1b) nubWith is back in. I guess I tend > toward (1b). Actually, the asymptotic complexity (measured in terms of list length) of nubOrd is identical to the asymptotic complexity of nubAscii, nubBool or nubFinite. They differ by a constant factor of the log(# possible data values). David From bart at cs.pdx.edu Tue Sep 30 12:24:29 2008 From: bart at cs.pdx.edu (Bart Massey) Date: Tue Sep 30 12:21:23 2008 Subject: Proposal #2629: Data.List: Replace nub; add nubOrd, nubInt, nubWith References: <200809300220.13140.dan.doel@gmail.com> Message-ID: Dan Doel gmail.com> writes: > Data.List is in the base package. Data.Set is in containers. > > Data.Set also imports Data.List, so using sets in the latter creates a > circular dependency. Oh. Ow. My bad for not doing a proper patch in the first place, which would have exposed the problem before it got this far. My apologies. Thanks much for the catch. You said that the circular module dependency is "not as big a deal"? I'm not getting why...it seems pretty serious to me. Is there some refactoring that makes it go away without doing huge violence to the existing structure? I mean, we could split the Data.List module up into pieces to break the dependency, but that doesn't seem like it's going to happen... I'd completely forgotten about the recent package split of containers and base. No idea what to do there. I suppose at worst we could have a Data.Nubs module, but that just seems silly, as all it's going to export at this point is nubOrd and (StopList-less) nubWith. Besides, what package do we put it in? Do we now have container, base, and nubs?? :-) :-) (In general, it seems like this sort of thing is going to become a problem as the libraries grow. I note, for example, that Data.Function is in base, which makes putting any reasonable implementation of transitiveClosure in there pretty hard for this same reason.) Any suggestions from anyone about how to proceed? Or are we just done at this point? So close... Bart Massey bart cs.pdx.edu From dan.doel at gmail.com Tue Sep 30 12:53:25 2008 From: dan.doel at gmail.com (Dan Doel) Date: Tue Sep 30 12:43:39 2008 Subject: Proposal #2629: Data.List: Replace nub; add nubOrd, nubInt, nubWith In-Reply-To: References: <200809300220.13140.dan.doel@gmail.com> Message-ID: <200809301253.25968.dan.doel@gmail.com> On Tuesday 30 September 2008 12:24:29 pm Bart Massey wrote: > You said that the circular module dependency is "not as big a deal"? I'm > not getting why...it seems pretty serious to me. Is there some refactoring > that makes it go away without doing huge violence to the existing > structure? I mean, we could split the Data.List module up into pieces to > break the dependency, but that doesn't seem like it's going to happen... Well, in GHC, at least, there are ways to handle mutually recursive modules. I've never encountered the need myself, so I don't know the specifics, but it involves making an hs-boot file or something of the sort. Of course, that only works if they're in the same package, I suspect, so maybe it is a big problem. :) I don't know how any other compilers handle such things. > I'd completely forgotten about the recent package split of containers and > base. No idea what to do there. I suppose at worst we could have a > Data.Nubs module, but that just seems silly, as all it's going to export at > this point is nubOrd and (StopList-less) nubWith. Besides, what package do > we put it in? Do we now have container, base, and nubs?? :-) :-) > > (In general, it seems like this sort of thing is going to become a problem > as the libraries grow. I note, for example, that Data.Function is in base, > which makes putting any reasonable implementation of transitiveClosure in > there pretty hard for this same reason.) > > Any suggestions from anyone about how to proceed? Or are we just done at > this point? So close... Lists are a container, so I guess it'd be nice if Data.List could be moved to containers, but I think the prelude imports and uses stuff from it, and you're not going to move that. nubOrd could be stuck in Data.Set, but that's kind of an odd place for it. Other than that, I'm stumped. -- Dan From droundy at darcs.net Tue Sep 30 12:55:34 2008 From: droundy at darcs.net (David Roundy) Date: Tue Sep 30 12:51:49 2008 Subject: Proposal #2629: Data.List: Replace nub; add nubOrd, nubInt, nubWith In-Reply-To: <117f2cc80809300858o71f85ef3tdcde00d3c4859b17@mail.gmail.com> References: <117f2cc80809300858o71f85ef3tdcde00d3c4859b17@mail.gmail.com> Message-ID: <20080930165533.GN25053@darcs.net> On Tue, Sep 30, 2008 at 11:58:07AM -0400, David Roundy wrote: > On Tue, Sep 30, 2008 at 1:46 AM, Bart Massey wrote: > > Note, though, that one can easily imagine a nubAscii > > that is linear-time rather than the n log n time of > > nubOrd / nubInt, using a small bit vector to track the > > Chars. Certainly nubBool has this property. Hmm. > > What's our criterion for when the performance difference > > between two functions constitutes a practical semantic > > difference? I'm claiming it's asymptotic complexity > > class, in which case (a) we should probably figure out how > > to expose some kind of nubFinite. Or we could just take > > the position that in the vast universe of possible > > functions, our library cannot provide them all. In > > which case (1b) nubWith is back in. I guess I tend > > toward (1b). > > Actually, the asymptotic complexity (measured in terms of list length) > of nubOrd is identical to the asymptotic complexity of nubAscii, > nubBool or nubFinite. They differ by a constant factor of the log(# > possible data values). Incidentally, for data types with finite value ranges, nub itself isn't bad, as it'd just O(n * # of values present). So, for instance, nub on a list of Bool is likely to be faster than nubOrd on a list of bools, and it's certainly O(n)... I just ran a timing, and nub takes about as long as length does. David From alfonso.acosta at gmail.com Tue Sep 30 12:59:00 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Tue Sep 30 12:55:51 2008 Subject: HackageDB bug in exposed modules Message-ID: <6a7c66fc0809300959p6566517dm93bcc46430f5791@mail.gmail.com> Hi, I just uploaded a library to hackagedb: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ForSyDe Everything went smoothly, but the webpage shows certain hidden modules (other-modules section in the cabal description) as exposed. Am I missing something or is this a bug in HackageDB? Best regards, Alfonso Acosta From duncan.coutts at worc.ox.ac.uk Tue Sep 30 13:18:57 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Sep 30 13:15:43 2008 Subject: HackageDB bug in exposed modules In-Reply-To: <6a7c66fc0809300959p6566517dm93bcc46430f5791@mail.gmail.com> References: <6a7c66fc0809300959p6566517dm93bcc46430f5791@mail.gmail.com> Message-ID: <1222795137.14163.203.camel@dell.linuxdev.us.dell.com> On Tue, 2008-09-30 at 18:59 +0200, Alfonso Acosta wrote: > Hi, > > I just uploaded a library to hackagedb: > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ForSyDe > > Everything went smoothly, but the webpage shows certain hidden modules > (other-modules section in the cabal description) as exposed. > > Am I missing something or is this a bug in HackageDB? I think I must be missing something. Looking at the page currently and comparing it to the .cabal file, the page lists only the exposed modules and not the other modules. BTW, you may be pleased to know that the latest version of Cabal lets you use (a restricted form of) wildcards in the extra-source-files field. Duncan From alfonso.acosta at gmail.com Tue Sep 30 13:39:47 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Tue Sep 30 13:36:31 2008 Subject: HackageDB bug in exposed modules In-Reply-To: <1222795137.14163.203.camel@dell.linuxdev.us.dell.com> References: <6a7c66fc0809300959p6566517dm93bcc46430f5791@mail.gmail.com> <1222795137.14163.203.camel@dell.linuxdev.us.dell.com> Message-ID: <6a7c66fc0809301039o792e280egf841b3d406586fa5@mail.gmail.com> On Tue, Sep 30, 2008 at 7:18 PM, Duncan Coutts wrote: > I think I must be missing something. Looking at the page currently and > comparing it to the .cabal file, the page lists only the exposed modules > and not the other modules. My bad, I was the one missing something, sorry for the noise. Everything makes sense now, the bug was just in my head. > > BTW, you may be pleased to know that the latest version of Cabal lets > you use (a restricted form of) wildcards in the extra-source-files > field. Great! When will we see a doc-files category? From alfonso.acosta at gmail.com Tue Sep 30 13:45:42 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Tue Sep 30 13:42:25 2008 Subject: HackageDB bug in exposed modules In-Reply-To: <6a7c66fc0809301039o792e280egf841b3d406586fa5@mail.gmail.com> References: <6a7c66fc0809300959p6566517dm93bcc46430f5791@mail.gmail.com> <1222795137.14163.203.camel@dell.linuxdev.us.dell.com> <6a7c66fc0809301039o792e280egf841b3d406586fa5@mail.gmail.com> Message-ID: <6a7c66fc0809301045r31ac06efq604ff84ea9909e01@mail.gmail.com> BTW, can someone tell me how long does HackageDB normally take to compile the uploaded packages and generate the haddock documentation? On Tue, Sep 30, 2008 at 7:39 PM, Alfonso Acosta wrote: > On Tue, Sep 30, 2008 at 7:18 PM, Duncan Coutts > wrote: >> I think I must be missing something. Looking at the page currently and >> comparing it to the .cabal file, the page lists only the exposed modules >> and not the other modules. > > My bad, I was the one missing something, sorry for the noise. > > Everything makes sense now, the bug was just in my head. > >> >> BTW, you may be pleased to know that the latest version of Cabal lets >> you use (a restricted form of) wildcards in the extra-source-files >> field. > > Great! When will we see a doc-files category? > From lemming at henning-thielemann.de Tue Sep 30 14:54:19 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Sep 30 14:51:03 2008 Subject: Proposal #2629: Data.List: Replace nub; add nubOrd, nubInt, nubWith In-Reply-To: <200809301253.25968.dan.doel@gmail.com> References: <200809300220.13140.dan.doel@gmail.com> <200809301253.25968.dan.doel@gmail.com> Message-ID: On Tue, 30 Sep 2008, Dan Doel wrote: > Lists are a container, so I guess it'd be nice if Data.List could be moved to > containers, but I think the prelude imports and uses stuff from it, and you're > not going to move that. > > nubOrd could be stuck in Data.Set, but that's kind of an odd place for it. Data.List could import list functions from Prelude and re-export them. From duncan.coutts at worc.ox.ac.uk Tue Sep 30 14:39:32 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Oct 1 01:57:10 2008 Subject: HackageDB bug in exposed modules In-Reply-To: <6a7c66fc0809301039o792e280egf841b3d406586fa5@mail.gmail.com> References: <6a7c66fc0809300959p6566517dm93bcc46430f5791@mail.gmail.com> <1222795137.14163.203.camel@dell.linuxdev.us.dell.com> <6a7c66fc0809301039o792e280egf841b3d406586fa5@mail.gmail.com> Message-ID: <1222799972.14163.208.camel@dell.linuxdev.us.dell.com> On Tue, 2008-09-30 at 19:39 +0200, Alfonso Acosta wrote: > > BTW, you may be pleased to know that the latest version of Cabal lets > > you use (a restricted form of) wildcards in the extra-source-files > > field. > > Great! When will we see a doc-files category? When people can agree on some conventions on how to build various formats of documentation. We have all these easy conventions for source code; we pretty much know how to build a .hs file without needing custom build rules for every package. For documentation however there is much less consensus or common convention. What do I do with a .xml file? Is it xhtml, or do I need to do something obscure with docbook? This would be an excellent area for someone to take charge, look at the current common uses and see if there is a way of making the common simple stuff easy. Duncan From duncan.coutts at worc.ox.ac.uk Tue Sep 30 14:40:30 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Oct 1 01:57:15 2008 Subject: HackageDB bug in exposed modules In-Reply-To: <6a7c66fc0809301045r31ac06efq604ff84ea9909e01@mail.gmail.com> References: <6a7c66fc0809300959p6566517dm93bcc46430f5791@mail.gmail.com> <1222795137.14163.203.camel@dell.linuxdev.us.dell.com> <6a7c66fc0809301039o792e280egf841b3d406586fa5@mail.gmail.com> <6a7c66fc0809301045r31ac06efq604ff84ea9909e01@mail.gmail.com> Message-ID: <1222800030.14163.210.camel@dell.linuxdev.us.dell.com> On Tue, 2008-09-30 at 19:45 +0200, Alfonso Acosta wrote: > BTW, can someone tell me how long does HackageDB normally take to > compile the uploaded packages and generate the haddock documentation? It's normally on the order of a few hours. I'm afraid I do not know exactly. Duncan