May 2003 - Libraries - Haskell.org

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

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

29 May '03

> Shae Matijs Erisson owns the >haskell-libs< project at > sourceforge.net, and we figured this would be a good platform for the > effort. I just wanted to point out that there's some overlap between what you're doing in the haskell-libs project, and what's going on here on the libraries list. It's best not to duplicate effort if we can avoid it. > The idea is to set-up a CVS repository, which contains the > following directories: > > - hslibs > > Here do the actual source codes live, using a directory layout > complying to the hierarchical library structure, for example: > > - Text > - Data > - Foobar > > The contents is by-approval-only: We have a name registry for the hierarchy, and an (albeit informal) approval policy, here: http://www.haskell.org/~simonmar/libraries/libraries.html I don't quite understand the purpose of the hslibs libraries: are you providing a replacement set of libraries, or a complementary set? I believe it's important that there be one place which lists (a) which names in the hierarchy correspond to existing libraries, and (b) where to get an implementation of those libraries. > These libraries serve as a quasi-extension of the libraries shipped > with ghc/hugs/nhc98. Ideally, everybody would be able to use them > by just checking out this directory and adding it to the compiler's > search path. Just adding to the search path in GHC is unlikely to work - you really want to hook into the package system, and you'll need a build system of some kind. Cheers, Simon

3 2

RE: Haskell library infrastructure coordinator
by Simon Peyton-Jones 28 May '03

28 May '03

Peter | I wanted to write up a proposal regarding the organization of a | >central< library infrastructure for weeks Terrific! | ... So I guess now is the time to do or die. No, no, absolutely not! The idea is *not* that the coordinator goes into a corner and produces something that s/he imposes on the rest of us. The idea is that s/he asks for ideas, makes proposals, and moderates the process of melding those ideas into a design we can all support. Step 1 : identify coordinator Step 2 : propose designs, discuss, evolve consensus Step 3 : implement My message only concerned step 1. Yours is about step 2. Which is excellent, but it *isn't* do-or-die time for step 2. Simon

3 3

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

27 May '03

> There are currently four libraries in the snapshot: DSP, Matrix, Poly, > and Stat. I would like to add these to the official namespace, and > would like to know where they should live. Would you like to submit a proposal - or does the library snapshot you posted constitute a proposal? Would anyone else interested in DSPs care to comment on possible names for these libraries? In the current hierarchy design we have: Numeric DSP FastFourierTransform Noise Oscillator but given the size of your DSP library, perhaps moving it to the top level would be justified? The other question to ask is whether this is will be *the* DSP library, or whether there are other competing designs. If there are multiple designs, then the pattern we usually follow is to do something similar to the Text.PrettyPrint hierarchy, where we have Text.PrettyPrint.HughesPJ, Text.PrettyPrint.Wadler and so on. > Everything is GPL. I don't really care one way or another about this, > but there is some code that I don't claim copyright to, and > some derived > code that inherits the GPL. In particular, MT19932.hs and > Roots.hs have > different copyright holders, and the original code was GPL. FFT.hs, > FFTHard.hs, and PFA.hs have some derived code, so they have to inherit > the GPL. I have to consult with the author, but IIRCookbook.lhs is a > derived work, and I have a feeling that the license on this > will be PD. There is no problem with GPL code, but we must be careful with dependencies. Any code (library or otherwise) which depends on your library will potentially be required to be GPL'd too, so the license needs to be prominently displayed. Cheers, Simon

4 4

mkstemp in Haskell
by Martin Sjögren 27 May '03

27 May '03

Dear list. I needed a function for creating temporary files. Since I couldn't find one in the standard library, I just hacked one up using the ffi. It's in the haskell-libs cvs [1]. I've got an icky import of GHC.Handle to get openFd, any way I could get rid of it? (fdToHandle isn't enough) [1] http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/haskell-libs/libs… /Martin PS: I slapped an LGPL license on it, if that's a problem, it's negotiable. -- Martin Sjögren sjogren(a)debian.org -- marvin(a)dum.chalmers.se GPG key: http://www.mdstud.chalmers.se/~md9ms/gpg.html let hello = "hello" : hello in putStr (unlines hello)

4 6