February 2004 - Libraries

RE: DData in hierarchical libraries
by Simon Peyton-Jones 23 Feb '04

23 Feb '04

JP Good for you! Do press ahead with getting a tidied-up interface agreed. (I doubt many people will have much to say, but don't be discouraged by that.) A good plan would be to Haddock-ise the source code, generate the HTML and send the link to the libraries list. That way people could easily browse your proposed interface. I wonder if any existing libraries could be removed (or, rather, deprecated) when you add DData? If so, say so. Simon | -----Original Message----- | From: libraries-bounces(a)haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of JP Bernardy | Sent: 20 February 2004 13:27 | To: libraries(a)haskell.org | Subject: DData in hierarchical libraries | | Dear Haskell Librairies Mailing List, | | Some time ago we discussed the inclusion of DData in | hierachical libraries. | | I remember Simon Marlow proposing someone "thrashes | out the details" and present the result for review. | | So, I've played with the code, to come up with a list | of proposed changes.

1 0

Re: new release of LIP prototype API
by Graham Klyne 23 Feb '04

23 Feb '04

At 15:55 22/02/04 -0500, Isaac Jones wrote: >Yep. It's unixy. See above. If you have any #defines I can add to >the code for windows, please pass them along. My preference would be to try and concentrate the system dependencies into a single location, (or to minimize their appearance). To that end, I'm minded to try and do an implementation of a basic parameter-grabbing module that can be easily re-implemented for different environments. Maybe easier said than done. But based on your responses this would be complementary to the work you're doing. >Let me know if I answered your questions well enough. That was helpful, thanks. I'll study the info more deeply later. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

new release of LIP prototype API
by Isaac Jones 22 Feb '04

22 Feb '04

Greetings, I just uploaded a new release of the Library Infrastructure prototype API for Distribution.Package and the command-line utility "haskell-config". The API for package configuration is included below, FYI. I'm going to be focusing more on the Build stuff (rather than the packaging stuff) for a little while, but with luck, this can be near to finalization soon. The web page is here: http://www.haskell.org/libraryInfrastructure/ Feedback and volunteers for coding are always welcome :) peace, isaac ps. I'm using arch (tla) for version control, so if you've been wanting to check it out, now is a good time :) ------------------------------------------------------------ lookupPackage :: PackageDB -> PkgIdentifier -> Maybe PackageConfig addPackage :: PackageDB -> PackageConfig -> PackageDB delPackage :: PackageDB -> PkgIdentifier -> (PackageDB, Bool) allPackages :: PackageDB -> [PackageConfig] createPackageDB :: FilePath -> (PackageDB -> IO PackageDB) -> IO () withPackageDB :: FilePath -> (PackageDB -> IO (PackageDB, a)) -> IO a userPkgConfigLocation :: String -> FilePath userPkgConfigLocation home = home ++ "/.haskell/packages.conf" systemPkgConfigLocation :: FilePath systemPkgConfigLocation = "/etc/haskell/packages.conf" PackageConfig(..), PkgIdentifier(..), License(..), Dependency(..), PackageDB

2 3

RE: new release of LIP prototype API
by Simon Marlow 22 Feb '04

22 Feb '04

> I just uploaded a new release of the Library Infrastructure prototype > API for Distribution.Package and the command-line utility > "haskell-config". The API for package configuration is included > below, FYI. The package API is much simpler, thanks. I have an uneasy feeling about the scope of this project: it seems to be tackling too much. Perhaps my doubts are unfounded... What's the purpose of the build_deps field in a PackageConfig? This seems to indicate that the PackageConfig has a lot more functionality than I thought - to me, the PackageConfig contains the information that a compiler needs to know in order to use a package at compile time (similarly for an interpreter). But the presence of build_deps seems to indicate that it's much more than this: is it supposed to contain enough information to be able to rebuild the package? Is the system supposed to be able to rebuild packages on demand? Can it downlaod and build dependencies if they aren't available? If the answers to any these questions are yes, then I have the feeling that a large can of worms has been opened. Life is much simpler if the answer to these questions is no ;-) Cheers, Simon

2 1

happy 1.14
by Iavor S. Diatchki 20 Feb '04

20 Feb '04

hi everyone, (this is an fptools/library infrastructure question) i was just trying to compile my monad library from scratch, and the configuration check the makefile does at the beginning (i don't understand how it works) failed complaining that happy 1.14 is needed to compile ghc (and i have 1.13). (incidently happy 1.14 is not released yet) now, i am not trying to compile ghc (just my library), but i am not sure how to fix the makefiles as i don't really understand the fptools build system. do you have any pointers, tips, tricks hints etc? ideally i would like the makefile for the library to be as simple as possible, but i guess it would be nice if it is compatable with the rest of the fptools stuff. for example, i noticed that the makefile makes two libraries (one with profiling), and also uses some flags to split up the object files in little bits. there are also some common "targets". so are these things described somewhere, so that if i was to write my own makefile, i could try and make it "compatable". i wouldn't mind (in fact i would prefer to) reusing the "common" make structure as long as i know exactly what files i need to distribute with the library, and the make process does not do unneccessary things. for example, the monad library is written in haskell, and it only uses standard libraries. so the only requirement it has is a running version of ghc (and perhaps haddoc if the documentation is wanted). there is no need to do the whole "configure" thing, checking the size of integers, and what not :-) so can i achive this with the existsing make system, or should i write my own makefile(s)? -iavor -- ================================================== | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | ==================================================

2 1

URI handling code; proposed Network.URI replacement
by Graham Klyne 20 Feb '04

20 Feb '04

I've completed the functionality of my proposed upgrade to Network.URI, though there are still a couple of issues that need to be resolved with the ongoing RFC2396bis work (none critical to the general functionality). This is still work-in-progress, but I'm airing it now to see if folks think it's an acceptable upgrade to the existing Network.URI module. There is an extensive test suite that runs without fault under Hugs and GHCi. This module duplicates the general functionality of the old GHC Network.URI module, and adds: - functions to parse different categories of URI (relative, absolute, URI-reference, etc.) - functions to test for different kinds of URI (returning Bool instead of Maybe URI). - 'relativeFrom', a function to calculate a relative URI with respect to a given base, to complement the existing 'relativeTo'. - functions to perform some common forms of URI normalization. - default behaviour is to not display the password field associated with userinfo in a URI. (This area needs some tidying up). The structure of the underlying URI implementation has changed quite a lot, but I've also defined some accessor functions that reflect the original structure fields. (Oops, I just noticed I forgot to export them) The code can be browsed at: http://www.ninebynine.org/Software/HaskellUtils/Network/ #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

RE: happy 1.14
by Simon Marlow 20 Feb '04

20 Feb '04

> (this is an fptools/library infrastructure question) > > i was just trying to compile my monad library from scratch, > and the configuration check the makefile does at the > beginning (i don't > understand how it works) > failed complaining that happy 1.14 is needed to compile ghc > (and i have > 1.13). > (incidently happy 1.14 is not released yet) > now, i am not trying to compile ghc (just my library), but i > am not sure > how to > fix the makefiles as i don't really understand the fptools > build system. > do you have any pointers, tips, tricks hints etc? The configure script will only complain about the lack of Happy if: - the GHC sources are in the tree (ie. fptools/ghc exists), and - the Happy sources are *not* in the tree (ie. fptools/happy does not exist) so to avoid the error, make one of these False :-) Happy 1.14 will be released at some point, since it's required to build the next major version of GHC (6.4). > ideally i would like the makefile for the library to be as simple as > possible, > but i guess it would be nice if it is compatable with the rest of the > fptools stuff. > for example, i noticed that the makefile makes two libraries > (one with profiling), > and also uses some flags to split up the object files in > little bits. there are also some > common "targets". so are these things described somewhere, > so that if i was to write > my own makefile, i could try and make it "compatable". > > i wouldn't mind (in fact i would prefer to) reusing the "common" make > structure > as long as i know exactly what files i need to distribute with the > library, and the make process > does not do unneccessary things. for example, the monad library is > written in haskell, > and it only uses standard libraries. so the only requirement > it has is a running version of ghc > (and perhaps haddoc if the documentation is wanted). there is no need > to do the whole "configure" thing, checking the size of integers, and > what not :-) > so can i achive this with the existsing make system, or > should i write my own makefile(s)? It is possible to use the fptools build system for shipping a separate library, but I won't claim that this is easy or well-tested. The build system has a setting called "STANDALONE_PACKAGE" for this purpose. So setting STANDALONE_PACKAGE=YES in your Makefile might help things along a bit. There isn't an easy way to do what you want to do. This is why the library infrastructure project was started :-) You can either use the fptools build system, which requires learning how it works, or you could write your own Makefiles from scratch, which requires re-writing a lot of stuff that the fptools system already does. There is some documentation for the fptools build system, but it doesn't cover packages in much detail: http://www.haskell.org/ghc/docs/latest/html/building/building-guide.html Cheers, Simon

