- Libraries - Haskell.org

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

Re: Compiler versions
by Jon Cast 07 Apr '04

07 Apr '04

Malcolm Wallace <Malcolm.Wallace(a)cs.york.ac.uk> wrote: <snip> > I remember Mark Jones suggesting more-or-less exactly this idea back > in about 1998/1999. It has been implemented in nhc98 ever since, but > I finally deleted it from CVS recently because no other systems > supported it. And (probably the more major reason) because I > frequently forgot to keep it up to date. Here was the signature: > > module Haskell where > > import Time > import Locale > > systemName :: String -- "Hugs", "GHC", "hbc", "nhc", "qhc", .. > . > haskellVersion :: Int -- 13, 14, 98, 2000, ... ^^^^^^^^^^^^^^^^^^^^^ I wholeheartedly endorse this, but these days I think (Version, [String]) would be a better type, i.e., (haskell98, ["Standard FFI", "Multi-parameter type classes", "Functional Dependencies", ...]. Knowing the Haskell version number by itself won't be much good until the Haskell 2.0 standard, but knowing which extensions are present (independent of the compiler version) would be a very good thing (listing syntactic extensions isn't an entirely useless thing; I'm sure it would make Autoconf's job easier). > releaseDate :: CalendarTime -- ... > version :: String -- some combination of the above <snip> Jon Cast

2 1

RE: Ord instance for TypeRep?
by Simon Peyton-Jones 07 Apr '04

07 Apr '04

It's not as simple as it sounds. The difficulty is this: Is typeOf (x::Int) > type (y::Bool) If the semantics of the language is well defined, there should be an answer, otherwise you could write programs in which different Haskell implementations give different answers. We could legislate lexicographic comparison based on the type constructor names, but that's not very efficient and I'd rather not tie the hands of the implementation. This is an old chestnut that I really don't know a good solution too. A not very good solution is this: if the reason for comparison is for maps, provide maps data TypeRepMap a empty :: TypeRepMap a insert :: TypeRepMap a -> TypeRep -> a -> TypeRepMap a etc But it's not very satisfactory because it adds a big new interface to TypeRep. Better ideas would be welcome. Simon | -----Original Message----- | From: libraries-bounces(a)haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Dylan | Thurston | Sent: 06 April 2004 21:12 | To: libraries(a)haskell.org | Subject: Ord instance for TypeRep? | | I'm not sure this is the right place to make this request, but could | an instance of 'Ord TypeRep' please be added? I'd like to store | dynamically typed elements in a FiniteMap. | | Peace, | Dylan

2 1

Re: [Haskell] ANNOUNCE: Haskell XML Toolbox Version 4.00
by Graham Klyne 07 Apr '04

07 Apr '04

