- Libraries - Haskell.org

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

Library reviewing (was: RE: Haskell library infrastructure coordinator)
by Simon Marlow 29 May '03

29 May '03

Peter Simons writes: > My idea was that a library was to be discussed ("reviewed") on this > list before it was included in the stable repository, so that > duplication of code can be avoided. Peer reviewing of libraries is a good idea, and I'd like to see us doing more of that for the libraries in general. I think I'm proposing that if there's a review process, that it be adopted consistently rather than just for the haskell-libs project. Would you (Peter, or anyone else) like to put together a proposal for how this might work? Something that can be included in the library document would be ideal. Cheers, Simon

2 1

RE: Haskell library infrastructure coordinator
by Simon Marlow 29 May '03

29 May '03

> > There should probably be test suites to cover dependencies to ensure > > that all libraries are adequately in sync -- I'm not sure how easy > > this is to do in practice. > > Hmmm. > It's best done as the library is being written because it > could actually help > development and because the author likely has a better idea of what a > function is supposed to do. But test suites are usually > ignored or built > long after the fact. Since quickcheck is quite easy to use, > I wonder what's > missing? Is it infrastructure (a handy driver program and > some make targets) > or some well-worked examples to cut and paste from? Where do > I find examples > of how to quickly add quickcheck to my library? May I plug the GHC testsuite framework here? It's about 1k lines of Python (Makefiles are optional), copes with running tests multiple ways, has concepts of "expected failures" and "unexpected passes", and it generates a nice summary output at the end. It's quite configurable too. Take a look at fptools/testsuite/README in the GHC CVS tree. Cheers, Simon

1 0

RE: Soliciting Comments on DSP Library
by Simon Marlow 29 May '03

29 May '03

Matthew Donadio writes: > Since it's populated, I think my current snapshot is a proposal. Then I'm happy for your library to be the reference for the DSP hierarchy. Unless there are any objections, I'll add that to the list. > Perhaps nodes in the hierarchy should have a Pending for > modules/libraries that are needed and should have a standard interface, > but don't yet. The caveat would be that users should not use the > X.Y.Z.Pending functions directly. So, I would have > > DSP > Pending > Stat > Poly > Matrix It's better to go straight for the final names, rather than have to move modules around in the hierarchy at a later date. The interface can always be marked 'experimental' if it is likely to change. > It may make sense for the FFT library to live outside the DSP tree. > Among DSP practitioners, the terms "FFT" and "DFT" are used almost > interchangeably, but DFT is probably a better name. A proper solution > could be > Numeric > Transform > DFT -- Discrete Fourier Transform > DCT -- Discrete Cosine Transform > DST -- Discrete Sine Transform > DHT -- Discrete Hartley Transform > ... > > Long names could be better to avoid confusion (there are several > transforms that begin with H). I'd go with the longer names. Numeric Transform Fourier Cosine ... 'DiscreteTranform' is a bit of a mouthful, so I'd go with just 'Tranform'. Malcolm Wallace writes: > > The Stat library could really live anywhere. It only > contains functions > > for mean, median, variance, and std. dev. > > I suggest the fuller name 'Statistics', and indeed it does not belong > under DSP. Possibly under Numeric, but maybe at the top level? Agreed. The choice about whether to put Statistics at the top level or not depends on whether it is likely to evolve into a deep hierarchy itself; if not, then Numeric.Statistics should be fine. > > Numeric > > Random > > Generators -- MT19937, DRAND48, ... > > PDF -- Uniform, Normal, Poisson, Rayleigh, ... > > Spectral? -- White, Pink, Red, ... > > PDF = Adobe Portable Document Format? No? Then what? My guess is > Psomething Distribution Function, so how about > Numeric.Random.Distribution? On the subject of acronyms, they don't necessarily have to be unambiguous on their own as long as the meaning is clear from the context. That is, while PDF on its own is ambiguous, Numeric.Random.PDF might not be. In this case there might be better names though - Numeric.Random.Distribution sounds good to me. Cheers, Simon

4 3

Haskell lib for libpcap
by ptucker 29 May '03

29 May '03

Hi all, I am interested in finding a library or some code in Haskell that can parse network packets from a network trace dump file generated by tcpdump (libpcap). Is anyone aware of such a library? Thanks for your help. -- Pete Tucker (503) 748-4057 http://www.cse.ogi.edu/~ptucker

3 2