March 2004 - Libraries

State of DData
by JP Bernardy 26 Mar '04

26 Mar '04

Hello, I've updated DData again. http://users.skynet.be/jyp/DData/doc/ http://users.skynet.be/jyp/DData/ddata.tar.gz * Eq I've stated the policy regarding Eq: it should mean equality. This is because it most likely refects general use, and was already more or less implied in Set and Map code. Advanced users can still act differently at their own risk. In the same vein, I've renamed MultiSet to Bag; being synonyms, I favoured the most usual name. * Naming of functions. (ie. isSubsetOf, etc.) I still stick to Data.List naming scheme. These choices are guided by the general goal: having decent concrete data structures fitting nicely in the hierarchy, suitable for daily use. (As opposed to the ultimate all-purpose collection framework) Point left open: * Left/Right bias; structure first/last To me, this barely makes a difference whatever is chosen. For reasons of compatibility with the old FiniteMap/Set, "right bias+structure first" might be better. Since changing the convention is a tedious work, and Daan has expressed the wish to take care of the implementation, I leave the decision to him. I insist though that functions sharing a name with one in Data.List should not have their argument order changed. Namely, having Data.List.lookup :: Eq k => k -> [(k, a)] -> Maybe a DData.map.lookup :: Ord k => Map k a -> k -> Maybe a is inconsistent, thus not desirable. Cheers, JP. __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html

6 10

RE: State of DData
by Simon Marlow 26 Mar '04

26 Mar '04

> Am Freitag, 26. März 2004 13:11 schrieb Keith Wansbrough: > > > > I vote for the current state "left bias+structure > last", as the bias > > > > should not matter much > > > > > > Does the bias matter at all if Eq means equality? > > > > It should be documented, so "advanced users" can rely on > the behaviour. > > In my opinion, even "advanced users" should adhere to The > Haskell Report which says that (==) means equality. Where does the report say that? As far as I can see, the closest quote is this: The Eq class provides equality (==) and inequality (/=) methods. (section 6.3.1). The report doesn't explicitly say anywhere that any assumptions about the properties of == are ever made. Cheers, Simon

2 1

RE: request for HUnit in hierarchical libs?
by Simon Marlow 26 Mar '04

26 Mar '04

> I'd like to make a request that the HUnit testing framework be > converted to a 'package' in the hierarchical libraries, to make for > easier installation and use. If it could be added to the fptools > repository, and so be distributed with new releases of ghc, Hugs, > and nhc98, so much the better, but a separate distribution would be > fine as well. The current distribution appears to be two years old, > so I'm guessing it is pretty stable. I know it has several > keen users, > and making it more readily accessible would be a good goal. Sure, hoick it on over. We'll ship it with GHC and build it by default if it has an active maintainer with CVS access. When the library infrastructure project comes to fruition, I'd like to see us split some of these packages off into separate shippable entities, but for the time being bundling with compilers is fine. > [ > For folks on the libraries list, I would also like to recommend > that the existing 'QuickCheck' package move from its > current location > in 'Debug.QuickCheck' to 'Test.QuickCheck', which is more > descriptive > of its actual use. > ] No objections here. Leave Debug.QuickCheck as an indirection for a while, marked deprecated. Cheers, Simon

4 3

parseCalendarTime
by Bjorn Bringert 25 Mar '04

25 Mar '04

System.Time has formatCalendarTime :: TimeLocale -> String -> CalendarTime -> String but no parseCalendarTime. After writing a few inflexible single purpose date parsing functions I decided that it would be easier to just write one that takes a formatting string. I have written a parseCalendarTime :: TimeLocale -> String -> String -> Maybe CalendarTime which accepts all format specifiers that formatCalendarTime accepts. It is far from perfect (19 FIXMEs last time I checked), but it should work for most common cases. The output is not neccessarily a valid date, as the date format used may not contain enough information, and no attempt is made to calculate or validate, for example, the day of the week or the number of days in a month. A CalendarTime is used here as a "slightly more tractable representation of a date/time string" [1]. The code is available at: http://www.dtek.chalmers.se/~d00bring/misc/ParseDate.hs The code is extremely untested. All comments, bug reports, flames and suggestions for improvement are welcome. /Bjorn Bringert [1] http://www.haskell.org/pipermail/haskell-cafe/2002-December/003758.html

1 0

request for HUnit in hierarchical libs?
by Malcolm Wallace 24 Mar '04

24 Mar '04

I'd like to make a request that the HUnit testing framework be converted to a 'package' in the hierarchical libraries, to make for easier installation and use. If it could be added to the fptools repository, and so be distributed with new releases of ghc, Hugs, and nhc98, so much the better, but a separate distribution would be fine as well. The current distribution appears to be two years old, so I'm guessing it is pretty stable. I know it has several keen users, and making it more readily accessible would be a good goal. As far as locating it in the hierarchy is concerned, I would suggest the following renaming plan: HUnit -> Test.HUnit HUnitBase -> Test.HUnit.Base HUnitLang -> Test.HUnit.Lang HUnitLang98 -> Test.HUnit.Lang98 HUnitLangExc -> Test.HUnit.LangExtended HUnitText -> Test.HUnit.Text Terminal -> Test.HUnit.Terminal The other modules in the current distribution are unit tests for the testing framework itself, so do not exactly belong in the hierarchy: HUnitTestBase HUnitTest98 HUnitTestExc TerminalTest I imagine they could simply be retained as tests, but not installed. The top-level of the 'Test' hierarchy does not currently exist, but HUnit looks like an ideal candidate to start it off. [ For folks on the libraries list, I would also like to recommend that the existing 'QuickCheck' package move from its current location in 'Debug.QuickCheck' to 'Test.QuickCheck', which is more descriptive of its actual use. ] Regards, Malcolm

1 0

More on version management...
by Graham Klyne 23 Mar '04

23 Mar '04

I took a look at the Subversion site [1], and see three features which appear to be quite compelling. [[ Features of Subversion * Most current CVS features. Subversion is meant to be a better CVS, so it has most of CVS's features. Generally, Subversion's interface to a particular feature is similar to CVS's, except where there's a compelling reason to do otherwise. * Directories, renames, and file meta-data are versioned. Lack of these features is one of the most common complaints against CVS. Subversion versions not only file contents and file existence, but also directories, copies, and renames. It also allows arbitrary metadata ("properties") to be versioned along with any file or directory, and provides a mechanism for versioning the `execute' permission flag on files. * Apache network server option, with WebDAV/DeltaV protocol. Subversion can use the HTTP-based WebDAV/DeltaV protocol for network communications, and the Apache web server to provide repository-side network service. This gives Subversion an advantage over CVS in interoperability, and provides various key features for free: authentication, path-based authorization, wire compression, and basic repository browsing. ]] I've recently realized that directory moving and renaming is a pain with CVS. I also think that support for an open standard protocol (WebDAV) is, in the longer term, a real win because it should mean greater client availability across different platforms. The choice of staying close to CVS except where there's a reason not to will hopefully ameliorate the learning-curve concerns. Just a datum. #g -- [1] http://subversion.tigris.org/ ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

8 8

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