- Libraries - Haskell.org

RE: System.Locale is broken?
by Simon Marlow 13 Apr '04

13 Apr '04

> System.Locale.defaultTimeLocale, which appears to be taken > directly from > the Haskell report, is hard-coded to american english > settings... which > seems to defeat the purpose of the module. Are there plans > to provide the actual locale? > > I have users who would like to have their times formatted according to > their own locale. I'd rather not have to do this using the > FFI to access the C library. :( We can't change Locale.defaultTimeLocale, because the Haskell 98 report specifies it. OTOH, I agree that it should do something reasonable. We can change System.Locale.defaultTimeLocale to be locale-specific: if you have some code, I'll incorporate it (assuming there are no objections). Cheers, Simon

2 1

RE: Compiler Versions
by Simon Marlow 13 Apr '04

13 Apr '04

> Simon Marlow wrote (snipped): > > I agree it's not worth arguing, it's more important to > decide whether we can implement Read Version. > > Why is the Read instance for Version so important? I don't really see > one using it much. The only occasion I can imagine when you > would actually > want to create a Version value for GHC is when you send a new > release out the door. > > I don't really the instance of Ord being that important > either. What one > wants to know is whether > (1) version X was released later than some given date; > (2) version X is lexicographically subsequent to [sequence of > integers] > (so GHC 6.02.1 comes after GHC 4.08.1); > (3) version X is a subversion of [sequence of integers], as > 6.2.1 is a subversion of 6.2; > (4) version X has a tag attached meaning "DANGER. Do not use > unless your > name is Simon". I see - I assumed you were planning to have Ord and Read instances for Version and compare versions by doing if ghc_version => read "6.2" then ... but you'd do it like this: if branch ghc_version >= [6,2] then ... which is fine. In fact, I think I like yours better :-) I'm not convinced of the need to have a date attached to all versions, though. Under what circumstances do you imagine needing (1) above, where (2) won't do? Cheers, Simon

2 1

RE: Compiler Versions
by Simon Marlow 13 Apr '04

13 Apr '04

> > type Branch = [Int] > > data Version = Release Branch | Snapshot Branch ClockTime > > This seems to me far too dependent on GHC. I see it more as a CVS-like versioning scheme than a GHC-like scheme. It follows a pattern that many projects are using these days. > I suggest that abstract or > not, each Version value contains the following information: > The format of "tags" should > be entirely up to the vendor > branch :: [Int] > date :: ClockTime > tags :: [String] > > Other information should be included as well of course, but is not > relevant to this discussion. > > Information about whether something is (in GHC-speak) a "release" or > a "snapshot" should properly be in (tags). But other people > should not > be obliged to use the GHC distinction between "release" and > "snapshot". The difficulty with this is how to construct a value of type Version. In your scheme, I need to know the release date for each version, or the library needs to have an appropriate mapping so that it can implement the Read instance for Version. This is why I left out the date from released versions in my scheme - but the disadvantage is that some versions become imcomparable. eg. I can't prove that a snapshot along the 6.2 branch is later or earlier than a particular release along that branch, but it is definitely later than 6.1.x and earlier than 6.3.x. I think this is reasonable. > There are two natural orderings, namely by branch and by > clocktime, but > there's not really a lot you can do about that. It is > entirely plausible > version 6.2.2 of something should have a release date after 6.4. > (If, for example, a number of Luddites have still to convert > to 6.4, but > need a bug fixed.) My vote would be for making Ord compare date first > (since that is a linear value), then branch, and then tags, but I can > see that other people may have different equally valid > opinions. In any > case there's not a whole lot of point arguing about it. Since versions are tree-shaped, it's going to be impossible to find an appropriate Ord instance that does the right thing all the time. Arguably it should be a partial ordering where only versions along the same branch of the tree are comparable, but in practice I need to compare versions like 4.08.2 and 6.2.1 and come up with the result LT, but knowing that I can do this depends on GHC's development strategy. I agree it's not worth arguing, it's more important to decide whether we can implement Read Version. > The fact that GHC refers to a snapshot of 6.2 on 13th April 2004 as > "6.2.20040413" is a vile hack which this discussion should certainly > ignore! Well, I didn't actually specify a concrete syntax for my Version type. Cheers, Simon

2 1

