April 2004 - Libraries

System.Locale is broken?
by David Roundy 07 Apr '04

07 Apr '04

System.Locale.defaultTimeLocale, which appears to be taken directly from the Haskell report, is hard-coded to american english settings... which seems to defeat the purpose of the module. Are there plans to provide the actual locale? I have users who would like to have their times formatted according to their own locale. I'd rather not have to do this using the FFI to access the C library. :( -- David Roundy http://www.abridgegame.org

1 0

RE: #ifdef considered harmful
by Simon Peyton-Jones 07 Apr '04

07 Apr '04

I have not been following the details of this thread, but let me urge caution. Cpp is used in mostly-trivial ways to deal with the fact that a single blob of source code is being fed into several different compilers. The fact that cpp is not perfect for this use is not a reason to design something new. cpp is readily available everywhere, whereas some new tool would not be. It certainly seems overkill to design a whole new pre-processor system! (Mind you, doing so might be an interesting exercise in its own right -- Template Haskell is such an experiment -- but the need here is for a solution, not a research programme.) I agree with Johannes: (a) keep it simple, (b) integrate with compilers. (a) argues for cpp. As to (b) is there some reason that Hugs cannot simply run cpp? Simon | -----Original Message----- | From: libraries-bounces(a)haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Johannes | Waldmann | Sent: 07 April 2004 07:43 | To: Alastair Reid | Cc: libraries(a)haskell.org | Subject: Re: #ifdef considered harmful | | Alastair Reid wrote: | | > So, I'd like to float the idea that the Haskell preprocessor should _only_ | > support conditional compilation, that macro expansion should only occur in | > lines that begin with '#' not in "normal" lines and that macros should always | > evaluate to expressions with simple scalar types (ints, strings, etc.) | | > [It's probably simple enough that the preprocessor could | > easily be built into Hugs if we wanted. This isn't the primary | > motivation for this suggestion but it would be nice.] | | I'd vote for that (as a user). If we absolutely need preprocessing, | then the above looks like a very reasonable way to go: | 1. keep it simple, 2. integrate it with compilers. | | best regards, | -- | -- Johannes Waldmann, Tel/Fax: (0341) 3076 6479 / 6480 -- | ------ http://www.imn.htwk-leipzig.de/~waldmann/ --------- | | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries

2 1

sequences
by ross＠soi.city.ac.uk 07 Apr '04

07 Apr '04

I've been arguing that sequences should be treated differently from other data structures, since they can be handled by a Haskell 98 class, and they exhibit greater variety, so the class is more useful. One way to get there is to take Edison, remove the module-based overloading and add default definitions to the class. I don't think default definitions are quite as useless as Chris suggests: often there is a most common default; in some other cases there is a choice, but you have a family of methods that will all decide the same way, so you can delegate to one member of the family. And defaults make it easier to get started with a new instance. To have something concrete to discuss, I've placed a structure based on Edison at docs: http://www.soi.city.ac.uk/~ross/seq/ code: http://www.soi.city.ac.uk/~ross/seq.tar.gz

3 3

Ord instance for TypeRep?
by dpt＠lotus.bostoncoop.net 06 Apr '04

06 Apr '04

I'm not sure this is the right place to make this request, but could an instance of 'Ord TypeRep' please be added? I'd like to store dynamically typed elements in a FiniteMap. Peace, Dylan

1 0

Re: DData
by Johannes Waldmann FbIMN 05 Apr '04

05 Apr '04

BTW, what does the first "D" in DData stand for? Perhaps "Daan"? I don't like concatenated module names ("D" ++ "Data"). We have hierarchical names to avoid exactly that. It should then perhaps be Data.Daan, similar to module Text.PrettyPrint.HughesPJ -- -- Johannes Waldmann, Tel/Fax: (0341) 3076 6479 / 6480 -- ------ http://www.imn.htwk-leipzig.de/~waldmann/ ---------

1 0

Re: Heirarchical name space allocation /Trees
by Okasaki, C. DR EECS 02 Apr '04

02 Apr '04