1 0

RE: Data.Set whishes
by Simon Marlow 17 Feb '04

17 Feb '04

> could the following be added to Data.Set? > * instance Ord element => Monoid (Set element) Due to dependency issues, this would have to be defined in the Monoid module, or later. > * subsetOf :: Ord element => Set element -> Set element -> Bool This could be added (I agree with Ketil that isSubsetOf follows existing conventions better). Do you have a patch? Cheers, Simon

2 1

Network.URI module
by Graham Klyne 16 Feb '04

16 Feb '04

I went rather quiet on this topic, partly because there have been a flurry of late comments and changes to the RFC2396bis work-in-progress spec [1] (some with the effect of simplifying the syntax). I plan to update my implementation accordingly within the next 2 weeks, and add some (separate) path-normalization logic so that I can run all of my test cases. Meanwhile, there were a couple of questions in my previous message to which I've not noticed any answers... What are the ground rules for potentially non-backward-compatible changes? What are the procedures for lodging new releases (CVS?). A proposal to change the code structure while (mostly) preserving backward compatibility (details below). #g -- [1] http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html At 10:44 03/02/04 +0000, Simon Marlow wrote: > > (1) Network.URI > > > > I've written a new parser, and extended the module interface > > slightly, thus: > >[snip] > >If you'd like to become the maintainer of this module and incorporate >your changes, you're entirely welcome (I'm not using this code actively >at the moment). I'd be happy to do that. What are the ground rules for potentially non-backward-compatible changes? What are the procedures for lodging new releases (CVS?). >You mentioned that there were problems with the existing implementation >- perhaps you could explain further? As far as I'm aware, the regular >expression and the test cases were taken directly from RFC 2396, and the >implementation was correct at the time - did something change? The >current testcases are in testsuite/tests/ghc-regress/lib/net/uri001.hs. I don't think it was a problem with the regular expression per se: (a) the regex in RFC2396 doesn't tell you (reliably) if a URI is or is not valid. What it does do is, assuming a valid URI is presented, is pick apart the various components. (b) I would have stuck with the regex-based implementation here, except that the regex module used is not available on Windows. For me, it was easier to construct a URI parser using Parsec, which doesn't depend on system-dependent modules. (c) there are some small changes in syntax that might affect the regex implementation: reserving '[' and ']' for use in IPv6 literals comes to mind. I haven't checked the details. My parser follows the syntax in the RFC2396bis proposal very closely. As such, it will reject some URIs that the regex implementation would accept. My own test suite includes all the RFC2396 test cases. (The RFC2396 proposal already has extensive review and broad consensus in the URI working group; my Haskell work is providing some implementation feedback.) The problems with behaviour of the current implementation that I did note are covered below... > > I have some concerns about the way URI strings are > > reassembled from the > > component parts using the current URI module interface (e.g. > > problem with > > empty fragment handling noted in a previous message). I > > think the URI > > implementation should be changed so that all the punctuation > > characters > > ("//", "?", "#", etc.) are stored as part of the component > > values in a URI > > structure, but I don't know what impact that might have on > > existing code. > >If that's an unforced change I'd vote to keep the current behaviour, to >avoid breaking code. It's not entirely "unforced"... it has to do with the way a URI is stored internally, and the consequences for reconstructing a URI string from the URI components; e.g. file:///path/name is reconstructed as: file:/path/name http://example.org/path/resource# is reconstructed as: http://example.org/path/resource I have a question [1] outstanding with the URI WG about the validity of the first, and do believe that the second is incorrect (there has been some discussion that the presence of a fragment is significant in some web applications). There is a general presumption in Web circles that a URI should be used in exactly the form given; cf. [2]. [1] http://www.w3.org/mid/5.1.0.14.2.20040202132114.00bd6ec8@127.0.0.1 (Can't get proper URI yet ... lists.w3.org is down as I write) [2] http://www.w3.org/2001/tag/webarch/#lc-uri-chars I suppose it would be possible to make a new implementation of the URI structure that presents the same interface, but remembers the presence of empty fields, but I'm concerned that would be locking in undesirable complexity and propagating a debatable design. (Question: why would one wish the URI components to be stored without their distinguishing punctuation?) ... Here's a proposal: (a) change URI thus: [[ data URI = URI { uriScheme :: String -- ^ @http:@ , uriAuthority :: String -- ^ @//www.haskell.org@ , uriPath :: String -- ^ @/ghc@ , uriQuery :: String -- ^ @?query@ , uriFragment :: String -- ^ @#frag@ } ]] (b) implement access functions that behave like the original field selectors. Then the visible change in behaviour would be that 'show' of any URI would reconstruct exactly the string supplied to construct it. If it turns out that the alternative access functions are not needed, they could be dropped in a later revision (hmmm... do Haskell impleemnetations offer a deprecated flag?). #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

Data.Set whishes
by Wolfgang Jeltsch 16 Feb '04

16 Feb '04

Hello, could the following be added to Data.Set? * instance Ord element => Monoid (Set element) * subsetOf :: Ord element => Set element -> Set element -> Bool Wolfgang

2 1