RE: Compiler versions
by Simon Marlow 13 Apr '04

13 Apr '04

> > > I prefer George's idea of an abstract version type which is > > > an instance of Show, Read and Ord. I'd probably also add > majorVersion and > > > minorVersion functions, which could return perhaps the > same abstract type. > > Sounds good to me. > > > Using an abstract version type seems to be the best choice for the > > reasons you give. However, there's a compromise here: > > > > - If you have an abstract version type for the version of > > entity X, then you need one version type for each X, because > > they have different versioning policies. (e.g. we can't > > use the same version type for the version of the > Haskell language > > and the version of the compiler, or versions of libraries). > > Can't we solve that problem with classes? > > class (Show a, Read a, Ord a) => Version a where > version :: a > majorVersion :: a -> a > minorVersion :: a -> a > > Each entity (language, compiler, library) can indeed define its own > versioning type and policy, with this abstract interface. It just > needs to publish the name of the concrete type that implements it. There isn't really a "problem" here, just that having lots of different version types might be unnecessary. I'm not sure that having a unified majorVersion/minorVersion interface buys very much - it implies a kind of binary tree structure to versions, but then I have to say how that is overlaid on the actual structure of each version type, and what it means to compose majorVersion/minorVersion. What would you use 'version' for, BTW? For packages at least, we have to pick a single versioning policy for all packages so that the library infrastructure can manage dependencies without having to know a separate versioning policy for each individual package. Ok, well it's not that big a deal. I guess we could have module System.Info -- or something data ImplementationVersion -- instacne Eq, Ord, Read, Show implementationVersion :: ImplementationVersion data HaskellVersion -- instance Eq, Ord, Read, Show haskellVersion :: HaskellVersion haskellExtensions :: [Extension] and then have a separate PackageVersion type for packages. I'll probably re-use the PackageVersion type for GHC's version. Cheers, Simon

1 0

Re: Compiler Versions
by George Russell 13 Apr '04

13 Apr '04

Simon Marlow wrote (snipped): > I like the idea of representing a version as [Int], using > lexicographic ordering; like CVS versions, this lets you branch the tree > as much as you like by adding an extra component. > > However, this presents a small problem for GHC versions, where eg. > 6.2.2004025 is supposed to be earlier than 6.2.1. So perhaps we should > elaborate the type: > > type Branch = [Int] > data Version = Release Branch | Snapshot Branch ClockTime This seems to me far too dependent on GHC. I suggest that abstract or not, each Version value contains the following information: The format of "tags" should be entirely up to the vendor branch :: [Int] date :: ClockTime tags :: [String] Other information should be included as well of course, but is not relevant to this discussion. Information about whether something is (in GHC-speak) a "release" or a "snapshot" should properly be in (tags). But other people should not be obliged to use the GHC distinction between "release" and "snapshot". There are two natural orderings, namely by branch and by clocktime, but there's not really a lot you can do about that. It is entirely plausible version 6.2.2 of something should have a release date after 6.4. (If, for example, a number of Luddites have still to convert to 6.4, but need a bug fixed.) My vote would be for making Ord compare date first (since that is a linear value), then branch, and then tags, but I can see that other people may have different equally valid opinions. In any case there's not a whole lot of point arguing about it. The fact that GHC refers to a snapshot of 6.2 on 13th April 2004 as "6.2.20040413" is a vile hack which this discussion should certainly ignore!

1 0

Seq instances
by Wolfgang Jeltsch 13 Apr '04

13 Apr '04

Hi, why are the following instances missing? instance Ord a => Ord (DData.Seq.Seq a) instance Monad DData.Seq.Seq Wolfgang

2 1

RE: Compiler versions
by Simon Marlow 13 Apr '04

13 Apr '04

