April 2004 - Libraries

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

Compiler versions
by Simon Peyton-Jones 07 Apr '04

07 Apr '04

Library folk Below is a suggestion from George that initially appears to be about Template Haskell: access to the GHC version identity. But of course it's not strictly a TH thing: we could simply provide a module module GHC.Version where ghcVersion :: Int and then you could import that module anywhere, including in your TH program: import GHC.Version $( if ghcVersion > ... then ... ) And indeed such a thing might be more generally useful, across all Haskell implementations not just GHC. Perhaps it should be module System.Compiler where compilerName :: String releaseDate :: CalendarTime -- or (Day,Month,Year)? version :: (Int,Int) patchLevel :: Int So then a program could ask whether it was being run by Hugs or GHC or whatever. Questions: * Would this be a good thing to agree across compilers? * What should the interface be? I gave one possibility above; George gives another. * I imagine this'd be useful for the library infrastructure project, somehow. Would anyone like to run with this to get an interface agreed? From the GHC end we'd be happy to implement any agreed interface. Simon -----Original Message----- From: George Russell [mailto:ger@informatik.uni-bremen.de] Sent: 07 April 2004 10:46 To: Simon Peyton-Jones Subject: Re: mkName and qualified names George Russell wrote: > incidentally you asked for priorities. Mine are (still) Oh, and another one, (3) access to the current GHC version. For example data GhcVersion instance Read GhcVersion instance Ord GhcVersion thisVersion :: GhcVersion then you can do $( if thisVersion >= read "6.4.1" then [dd| -- use whizzo new features ... |] else [dd| -- sigh. painful workaround for Luddites ... |] ) This isn't nearly as important to me as the other two suggestions I made, however I presume it would be easier to implement. best wishes and thanks, George

5 5

Re: Compiler versions
by Graham Klyne 07 Apr '04

07 Apr '04

I started (and stalled, though not permanently I hope) on a similar idea, to offer as part of the library infrastructure. Mine was somewhat more complex, maybe too much so, dealing with a combination of static and dynamic information, and also hoping to circumvent or minimize the CPP problem. Copies of the initial code and test module are at: http://www.ninebynine.org/Software/HaskellUtils/LibraryInfrastructure/Distr… http://www.ninebynine.org/Software/HaskellUtils/LibraryInfrastructure/Distr… #g -- At 10:59 07/04/04 +0100, Simon Peyton-Jones wrote: >Library folk > >Below is a suggestion from George that initially appears to be about >Template Haskell: access to the GHC version identity. But of course >it's not strictly a TH thing: we could simply provide a module > > module GHC.Version where > ghcVersion :: Int > >and then you could import that module anywhere, including in your TH >program: > > import GHC.Version > $( if ghcVersion > ... then ... ) > >And indeed such a thing might be more generally useful, across all >Haskell implementations not just GHC. Perhaps it should be > > module System.Compiler where > compilerName :: String > releaseDate :: CalendarTime -- or (Day,Month,Year)? > version :: (Int,Int) > patchLevel :: Int > >So then a program could ask whether it was being run by Hugs or GHC or >whatever. > >Questions: > >* Would this be a good thing to agree across compilers? > >* What should the interface be? I gave one possibility above; George >gives another. > >* I imagine this'd be useful for the library infrastructure project, >somehow. > >Would anyone like to run with this to get an interface agreed? From the >GHC end we'd be happy to implement any agreed interface. > >Simon > >-----Original Message----- >From: George Russell [mailto:ger@informatik.uni-bremen.de] >Sent: 07 April 2004 10:46 >To: Simon Peyton-Jones >Subject: Re: mkName and qualified names > >George Russell wrote: > > incidentally you asked for priorities. Mine are (still) > >Oh, and another one, >(3) access to the current GHC version. For example > > data GhcVersion > > instance Read GhcVersion > instance Ord GhcVersion > > thisVersion :: GhcVersion > >then you can do > $( if thisVersion >= read "6.4.1" > then > [dd| -- use whizzo new features > ... > |] > else > [dd| -- sigh. painful workaround for Luddites > ... > |] > ) > > >This isn't nearly as important to me as the other two suggestions >I made, however I presume it would be easier to implement. > >best wishes and thanks, > >George >_______________________________________________ >Libraries mailing list >Libraries(a)haskell.org >http://www.haskell.org/mailman/listinfo/libraries ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

RE: #ifdef considered harmful
by Simon Marlow 07 Apr '04

07 Apr '04

> At 08:57 07/04/04 +0100, Simon Peyton-Jones wrote: > >cpp is readily available everywhere, whereas some new > >tool would not be. > > Hmmm... it was my perception of the falsity of this that led > me to raise > the issue in the first place. See also [1]. > > Otherwise, I broadly agree with the points you make. One good reason for implementing our own preprocessor that nobody has raised yet is that the implementation of cpp we all use (gcc) is not under our control and recently has been changing its semantics in ways that affect us. CPP in gcc 3.4 interprets '\' followed by whitespace at the end of a line as a line continuation; previous versions of cpp didn't do that, and it makes it impossible to use Haskell string gaps in CPP'd Haskell source. I don't trust the GCC guys to keep the -traditional flag around for ever either. I'd settle for just finding a good standalone open source cpp, removing any undesirable features, and shipping it with the compilers. BTW, Hugs copes with CPP directives in the standard libraries by running CPP over the source code before packaging up the distribution: that way CPP isn't required on the target system. Cheers, Simon

1 0

Text.PrettyPrint mixes tabs and spaces??
by Martin Sjögren 07 Apr '04

07 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? Regards, Martin

1 0

RE: #ifdef considered harmful
by Graham Klyne 07 Apr '04

07 Apr '04

At 08:57 07/04/04 +0100, Simon Peyton-Jones wrote: >cpp is readily available everywhere, whereas some new >tool would not be. Hmmm... it was my perception of the falsity of this that led me to raise the issue in the first place. See also [1]. Otherwise, I broadly agree with the points you make. #g -- [1] http://www.haskell.org//pipermail/libraries/2004-April/002009.html ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0