- Libraries - Haskell.org

happy 1.14
by Iavor S. Diatchki 21 Feb '04

21 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 18 Feb '04

18 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 17 Feb '04

17 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

Code for conversion to and from UTF8
by George Russell 13 Feb '04

13 Feb '04

I don't know if anyone else has done this, but I thought my own effort (attached) might be of interest. It converts String -> String to and from UTF8 representations. It /should/ compile with any Haskell98 compiler which also has the (base) library Data.Bits. I'd be happy to see it in the standard hierarchy, if that's desired. Good points: (1) I think I've tested it fairly thoroughly; (2) when decoding UTF8 sequences, it rejects all ill-formatted sequences, and such errors can be easily detected (without exception handlers). Bad points: it's unoptimised. {- This module contains functions for converting to and from the UTF8 representations for Strings. -} module UTF8( toUTF8, -- :: String -> String -- Converts a String (whose characters must all have codes <2^31) into -- its UTF8 representation. fromUTF8WE, -- :: Monad m => String -> m String -- Converts a UTF8 representation of a String back into the String, -- catching all possible format errors. -- -- Example: With the Haskell module Control.Monad.Error, you can -- instance this as -- (fromUTF8WE :: String -> Either String String) -- to get a conversion function which either succeeds (Right) or -- returns an error message (Left). ) where import Char import List import Data.Bits -- -------------------------------------------------------------------------- -- Encoding -- -------------------------------------------------------------------------- -- | Converts a String into its UTF8 representation. toUTF8 :: String -> String toUTF8 [] = [] toUTF8 (x:xs) = let xs1 = toUTF8 xs ox = ord x mkUTF8 :: Int -> String -> Int -> Int -> String mkUTF8 x0 xs0 xmask0 xmax0 = let xbot = 0x80 .|. (x0 .&. 0x3f) x1 = x0 `shiftR` 6 xs1 = chr xbot : xs0 in if x1 < xmax0 then chr (xmask0 .|. x1) : xs1 else let xmask1 = xmask0 .|. xmax0 xmax1 = xmax0 `shiftR` 1 in mkUTF8 x1 xs1 xmask1 xmax1 in if ox <= 0x7f then x : xs1 else if ox `shiftR` 31 /= 0 then error ("Huge character with code " ++ show ox ++ " detected in string being converted to UTF8.") else mkUTF8 ox xs1 0xc0 0x20 -- | Converts a UTF8 representation of a String back into the String, -- catching all possible format errors. -- -- Example: With the Haskell module Control.Monad.Error, you can -- instance this as -- (fromUTF8WE :: String -> Either String String) -- to get a conversion function which either succeeds (Right) or -- returns an error message (Left). fromUTF8WE :: Monad m => String -> m String fromUTF8WE [] = return [] fromUTF8WE (x0 : xs0) = let ox = ord x0 in case topZero8 ox of 7 -> do xs1 <- fromUTF8WE xs0 return (x0 : xs1) 6 -> fail "UTF8 escape sequence starts 10xxxxxx" 0 -> fail "UTF8 escape sequence starts 11111110" -1 -> fail "UTF8 escape sequence starts 11111111" n -> let r = 6 - n -- number of 6-bit pieces xtop = ox .&. ones n minx = bit ( if r == 1 then 7 else 5*r + 1 ) mkx [] _ _ = fail "UTF8 string ends in middle of escape sequence" mkx (ch : xs1) x0 count0 = do let och = ord ch if och .&. 0x80 /= 0x80 then fail ("UTF8 escape sequence contains continuing " ++ "character not of form 10xxxxxx") else return () let xbot = och .&. 0x3f x1 = (x0 `shiftL` 6) .|. xbot count1 = count0 - 1 if count1 == 0 then return (x1,xs1) else mkx xs1 x1 count1 in do (x,xs1) <- mkx xs0 xtop r if x < minx then fail ("UTF8 escape sequence contains character not " ++ "optimally encoded") else do xs2 <- fromUTF8WE xs1 return (chr x : xs2) -- -------------------------------------------------------------------------- -- Binary utilities -- -------------------------------------------------------------------------- -- | return the number of the top bit which is zero, or -1 if they -- are all zero, for a number between 0 and 255. topZero8 :: Int -> Int topZero8 i = case (findIndex not (map (\ bn -> testBit i bn) [7,6..0] )) of Just n -> 7 - n Nothing -> -1 -- | (ones i) is number with binary representation 1 written i times. ones :: Int -> Int ones i = bit i - 1

2 1

RE: [Haskell] Weaving the Web with Haskell
by Simon Marlow 05 Feb '04

05 Feb '04

> On a tangentially related point, portability of several of > the existing > standard hierarchical libraries is rather patchy too. For instance, > the main reason that nhc98 does not currently ship with System.Time > from the base package, or any of the network or unix packages, is that > the checked-in implementations have a tool-dependency on hsc2hs. > (The latter does not appear to have a stand-alone distribution > independent of ghc, so it would be necessary to incorporate > it into the > nhc98 tree, and I don't currently have the time available to untangle > hsc2hs's configuration and build system and re-tangle it for nhc98.) > > I guess I'm with Sigbjorn on wanting to reduce the number of tool > dependencies, even though I happen to like GreenCard and hsc2hs > for what they can automate. Or perhaps, rather than reducing the > dependencies, I want to reduce their impact, by making the tools much > easier to get hold of, configure, and install. Splitting off hsc2hs into a standalone distribution wouldn't be too difficult, and is definitely a worthwhile task if anyone would like to take it on. Looking at the sources, it has some #ifdef __NHC__ so it looks like it worked on nhc98 at some point. It's a single module Haskell program with an auxiliary file (template-hsc.h). It needs to know one or two things about the system: what the C compiler is called, or where GHC can be found. That's about it, as far as I can tell. Cheers, Simon

1 0

Patch for Debug.QuickCheck
by Martin Sjögren 05 Feb '04

05 Feb '04

I just noticed that while the check function and the Config type are exported from Debug.QuickCheck, there is no "default" config exported. I attached a patch that exports a 'defaultConfig' variable that's equal to the normal 'quick' config. /Martin

2 1

RE: [Haskell] Weaving the Web with Haskell
by Graham Klyne 05 Feb '04

05 Feb '04

At 16:23 03/02/04 +0000, Simon Peyton-Jones wrote: >Having solid libraries for XML and HTTP would be a jolly good thing. As >you know, there is plenty of raw material around, but it obviously >doesn't do what you want, yet. I think I'm very close, based on the HXml Toolkit software and a few bits. I was parsing XML directly from the web earlier today, using Hugs on Win32. >If you, together with other interested parties, were to get together to >do this, the rest of us would be very grateful. You could do that by >directly working on the libraries distributed with GHC and Hugs (we >could give you CVS access). I'd like to see this become part of the standard libraries, when it becomes sufficiently stable and portable. I can't say how Uwe Schmidt feels about this. > Or you could make a separate project of it, >and distribute the stuff separately, which would free you from the GHC >and Hugs's release cycles. If the new library infrastructure project takes off, that could be an attractive option. I assume that in due course, the hierarchical libraries would move into such a framework. My goal is to be able to write software that uses an XML library that is easy for people not experienced with Haskell to obtain and load into their running environment. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

2 1