- Libraries - Haskell.org

XML libraries, again
by Graham Klyne 23 Mar '04

23 Mar '04

Further to my previous message: http://www.haskell.org//pipermail/libraries/2004-March/001853.html I've spent some more time getting to know the HaXml and HXml toolbox libraries. I've written a simple (HUnit-based) test module which might be a basis for future regression tests for either library (with small modifications), though for now it performs only very few simple tests. I have now been able to isolate the XML parser in HXml Toolbox from the IO-bound XmlFilter logic, so I can use it outside the IO monad. This turned out to be easier than I first feared. In so doing, the previously suspected inability to catch errors in the program is overcome. I've also spent a little time with the HaXml library, and modified the parser (HMW) combinator code so that errors are passed back via an (Either String a) value, rather than simply throwing an error, so that a calling program can take control of error conditions. Overall, I'm finding the codebases comparable to work with. On my limited experience to date, HaXml has been easier to get into, but looking easier to make more fundamental structural modifications with HXml Toolbox. Given thatr HXml Toolbox already has much of the functionality I require, I am planning (for now) to continue with that. Copies of my (current) working codebases can be found at: http://www.ninebynine.org/Software/HaskellUtils/HaXml-1.11/ http://www.ninebynine.org/Software/HaskellUtils/HXmlToolbox-3.01/ In each case, my test module is in a new subdirectory 'test'. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

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

23 Mar '04

> It was an actual request for information. I'd really love to > be able to > just open an editor to let the user edit a file and have it > just work, and > currently I have no way of doing that which works with vi. > On the other > hand, if the answer is "No, don't pass stdin and stdout to > runInteractiveProcess", it would still be a very useful call, it just > wouldn't solve my vi problem. I admit I didn't follow the finer details of this discussion. But we ought to reach a conclusion. The original question, correct me if I'm wrong, is can I invoke an interactive editor that uses stdin/stdout using runInteractiveProcess? the answer is no - that isn't what runInteractiveProcess is for (perhaps the name is misleading). You can however happily invoke an editor using runProcess. I just tested it, and it works fine. GHC *might* have changed the terminal settings for stdin/stdout - this doesn't make any difference, as long as the Haskell program doesn't change the buffering on stdin/stdout while the editor is running. David - does that solve your problem? Cheers, Simon

2 1

Re: DData revision
by Wolfgang Jeltsch 23 Mar '04

23 Mar '04

Am Sonntag, 14. März 2004 18:31 schrieben Sie: > [...] > > And why does Seq.concat have the type > > Seq (Seq a) -> Seq a > > instead of > > [Seq a] -> Seq a > > which would be more consistent with the other modules? > > I gave it some thought, and concluded that it is more > important for Seq to be consitent with itself than with > other modules. This really should be solved with type > classes, yet we chose not to introduce new classes with > DData. > > Moreover, Seq is an instance of Monoid, so 'mconcat' > can be used. But why does LambdaSeq.concat have the type [LambdaSeq a] -> LambdaSeq a instead of LambdaSeq (LambdaSeq a) -> LambdaSeq a then? > [...] > Cheers, > JP. Wolfgang

4 6

Re: [Haskell] New version of the HTTP module
by Graham Klyne 22 Mar '04

22 Mar '04

At 11:18 17/03/04 +0100, Bjorn Bringert wrote: >I have reverted the type of the exported openTCP to String -> IO >Connection, it now always uses port 80 like the old version did. Instead >there is an internal function openTCPPort that takes a port number. I will >try to have a look at the Browser module to see what needs to be done to >make it support arbitrary port numbers and if it needs any other updates. > >An updated version of HTTP.hs is available at >http://www.dtek.chalmers.se/~d00bring/haskell-xml-rpc/HTTP.hs OK, that works. I just re-ran the HXml Toolbox HUnitExample test successfully, using the new HTTP module (with some further edits) and my new URI module. I also had to apply a small edits to Browser.hs (to include Proxy in the export list). I am finding that there are some (easily fixed) incompatibilities with my revised Network.URI module. (I also note that the HTTP module duplicates the Authority-parsing functionality that is also present in my Network.URI module, but that can be sorted out later.) In my module, I changed the structure of the URI datatype, though I do provide functions to access components with their original names. Unfortunately, the HTTP module makes some use of the "value { component=value }" syntax to define new URI values, which is not compatible. If we are to adopt my version, these instances will need changing. This will, in turn, require some synchronization of the change-over. Here are the differences: [[ Compare: (<)D:\Cvs\DEV\HaskellUtils\Network\HTTP.hs (46201 bytes) with: (>)D:\Cvs\DEV\HaskellUtils\Network\HTTP-bjorn.hs (45931 bytes) 13,15c13 < -- ** Changes by Graham Klyne: < -- - export httpVersion < -- - use new URI module (similar to old, but uses revised URI datatype) --- 85d81 < httpVersion, -- [GK] 498,499c493,494 < alt_uri = show $ if null (uriPath u) || head (uriPath u) /= '/' < then u { uriPath = '/' : uriPath u } --- > alt_uri = show $ if null (path u) || head (path u) /= '/' > then u { path = '/' : path u } 985,986c980 < -- r { rqURI = (rqURI r){ scheme = "", authority = "" } } < r { rqURI = (rqURI r){ uriScheme = "", uriAuthority = Nothing } } --- > r { rqURI = (rqURI r){ scheme = "", authority = "" } } ]] My full codebase for HTTP and URI can be seen at: http://www.ninebynine.org/Software/HaskellUtils/Network/ My suggestion would be that we make the change-over by moving these to the library CVS as a single unit. But I guess we should see if the URI changes are going to cause any other similar problems. Do we have a stand-alone test harness for the HTTP code? I've been using the HXml Toolbox unit tests. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

2 2

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