March 2004 - Libraries

RE: DData revision
by Simon Marlow 22 Mar '04

22 Mar '04

> > In an > > ideal world, we'd rename seq which is surely up > > there on the list of opaque, > > immemorable function names but, in this less than > > ideal world, using a > > different name for Seq would be good if someone can > > suggest one. (Sequence?) > > Robert proposes CatenableSeq, which I like because it > reflects closely the purpose of the type. > > Unless someone has a better idea along this lines, > I'll make the change. I'm usually in favour of longer, more descriptive and consistent naming schemes, but in this case I vote against the longer name, simply on the grounds that the type is going to be quite widely used. Cheers, Simon

1 0

RE: DData revision
by Simon Marlow 22 Mar '04

22 Mar '04

> On Fri, 19 Mar 2004, Robert Will wrote: > > > > By the way: a Sequence implementation based on OrdList is not too > > attractive either... > > I have had a look at OrdList (in GHC 5.00 and JPs DData) and this has > really no advantage over the simple Catenable Sequences, in > fact it only uses data cells where the other one uses closures. I didn't write OrdList, but I don't agree: toList.fromList is O(n) in the the closure version, but O(1) in the OrdList version. I suppose in a sense that is really a constant factor difference, because with laziness the closure version only adds a constant factor to the O(n) operation that observes the result list. But it also unshares the result list, which might be important. > Also the implementor > has not been too clever, since in the function OLtoList he uses the > Closure-trick to create the resulting list, but just the same > would have been achieved by a call to foldr! Indeed, toList is just a specialised version of foldr. Probably either (a) a specialised version was used for speed, or (b) foldr was added later. Cheers, Simon

1 0

RE: DData revision
by Simon Marlow 20 Mar '04

20 Mar '04

> A revision of DData. > > http://users.skynet.be/jyp/DData/doc > http://users.skynet.be/jyp/DData/ddata.tar.gz > > New sequences are added. I've tried to reflect settled > issues in the code. If it is not so, tell me. I like the new Seq. Do we need DData.LambdaSeq too? Does it bother anyone that the use of Seq here migh get confused with the 'seq' function? Similarly for Map. Cheers, Simon

4 3

RE: Win32 process spawning, POpen and Hugs, revisited
by Simon Marlow 19 Mar '04

19 Mar '04

On a related note, I recently implemented a System.Process library on Unix. Source code attached. The Windows implementation should be relatively straightforward. Porting it to Hugs will require System.Posix.forkProcess, but I don't see any great difficulties there. One warning: if you want to use it in a concurrent environment with GHC, you need to use GHC's threaded RTS (i.e. use the -threaded option in the forthcoming GHC 6.2.1), otherwise waitForProcess will block all threads. POpen-type abstractions can easily be layered on top of the functionality here - indeed the library should probably contain some higher-level versions which correspond to common usage. I think this is a good platform-independent abstraction for process management. What do others think? Cheers, Simon

5 10

RE: HaXml and HXml toolbox; namespace support
by Simon Marlow 19 Mar '04

19 Mar '04

> Well, IIRC the reason for wanting independent releases was about > keeping up-to-date in a more specific sense: when GHC shipped with > HaXml, the code was always woefully out-of-date because there were > two separate CVS repositories, my own and the GHC one, and they were > structured differently. It was far too much of a pain to maintain > and synchronise the two repositories, so the GHC one languished. > > Now however, the repositories (including ghc/nhc98/Hugs as well as > the libraries) are unified, so synchronisation is not a problem. > Each compiler should always have the latest version of the library > available when a release is forged. Additionally, if you recall, > HaXml used to be just one part of the 'text' package, alongside Parsec > and various other things, which militated strongly against updating > it independently. We now have a more fine-grained package mechanism, > which permits the user of a compiler to update an individual package > like HaXml in between compiler releases. Hugs handles this by > separating the 'contributed' packages into separate directories, > distinct from the 'core' packages which install into a single > directory hierarchy. (Ghc and nhc98 both use separate directories > for all packages.) Fair enough. GHC also puts all the interface files for its hierarchical packages into the same directory, BTW. Cheers, Simon

1 0

RE: HaXml and HXml toolbox; namespace support
by Simon Marlow 19 Mar '04

19 Mar '04

> > HaXml > > ----- > > + Already part of the common hierarchical library > > ... and will be distributed as part of the next release of Hugs. GHC used to ship with HaXml, but we stopped doing this, I believe after discussing it with you. I think the reasoning was that you wanted to be able to distribute new versions of HaXml independently. Is it really a good idea to bundle HaXml with Hugs? Cheers, Simon

3 2

HaXml and HXml toolbox; namespace support
by Graham Klyne 19 Mar '04

19 Mar '04