David Roundy writes: > With the scheme of a triple of Ints, you could have problems > with versions > like 6.2.1pre1 or 6.2.1rc1 which can't easily be mapped to a triple of > Ints. > > I prefer George's idea of an abstract version type which is > an instance of > Show, Read and Ord. I'd probably also add majorVersion and > minorVersion > functions, which could return perhaps the same abstract type. > This could > also be extended to allow the versions of CVS checkouts to be dealt > with--they could have version numbers like 6.2.1cvs20040402 > or something. > Most importantly, though, you wouldn't be defining a version numbering > policy in the interface. Using an abstract version type seems to be the best choice for the reasons you give. However, there's a compromise here: - If you have an abstract version type for the version of entity X, then you need one version type for each X, because they have different versioning policies. (e.g. we can't use the same version type for the version of the Haskell language and the version of the compiler, or versions of libraries). - The alternative is to impose a policy. Perhaps the best choice is to pick a policy that is as unrestrictive as possible. I like the idea of representing a version as [Int], using lexicographic ordering; like CVS versions, this lets you branch the tree as much as you like by adding an extra component. However, this presents a small problem for GHC versions, where eg. 6.2.2004025 is supposed to be earlier than 6.2.1. So perhaps we should elaborate the type: type Branch = [Int] data Version = Release Branch | Snapshot Branch ClockTime I'm aware that Hugs versions don't fit well with this type, but there has been some discussion recently about changing the Hugs versioning scheme. The Haskell language versions just about fit into this type (98 > 1.3). One possible extension is to allow branches to be named, as long as there was an appropriate way to determine ordering (e.g. an Int associated with each branch name behind the scenes). Cheers, Simon

2 1

RE: Text.PrettyPrint mixes tabs and spaces??
by Simon Marlow 13 Apr '04

13 Apr '04

> >From Text.PrettyPrint.HughesPJ: > > indent n | n >= 8 = '\t' : indent (n - 8) > | otherwise = spaces n > > I consider it seriously evil to mix tabs and spaces for indentation. > *Seriously* evil. Kill-on-sight evil. > > Not to mention that LaTeX's \verbatiminput does not handle tabs, which > makes the result look like, well, crap. > > If there are people who want to mix tabs and spaces, fine, > but at least give me a flag that turns it off. Please? He's right; tabs aren't necessarily every 8 columns everywhere, so the generic pretty printing library shouldn't make this assumption. I'll remove it, unless there are any objections. Cheers, Simon

1 0

RE: Heirarchical name space allocation
by Simon Marlow 13 Apr '04

13 Apr '04

> That's no contradiction to my rule, e.g. > Graphics.Rendering.OpenGL is about > *all* OpenGL stuff, while Graphics.Rendering.OpenGL.GL is about GL and > Graphics.Rendering.OpenGL.GLU is about GLU. > > Perhaps I should explain a little bit more what IMHO is a > "good use" of the > hierarchical structure: > > * "collector" modules: These are a necessity for larger > APIs, otherwise you > can easily have dozens of closely related imports. Nobody > argued against > this use, IIRC, and we already have a lot of examples of it. > > * "selector" modules: There are different implementations > Foo.A and Foo.B of > basically the same API, but it's not clear (yet) which > one is better. So > Foo simply re-exports one of Foo.A and Foo.B as the > default for people who > don't care, but there is still the possibility of using a > specific one. > Text.PrettyPrint is an example of this use, although > there's currently only > one specific implementation. Another example is > Data.STRef, Data.STRef.Lazy, > and Data.STRef.Strict, but the imports are a bit > "upside-down" here, something > we should probably change. > > * A collection of only loosely related modules Foo.A, > Foo.B, ...: Having a > module Foo wouldn't make much sense in this case. A good > example for this > is the Data hierarchy. There is a rough policy, which pretty much repeats what Sven says above, here: http://www.haskell.org/hierarchical-modules/libraries/layout.html This is part of the document in fptools/libraries/doc/libraries.sgml, BTW. Some bits of it are out of date. Perhaps I should separate out the design guidelines into a separate document. Cheers, Simon

1 0

RE: DData
by Simon Marlow 13 Apr '04

13 Apr '04

> hello, > irrespective of if DData is "the" data structure library > (whatever that > means), > or simply another library, could we avoid adding it to the > base package? > it would be much nicer, if the base package was split into > more components. > > and it would also be nice if i can go and download DData on its own, > whenever there are bugfixes, > or improvements, without needing to download GHC with it. > i don't see any reason why DData should be part of "base". A rough criteria for what should be in 'base' is: everything required by Prelude. I say only a rough criteria, because there are currently plenty of libraries in base that aren't required by the Prelude, but are there because splitting them off into a separate package would be overkill. (Also at one stage I was using a different criteria: everything required to bootstrap GHC). Cheers, Simon

1 0