- Libraries - Haskell.org

Re: cvs commit: fptools/libraries/base/Control/Monad/X Cont.hs ContT.hs Error.hs ErrorT.hs Fix.hs Identity.hs Monads.hs Nondet.hs NondetT.hs README Reader.hs ReaderT.hs Resume.hs ResumeT.hs State.hs StateT.hs Trans.hs Transformers.hs Types.hs Utils.hs ...
by Alastair Reid 04 Jun '03

04 Jun '03

On Tuesday 03 June 2003 11:26 pm, diatchki(a)glass.cse.ogi.edu wrote: > Added files: > libraries/base/Control/Monad/X Cont.hs [...] > Log: > Added a first version of the new monad library (experimental). > Hopefully one day the "X" will disappear. What's the policy on adding large directory trees of experimental code to existing libraries like base? Some obvious options: 1) Go right ahead - no need to mark it specially 2) Go right ahead but be sure to use an X prefix to warn people - we'll delete the X once it is finalized. 3) It'd be better to do the development in a separate library tree such as fptools/libraries/newmonads. a) And give it a name like Unsafe.Control.Monad.Cont b) And give it a name like Org.Diatchki.Control.Monad.Cont c) And give it a name like Control.Monad.Cont I lean towards either (1) or (3) and can't decide between 3a/b/c. (3) seems most in keeping with the push for a library infrastructure. -- Alastair Reid

1 0

RE: Soliciting comments on Edison
by Simon Marlow 04 Jun '03

04 Jun '03

> On Thu, May 29, 2003 at 01:25:10PM +0100, Ross Paterson wrote: > > > I'm not sure that the separate top-level name is justified. > > I'm not so sure about that either, but the hierarchy document had one > last time I looked. At the moment, Edison has its own top-level name in the hierarchy. This was intended to be a temporary measure - ultimately we want a comprehensive library of data structures under Data, but there was a feeling at the time that Edison is not The Right Thing. For my money, I'd be happy with something simpler. Cheers, Simon

2 1

Italian-crafted Rolex - only $65 - $140!! Free SHIPPING ! !
by tony2003＠yahoo.ca 03 Jun '03

03 Jun '03

1 0

Concerning Time.TimeDiff
by Graham Klyne 02 Jun '03

02 Jun '03

Following a brief off-list exchange, Simon Marlow suggested I post some notes here concerning Time.diffClockTimes and Time.TimeDiff. These arise from my thought that the current behaviour of the GHC library in (sometimes) returning a value with positive seconds and negative picoseconds values might be viewed as perverse. I'm trying to go beyond a "what is technically correct" viewpoint to "what is useful"... I understand there's some history here, of which I'm not properly aware, so if this is merely rehashing old ground, please ignore. ... What's useful here? In practice, I think one would want to be able to compare and display time intervals. Maybe the easiest form for doing this (for a multi-component value like TimeDiff) would be a sign+magnitude representation. But TimeDiff doesn't allow for that, so what other options? (a) all components except the most significant are positive, (b) all components the same sign Either of these allows component-wise comparison, from left to right. I think (a) is easiest to format. Of all the options, having the least-significant component negative and the rest positive really seems perverse, as I can't see how to compare or format the value without examining all of the fields before I start. BTW, I'm also dubious about the desirability of including months and years in a time-difference value, because of the variability of months; whenever I've implemented this kind of thing in the past, I use days/hours/mins/secs/sub-secs to measure intervals (though even this is debatable). ... I think it would be helpful if the Haskell Report documentation of diffClockTimes [1] were a little more specific, to the point of stating which way round the subtraction is performed, and also would say something about how negative time-differences should be returned. [1] http://www.haskell.org/onlinereport/time.html: Currently says: [[ Function getClockTime returns the current time in its internal representation. The expression addToClockTime d t adds a time difference d and a clock time t to yield a new clock time. The difference d may be either positive or negative. The expression diffClockTimes t1 t2 returns the difference between two clock times t1 and t2 as a TimeDiff. ]] ... Time representation is something that is difficult to get absolutely right for all purposes, so if the overall design is up for reconsideration I think it's important to have some idea of the intended scope of use. (Pat Hayes summarized some work on the complexity of these issues to a Semantic Web calendaring meeting [2][3].) [2] http://ilrt.org/discovery/chatlogs/rdfig/2002-10-09.html#T11-46-06 [3] http://www.coginst.uwf.edu/~phayes/research.html #g ------------------- Graham Klyne <GK(a)NineByNine.org> PGP: 0FAA 69FF C083 000B A2E9 A131 01B9 1C7A DBCA CB5E

1 0

RE: hirarchical modules
by Simon Marlow 30 May '03

30 May '03