I'm currently looking at the innards of HXml Toolbox and HaXml, with a view to adopting an XML parser with XML namespace support. Based on that requirement alone, HXml Toolbox would be the obvious choice, since it already has namespace support, but I have some concerns. These may simply be my own ignorance, so I'm airing my views here so that any misconceptions can be corrected. I present my thoughts in terms of pro's and con's for each. HXml Toolbox ------------ + XML Namespace support + DTD Entity handling + Good degree of conformance to W3C test suite - difficult to find way around documentation; no obvious high-level description, other than Martin Schmidt's thesis which is out-of-date with respect to the current software. - can't find simple String -> XML tree parsing function (dealing with Internal DTD Entity components) - errors seems to be reported to stderr rather than handed back to the calling program - complex and non-portable distribution: I'm concerned that any attempt distribute my applications based on this library may prove difficult, short of copying (and effectively branching) the complete source code. - not developed with Hugs/Windows as an intended target ? efficiency: some problems parsing large XML files with Hugs 98 are noted. ? still actively supported ? HaXml ----- + Already part of the common hierarchical library + XML handling is cleanly separated from other functions + separate, hand-coded lexer which I assume will give better performance + appears to be actively supported - no namespace support ? DTD Entity handling ? - errors returned to caller. As far as I can tell, errors are raised using the 'error' function... [which I see results in program termination when evaluated]. Ouch! (Why not 'fail' instead of 'error'?) - source code needs CPP preprocessing * no external DTD support [this is not a problem for me, and I'd certainly prefer it to be optional, or at least separated from the XML parsing, to avoid dependency on an HTTP library]. ... A weakness of both packages seems to be the handling of syntax errors in the input. HaXml uses HuttonMeijerWallace combinators - could these be extended in the style of Parsec to return an error description, thus making it possible to provide an interface that allows the calling program to handle any errors? E.g. [[ newtype Parser s t a = P (s -> [t] -> [(a,s,[t])]) ]] becomes, say: [[ newtype Parser s t a = P (s -> [t] -> Either String [(a,s,[t])]) ]] and define fail accordingly. Or, even, just use Parsec? HXml Toolbox makes mention of reporting errors to stderr, I think [lost reference]. It appears that I can isolate the XML parser, which uses Parsec, but I'm not sure if I can isolate the DTD processing logic that deals with entity substitutions.... This looks problematic: it seems that entity substitution is done in an XmlStateFilter Monad. I'm finding it really hard to tease apart the various strands of processing here, which is indicative of my concerns about using this package. ... So, any pointers that help me decide which way to jump would be appreciated... #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

2 1

DData revision
by JP Bernardy 19 Mar '04

19 Mar '04

Hi, A revision of DData. http://users.skynet.be/jyp/DData/doc http://users.skynet.be/jyp/DData/ddata.tar.gz New sequences are added. I've tried to reflect settled issues in the code. If it is not so, tell me. I haven't done anything to argument ordering yet. I have nothing against the right bias, so, I can implement it, but it is easy to forget some cases... That change would need review. Cheers, JP. __________________________________ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com

6 15

DData in hierarchical libraries
by JP Bernardy 19 Mar '04

19 Mar '04

Hello, I've compiled a haddock documentation for my proposal "DData in hierarchical libraries". I submit it to you for review. http://users.skynet.be/jyp/DData/doc/index.html The source code is available too. http://users.skynet.be/jyp/DData/doc/ddata.tar.gz Daan: I take the liberty to "publish" this without knowing the exact terms of your license. Given the audience of this list, I think it will be no problem. Cheers, JP. --------------- For easier review, a summary of changes follow. The source distribution also contains a diff. * Scc module removed More an algorithm than a data structure. Sort of (but not quite) redundant with SCC in Data.Graph * renamed "single" to "singleton" more explicit, more usual. * removed find, favouring (!) and lookup. avoids incoherency with Data.List.find Map.find :: Map k v -> k -> v List.find :: (a -> Bool) -> [a] -> Maybe a * removed (<>), prefering append More explicit. Besides, operators might be a problem in the current scheme of using modules qualified. * rename "isEmpty" to "null" to match List.null * foldL, foldR, foldI -> foldl, foldr, foldi to match Prelude.fold[lr] * Added instances * renamed "subset" to "isSubsetOf" this matches isPrefixOf, isSuffixOf * Added documentation / changed it to reflect changes incl. hints on how to use the module system. ----- I think I should explain why I wanted to change the interface of Maps. Consider the type of these functions: Set.fromList :: Ord a => [a] -> Set a Set.member :: Ord a => a -> Set a -> Bool Set.fold :: (a -> b -> b) -> b -> Set a -> b Set.filter :: Ord a => (a -> Bool) -> Set a -> Set a Map.fromList :: Ord k => [(k, a)] -> Map k a Map.member :: Ord k => k -> Map k a -> Bool Map.fold :: (a -> b -> b) -> b -> Map k a -> b Map.filter :: Ord k => (a -> Bool) -> Map k a -> Map k a With respect to fold and filter (and most functions), maps have the shape of collections of values. (The key type does not appear as such in the functions' signiatures) Yet, a few functions break this conventions. For example, "member" tests the presence of a key, not a value. This is justified by the implementation. I've come to think it is the way to go (given it is a "concrete" library). It makes me slightly uneasy that a few functions stand out, still. __________________________________ Do you Yahoo!? Get better spam protection with Yahoo! Mail. http://antispam.yahoo.com/tools

4 3

RE: Win32 process spawning, POpen and Hugs, revisited
by Simon Marlow 18 Mar '04

18 Mar '04

> The only thing I'd like to check on that I can't tell about is whether > passing stdin and stdout to runProcess will behave "correctly". Some > programs (e.g. gpg) can figure out how to get control of the tty by > themselves (to ask for passwords in the case of gpg), but others (some > versions of vi) will fail if their stdin and stdout > correspond to a tty. > It would be nice to be able to run "user-interactive" > commands such as text > editors in a safe and consistent manner. I'm not clear from your code > whether there will be a problem with passing stdin and stdout to > runProcess. If the process closes stdin, will it be closed > for me? If the > process changes the buffering of stdin, will that change it for me? > Enquiring minds want to know! :) Good questions, none of which I have given any thought to :-) You're almost certainly in a better position than me to decide what reasonable answers to these are, so would you like to propose some? Cheers, Simon

1 0