At 11:37 06/04/04 +0200, Uwe Schmidt wrote: >Haskell XML Toolbox 4.00 > >I would like to announce a new version of the Haskell XML Toolbox for >processing XML including a validating parser and a new XPath module. Testing the new kit using Hugs under Windows, with test program Examples/HUnit/HUnitExample.hs. Because I'm starting from a clean distribution, I'm hoping that this will show up all of the Windows/Hugs incompatibilities that I may have missed reporting previously. This message is constructed in a stream-of-consciousness style, as I wanted to capture every step I took to get the code running. (I *did* get the code running with Hugs under Windows, with just a little butchery ;-) My first step was to unpack the distribution kit into a directory: D:\Cvs\DEV\HaskellUtils\HXmlToolbox-4.00 I then created a batch file to run Hugs from the Examples directory: [[ rem Use Hugs version compiled with Unicode support set HUGS=C:\DEV\Hugs98\hugs-20040109.exe set LIBS=..\hdom;..\hparser;..\hvalidator;..\hxpath;..\http;..\popen %HUGS% -P"%LIBS%;" PAUSE ]] (I should check if the HXML Toolbox requires Haskell support for 'char's with codepoints >255. Later.) ... [[ Reading file "..\http\HTTP.hs": Parsing ERROR "..\http\HTTP.hs":132 - Syntax error in import declaration (unexpected symbol "partition") Network.Socket> ]] import Data.List ({- isPrefixOf -},partition,elemIndex) -- uwe changed to: import Data.List ({- isPrefixOf, -} partition,elemIndex) -- uwe ... I experienced a problem with http.hs, because my version of Network.URI has a different internal structure. It's not clear to me why there's a need to force a '/' at the front of the path (i.e. if a relative path is supplied here, isn't it an error in any case?): [[ alt_uri = show $ if null (path u) || head (path u) /= '/' then u { uriPath = '/' : path u } else u ]] (this is modified to use uriPath, so it works with my Network.URI) In the longer run, I'm hoping that the HTTP module will become part of the Network library module, based on work by Bjorn Bringert. ... [[ Reading file "..\http\Browser.hs": Parsing ERROR "..\http\Browser.hs":70 - Syntax error in import declaration (unexpected comma) HTTP> ]] import Control.Monad (foldM,filterM, {- liftMf -},when) changed to: import Control.Monad (foldM,filterM, {- liftMf, -} when) ... I also had a problem with functions trimHost and formToRequest in Browser.hs and my URI module, similar to that noted above. Again, I hope this problem can be avoided when http is part of the common library. ... [[ Reading file "..\hparser\ProtocolHandlerHttpCurl.hs": Parsing ERROR "..\hparser\ProtocolHandlerHttpCurl.hs" - Can't find imported module "Posix" ProtocolHandlerHttpNative> ]] This is the old well-known POpen problem. I've copied my version of POpen into the HXMLtoolbox code tree (it compiles, but still doesn't work), and changed the import Posix(popen) to import POPen(popen). ... With the above changes, the code runs but reports 8 failures: [[ Cases: 110 Tried: 110 Errors: 0 Failures: 8 Counts{cases=110,tried=110,errors=0,failures=8} ]] Failures are: [[ fatal error: illegal URI for input: "mini1.xml" : ### Failure in: 3:input tests:3 expected: "<x/>" but got: "" Cases: 110 Tried: 36 Errors: 0 Failures: 1 fatal error: illegal URI for input: "mini1.xml" ### Failure in: 3:input tests:4 expected: "0" but got: "3" Cases: 110 Tried: 37 Errors: 0 Failures: 2 fatal error: illegal URI for input: "mini1.xml" : ### Failure in: 3:input tests:5 expected: "4" but got: "0" Cases: 110 Tried: 38 Errors: 0 Failures: 3 fatal error: illegal URI for input: "mini2.xml" ### Failure in: 3:input tests:6 expected: "0" but got: "3" Cases: 110 Tried: 39 Errors: 0 Failures: 4 fatal error: illegal URI for input: "notThere.xml" : fatal error: illegal URI for input: "mini2.xml" : ### Failure in: 4:document transformation tests:0 expected: " ignore unknown important important " but got: "" Cases: 110 Tried: 42 Errors: 0 Failures: 5 fatal error: illegal URI for input: "mini2.xml" : ### Failure in: 4:document transformation tests:1 expected: "ignoreunknownimportantimportant" but got: "" Cases: 110 Tried: 43 Errors: 0 Failures: 6 fatal error: illegal URI for input: "mini2.xml" : ### Failure in: 4:document transformation tests:2 expected: " important important " but got: "" Cases: 110 Tried: 44 Errors: 0 Failures: 7 fatal error: illegal URI for input: "mini2.xml" : ### Failure in: 4:document transformation tests:3 expected: " ignore important " but got: "" Cases: 110 Tried: 110 Errors: 0 Failures: 8 Counts{cases=110,tried=110,errors=0,failures=8} Main> ]] Thus it looks as if all of the failures are due to an invalid URI for a local file. This is a re-run of an old problem, traced back to: [[ setDefaultURI :: XState state () setDefaultURI = do wd <- io getCurrentDirectory setSysParam transferDefaultURI ("file://localhost" ++ wd ++ "/") ]] -- XmlInput.hs The value returned by getCurrentDirectory on Windows is not valid as part of a URI. I previously fixed this by replacing the above with the following: [[ {- original: setDefaultURI :: XState state () setDefaultURI = do wd <- io getCurrentDirectory setSysParam transferDefaultURI ("file://localhost" ++ wd ++ "/") -} -- Revised version to allow Windows directory strings. [[[GK]]] -- -- If the current directory starts with 'd:', it is assumed to be a Windows -- directory, and all '\' characters are mapped to '/'. -- -- In any case, any non-URI or reserved character is escaped. setDefaultURI :: XState state () setDefaultURI = do wd <- io getCurrentDirectory let wd1 = case wd of d:':':_ | driveLetter d -> '/':concatMap win32ToUriChar wd otherwise -> concatMap escapeNonUriChar wd setSysParam transferDefaultURI ("file://localhost" ++ wd1 ++ "/") -- [[[I'd prefer to leave 'localhost' as null, but this raises -- awkward questions about whether it's OK to remove a -- null authority from a URI]]] where win32ToUriChar '\\' = "/" win32ToUriChar c = escapeNonUriChar c escapeNonUriChar c = escapeChar isUnescapedInURI c -- from Network.URI driveLetter d = d `elem` ['A'..'Z'] -- to test: -- run () $ do { uri <- getDefaultURI ; io (putStrLn uri) } {- Excerpt from: http://www.ietf.org/internet-drafts/draft-hoffman-rfc1738bis-01.txt 2.7 FILES The file URL scheme is used to designate files accessible on a particular host computer. This scheme, unlike most other URL schemes, does not designate a resource that is universally accessible over the Internet. A file URL takes the form: file://<host>/<path> where <host> is the fully qualified domain name of the system on which the <path> is accessible, and <path> is a hierarchical directory path of the form <directory>/<directory>/.../<name>. As a special case, <host> can be the string "localhost" or the empty string; this is interpreted as "the machine from which the URL is being interpreted". However, this part of the syntax has been ignored on many systems. That is, for some systems, the following are considered equal, while on others they are not: file://localhost/path/to/file.txt file:///path/to/file.txt Some systems allow URLs to point to directories. In this case, there is usually (but not always) a terminating "/" character, such as in: file://usr/local/bin/ On systems running some versions of Microsoft Windows, the local drive specification is preceded by a "/" character. Thus, for a file called "example.ini" in the "windows" directory on the "c:" drive, the URL would be: file:///c:/windows/example.ini For Windows shares, there is an additional "/" prepended to the name. Thus, the file "example.doc" on the shared directory "department" would have the URL: file:////department/example.doc The file URL scheme is unusual in that it does not specify an Internet protocol or access method for such files; as such, its utility in network protocols between hosts is limited. -} ]] I also needed to add an import to XmlInput.hs: [[ import Network.URI ( isUnescapedInURI, escapeChar ) ]] ... I also find I must modify ProtocolHandlerFile.hs to strip off the leading '/' from the path to work on Windows. The following change is made to function getFileContents: [[ {- Original: source = path uri readErr msg = addFatal msg n -} -- [[[GK]]] strip off leading '/' from Windows drive name source = fileuripath (path uri) fileuripath ('/':file@(d:':':more)) | driveLetter d = file fileuripath file = file driveLetter d = d `elem` ['A'..'Z'] readErr msg = addFatal msg n ]] ... Finally, I must copy mini1.xml and mini2.xml into the directory from which I'm running Hugs (i.e. HXmlToolbox-4.00/examples), and the test program runs with no errors: [[ Cases: 110 Tried: 110 Errors: 0 Failures: 0 Counts{cases=110,tried=110,errors=0,failures=0} ]] ... Well, that wasn't too hard, second time around. Maybe we should abstract out the URI<->filename mapping logic into another module that is specifically to handle the file: URI scheme. Dopes it make sense to add such a module to the network branch of the library hierarchy, to sit alongside the HTTP modules? #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

RE: DData
by Simon Marlow 07 Apr '04

07 Apr '04

> JP Bernardy wrote: > > [...] Therefore, I hereby submit it to the people in charge > > of the hierarchical libraries, for integration. Of > > course, if any specific detail deserves work, I remain > > available. [...] > > I could add DData to the hierarchical libraries in the > fptools repository, > but first a few points should be clarified: Can we hold off on this a while longer please. Partly because I am not here :-) but also I think it needs at least one more round of reviewing, and there is still Ross's overloaded sequences suggestion to decide on. The intention was for the DData libraries to be placed directly under Data (i.e. Data.Set etc.). I had imagined that we would leave the old interfaces available too, deprecated, as long as the names didn't clash. None of this precludes adding overloaded collections later; all we're doing here is adding some concrete data structures. Cheers, Simon

3 2