> Who doesn't get at least a bit uneasy when looking at all the redundancy, > in e.g. Edison's code? Okasaki has written some generic functions, but > they have to be renamed manually in each module. All for the sake of > efficiency! Bertrand Meyer did not propose to handle this via inheritance > without ensuring that the compiler would eliminate all the indirections. > And that was in 1985! I may be misunderstanding what you are saying here, but I think you are complaining that Edison has a lot of redundancy because it doesn't use default definitions. And I think you are attributing that avoidance of default definitions to a concern about avoiding indirections. But indirections and "efficiency" (in the sense I think you mean) have nothing to do with it! The redundancy you are referring to comes from two sources. First is the desire for Edison to support *both* the class-based style and the module-based style of accessing the data structures. As other posts in this thread have shown, both styles have their strong supporters, and I didn't see any reason that the library should dictate one style over the other. Because the module-based style doesn't support inheritance, you have to put in explicit definitions for every operation, even if many of those definitions are one-liners that refer to generic functions. The second source of redundancy is that default definitions are largely useless for this kind of library. The problem is that there is rarely *one* generic function that makes sense as the default. Instead, there are often two or three or more functions that are all equally good candidates to be the default. So which one do you choose? If there is one that is appropriate, say, 80% of the time, then sure go ahead and make that one the default. But if there are three, and each is appropriate about 33% of the time, then I think it is more clear not to have a default, and have every implementation state explicitly which of the "defaults" it is using. -- Chris

1 0

RE: State of DData
by Simon Marlow 02 Apr '04

02 Apr '04

> > Arguably then, anything which is an instance of Monad > should be a monad. > > I would certainly argue strongly for that. > > If it ain't true, then small, irrelevant changes in a piece > of code could > break. For example, is it safe to make this change: > > do > f y > ==> > do > x <- f y > return x > > I'd hope it would be. (And the change might be useful if I > want to insert a check or a debugging printf in the code.) I'm afraid it isn't true that all instances of Monad respect the monad laws, due to our old friend seq. See: http://www.haskell.org/pipermail/haskell/2002-May/009622.html I don't want this discussion to get out of hand. The only point I'm making here is that the Haskell definition doesn't *require* that every instance of (==) be equality, in the same way that it doesn't *require* that all Monad instances are monads, and all '+'s are additions etc. Libraries might rely on properties of these methods, but as far as is practical those assumptions should be documented. Cheers, Simon

4 3

RE: Heirarchical name space allocation
by Graham Klyne 02 Apr '04

02 Apr '04

At 10:19 30/03/04 +0100, Simon Marlow wrote: > > > 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? > >At one stage we thought that having a single global registry for names >was the way to go. Now I think that a free-for-all, with good package >management tools, is probably better. > >Names and hierarchy locations will still be discussed on this list, but >anyone is free to publish a library using any names in the hierarchy >they please. If there is overlap, then the compiler should prevent you >from using two overlapping packages at the same time. In fact, there's >one good reason for allowing overlap: versioning of libraries. > >Of course, if your library uses names that are consistent with the >general policy, then there's a greater chance that your library will be >included in future "collections" of libraries, bundled with compilers, >and so on. The idea is that community self-organisation replaces strict >central registration of library names. I think this is an improvement, >but perhaps it's a cop out. What do others think? I like it. It might be appropriate for designers to document module names they use in the wiki? #g -- PS: the "provisional registry" of "Registration procedures for message header fields" [1] is almost a similar free-for-all. The general idea is to give developers a pretty free hand in choosing names, but provide a common listing for the purposes of coordinating activities. [1] http://www.ietf.org/internet-drafts/draft-klyne-msghdr-registry-07.txt ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

RE: Heirarchical name space allocation /Trees
by Simon Peyton-Jones 02 Apr '04

02 Apr '04

| specific optimisations). Of course anyone may disagree. (Btw, | documenting all the really innovative stuff in official publications will | take some time, so if you want to wait...). Robert, let me encourage you to do this writing. Debates on the Haskell libraries list have a narrow audience; a paper has a far wider audience. Furthermore, the process of writing a paper often has an incredibly beneficial effect on the ideas being described. And the paper will still be read long after the implementations it describes have turned to dust -- papers infect people's brains which is the most powerful form of software propagation of all. The Haskell workshop might be a good venue. Simon

1 0