- Libraries - Haskell.org

RE: Heirarchical name space allocation
by Simon Marlow 30 Mar '04

30 Mar '04

> Have you given any thought to adding some security to go along with > library versioning? I'm thinking of something like the C# > repository, > where the version of the library you compile against has a digital > signature, and the signature is embedded in the app. The point is to > prevent an attack where someone substitutes another library, with the > same version information and public interface, and hijacks your code. I haven't thought about it, but my guess is that in the absence of any other security infrastructure it wouldn't be of much use. Could you outline some scenarios in which you think this would be helpful? Cheers, Simon

1 0

Heirarchical name space allocation
by Adrian Hey 30 Mar '04

30 Mar '04

Hello, Who's in charge of allocating names in the hierarchical modules for publicly released libraries these days? This page lists (some) allocated names.. http://www.haskell.org/~simonmar/libraries/layout.html But I can think of a few that aren't listed there. What's the policy? Is there a master reference or register somewhere? Regards -- Adrian Hey

1 0

Bug in the proof of Data.FiniteMap and DData.Map
by Robert Will 29 Mar '04

29 Mar '04

hi, both of the data structures are based on Adams' balancing algorithm which contains a bug -- at least in its proof. (Perhaps it is correct, but I don't know anyone that knows if.) Instead of fixing the bug I have re-derived the algorithm from the invariant together with a (now hopefully correct) proof. The new algorithm is contained in Dessy: http://www.stud.tu-ilmenau.de/~robertw/dessy/fun/ more specifically in the file: http://www.stud.tu-ilmenau.de/~robertw/dessy/fun/WeightedTrees.hs The derivation, proof (and hint to Adam's bug) are in: http://www.stud.tu-ilmenau.de/~robertw/dessy/fun/democratic/sequence.hs (The so-called hedge-union, -intersection, and -difference is also implemented: function 'x_merge_width' does all three: http://www.stud.tu-ilmenau.de/~robertw/dessy/fun/Dessy.hs ) A paper which presents the new (much simpler) algorithm and its proof putting it in scientific context is in preparation. Users that prefer proven algorithms over tested ones are free to use my implementation instead of the existing ones. (At moment, there is no proven and tested implementation. Of course this will change soon.) As for the maintenance of Data.FiniteMap and DData.Map, I don't know whether it is worth "fixing" the implementations or one would better replace them by a completely new design. Anyway, algorithms have no copyright and everyone is free to use the new "weight-balancer according to Will" to implement his own data structures. Oh, by the way, some of the other balancers in Dessy (or DData) might be more efficient than weight-based balancing anyway, I'll make some measurements later this year. good time, Bob

4 6

Patch for System.Console.GetOpt to align multi-line option descriptions
by Martin Sjögren 27 Mar '04

27 Mar '04

As the subject says, the attached patch will align multi-line option descriptions. I find this very useful since I typically write long option descriptions and having too long lines and having descriptions that muddle up the option columns suck equally bad in my opinion. I hope others find it useful too. Cheers, Martin Sjögren

2 1

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