Iavor Diatchki writes: > hmm... what should i do? implement 50 libraries using the > broken system just to illustrate that it is broken? Complaining doesn't achieve anything. May I suggest that proposing a solution, getting agreement from folks on this list, writing it up and implementing it are much more productive things to be doing. It's about time we had a proper Haskell 98 addendum for the hierarchical module extension: I'll split out what's in the current document into an addendum later today, and put it in CVS along with the FFI addendum so we have somewhere to record the outcome of the dicussion. Now, there are two separate issues here. 1) Relative imports. I don't see any problem with this at all, beyond choosing a syntax. 2) Not specifying the full module name in the module source. Several people have asked for (2), but the reason we have held off so far is because it makes a fundamental change to the language, namely that The meaning of a module would not be completely specified by its source code. The current design has this rather nice property, and it means the Haskell Report can avoid talking about filesystems or any other way to specify the full module name for a module. I'm sure this argument came up recently on the libraries list, so I won't say any more about it now. That's not to say it isn't possible to find a solution, but we should bear in mind this property before adopting any design that requires the filesystem to play a part in specifying the name of a module. Cheers, Simon

2 2

Italian-crafted Rolex - only $65 - $140!! Free SHIPPING ! !
by tony2003＠yahoo.ca 30 May '03

30 May '03

1 0

RE: Name allocation
by Simon Marlow 30 May '03

30 May '03

> Simon Marlow writes: > > > The only way (currently) to have such a guarantee is to use > > User.To.Cryp.Simons as the root of your library tree. > > Does this really guarantee uniqueness? > > What if I don't own a domain name personally? What if I give up > my domain and somebody else buys it? True. > What if somebody doesn't > know of this convention and simply uses this exact name because > he likes it? Then libraries distributed without following the convention risk colliding with other libraries on the system, and modules in a program. > As far as I can tell, you cannot guarantee unique names at all if > your name space system has an absolute root -- like Haskell does. > Whatever you come up with may potentially clash with someone > else's name -- and probably will. :-) > > The only way to guarantee unique names -- without requiring > people to abide to some "arbitrary" convention -- is the module > names to be relative. If I import a module "Foo.Bar", and I am > "Peter.Simons.ToolXY", then this module will be > "Peter.Simons.Foo.Bar" for me. In such a system I can uniquely > access any module, no matter how it's called. There's a technical problem with this: when we compile a module we bake its module name into the symbols exported by the object code. So this approach would work fine for distributing source code, but not for binaries. One other approach is to do it the Microsoft way and give all libraries GUIDs, with the rule that you have to change the GUID when you change the library API. This would guarantee no library clashes, because a module name would include its GUID. Hmm, this might be a good idea. Suppose in GHC we give each package a GUID. You import a module by giving the package GUID and the module name. Certain packages are designated as "standard" so that you don't have to specify the GUID (eg. the Prelude and standard libraries). This way you could have multiple versions of a package installed, and GHC could provide backwards-compatibility packages so that programs written for previous versions of the libraries continue to work. Thoughts? Would this be too ugly? Cheers, Simon

4 5

RE: Name allocation
by Simon Marlow 30 May '03

30 May '03

> > One other approach is to do it the Microsoft way and give all > > libraries GUIDs, with the rule that you have to change the GUID > > when you change the library API. This would guarantee no library > > clashes, because a module name would include its GUID. > > I know next to nothing about this GUID concept, so please correct me > if I'm wrong, but isn't this GUID just "yet another unique identifier > convention", which may or may not clash, depending on how lucky you > are? Would using a GUID really be different than using a hierarchy > like Haskell does today? Yes, technically this is true. But the important feature of a GUID is that you can generate a guaranteed unique one locally, without having to check a global registry to avoid clashing. Cheers, Simon

1 0

hirarchical modules
by Iavor Diatchki 30 May '03

30 May '03

hello, i was wondering how final is the design of the hirarchical module system for haskell? i have been working on the monad library for the past week or so and this is my first experience with the hirarchical module system in a real project. i must say that i find it very cumbersome. here is why: the whole monadic library is in the same directory, but since there is no way to use relative names, all the imports use the rather long fully qualified name. things like: import Control.Monad.X.ReaderT are very common. and if the hirarchy gets deeper, names will get longer. while the verbosilty is annoying there is a more serious problem. moving code around is very work intensive (and error prone). for example, when i decide that what i have is stable enough i'd like to move it to the Control.Monad part of the library (i.e. get rid of the X). that means that i have to go and change all the imports, and all the module names. of course i have a haskell lexer at my disposition so i have a little program to do that for me, but that solution seems very unsatisfactory. and there seems to be a rather obvious solution to this problem: 1. allow for imports relative to the location of the importing module 2. remove the requirement that the path to a module is hardcoded in the module name. i am now hoping that someone will say: yes we already tought of that and it is indeed supported... any thoughts? bye iavor

6 7

Imperative data structures
by Lauri Alanko 30 May '03

30 May '03

In GHC 6.0 there is a new data structure, Data.HashTable. Why is it based on the IO monad instead of ST? I really think it should be a general policy that imperative data structures be based on the ST monad so they can be used for implementing observably pure functions. There's always stToIO for when one really wants to do stuff in the IO monad. Lauri Alanko la(a)iki.fi

2 1