March 2004 - Libraries

Subprocesses (was: [ANNOUNCE] shell-haskell 1.0.0)
by Simon Marlow 08 Jul '04

08 Jul '04

Libraries people, There are currently two ways to create and communicate with external processes: - System.Cmd.system (very basic, doesn't give you access to the process's output but you can use shell primitives to redirect its input/output). - Posix.runProcess (can specify Handles for the process's input/output, but it doesn't create pipes so you can't actually communicate with the subprocess using these Handles.). - POpen.popen (can specify an input String, and gives you lazy output Strings. No interactive communication is possible.) Ok, *three* ways. System.Cmd.system, Posix.runProcess, POpen.popen, and shell-haskell. Er. *Four* ways. David Sankel's shell-haskell creates pipes for stdin/stdout/stderr, and lets you communicate interactively with the sub-process via Handles. It could do with a way to specify the environment and working directory of the sub-process (ala POpen and runProcess), but apart from that it seems to be the most flexible of the four. It could be simplified slightly by using one Handle rather than two for stdin/stdout. We should think about what functionality we want to provide in the core libraries. My preference would be to go for a full version with three pipes (like shell-haskell) and perhaps one or two more specialised versions covering common cases (I don't know what these should be, though). What do people think? Cheers, Simon -----Original Message----- From: haskell-admin(a)haskell.org [mailto:haskell-admin@haskell.org] On Behalf Of David Sankel Sent: 06 May 2003 03:06 To: haskell(a)haskell.org Subject: [ANNOUNCE] shell-haskell 1.0.0 =================== shell-haskell 1.0.0 =================== shell-haskell provides utilities to communicate with other process's via Haskell code. This library can be used for something as simple as getting the output of another program or as complex as interacting with an interpreter. see http://www.electronconsulting.com/shell-haskell for details. David J. Sankel _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell

5 10

Proposal for a Standard of Abstract Collections (with Reference Implementation)
by Robert Will 15 Apr '04

15 Apr '04

hi all, Curiously I have finished the promised draft standard for the Abstract Collections just by a time, where many are busily working on DData. It's there: http://www.stud.tu-ilmenau.de/~robertw/dessy/fun/ I'm making this discussion hot now, since my Dessy library implements the proposed collection standard and features all of the concrete structures that are also in DData, and some more, especially Deques and Democratic Sequences (explanation: http://www.stud.tu-ilmenau.de/~robertw/dessy/fun/democratic/ ). But I also want to have your attention for another aspect of the problem: the introduction of abstract data structures makes the programming language much more useful and suggests some generalisations of the manifest syntax. Thus my proposal does not only contain - a formal specification for a collection hierarchy (based on Abstract Algebraic Data Structures (TM)), but also - generalisations of all the standard functions from Prelude and Data.List, and - a formal specification of Haskell extensions, that make abstract structures as easy to use as lists -- but with much more flexibility. Incidentally the current discussion around DData already shows signs of what I predict in the standard's rationale: when concrete data structures are extended to become more general, the number of functions increases so fast, that a general standard isn't more complicated any more, but simpler actually. For example, you discussed whether Sets and Maps should be converted from and to Sequences or the built-in "lists". Well, the best answer is to convert from and two an type classes of which "lists" (if one uses them at all) are an instance. Exactly this is done by the function "convert" proposed in the standard: > convert :: (Collection coll a, Collection coll' a) => > coll a -> coll' a > convert = fold empty single (<+>) (The function can be specialised in the same way as 'fromIntegral' on the numeric types, so we don't loose efficiency.) Abstraction is more: the proposed standard helps to use a lot of different data structure implementations together, using one interface that has been designed with the user first in mind, not the implementation. But this abstraction also allows an entirely new programming style, that is especially useful when TEACHING programming. Data Structures are deeply intertwined with programming as such, that the proposed standard gives Haskell something that NO other language does have today. (Perhaps Eiffel comes closest, but EiffelBase is not standardised.) (Remind me to write "A Gentle Introduction into Haskell with Abstract Collections".) It has been mentioned that an advantage is of functional programming is the ability to easily _compose_ programs. But for this composition data structures are neccessary, without a standard for data structures functional languages loose one of their biggest advantages. In specifications Sets are the most important data structure, but in Haskell today, the so-called "lists" are the linguaga franca and that reminds me too much of the stacks in Forth (remember "lists" are actually functional stacks) or dynamic arrays in imperative languages: it's universal, but unflexible. (I'll have to write a paper on "Liberating programming from the McCarthy-style".) Since "a standard of Abstract Collections" has already been mentioned by some, I expect that there are high expectations regarding my proposal, and perhaps its many disadvantages (all the big ones mentioned in the documentation) will discourage the reader. On the other hand, there are so many advantages that one can hardly neglect that something big is going on. So the least thing that someone interested in the future of (functional) programming should is to download and try out the Collections, or to read a little bit in the design documents. Things to do: - Build examples for the use of the new Collections. (From now on anyone can port his code to get rid of "lists".) - Develop the Haskell Documentation Standard and apply it to Collections. (Specifications are exported and used for Tests.) - Using those specifications make a complete test framework. (Complete meaning every function is tested with the complete specification, so no Bugs can persist.) Given all that, it is trivial to add more implementations of the Abstract Collections. (Just added two concrete structures Yesterday, although Dessy has already much more functionality than DData, but only half its code size. (Or one third if you don't count the type classes and specifications.) I also think that Dessy has more readable code, but I don't know how important that is for anyone.) Have a good time, Bob

9 21

RE: Heirarchical name space allocation
by Simon Marlow 15 Apr '04

15 Apr '04

> On Tuesday 30 Mar 2004 10:19 am, Simon Marlow wrote: > > 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 think there should be some concensus about the overall > structure of the > hierarchy, and that should be documented somewhere (so > developers don't go > and reinvent their own slightly different names for concepts which are > already covered). Perhaps it would suffice to just do this for the top > level classifications. > > In my case I have a pretty complete binding to SDL which I > was thinking > of tidying up and releasing for other Haskellers. I call it HSDL :-) > > But should it go in the Graphics Heirarchy, if so where? > Graphics.HSDL? > SDL also covers other functionality (like audio) so I was > thinking of calling > it Multimedia.HSDL, but at present there's no Multimedia top > level AFAIK (but > then how would I know anyway?). Perhaps someone's already > using Multi_Media > instead? Or maybe my binding isn't necessarily unique, so perhaps > Multimedia.SDL.HSDL? SDL also has quite few bolt on extras too which > other people might write bindings for. There's a kind of "design document" for the hierarchy, which is currently in CVS: fptools/libraries/doc/lib-hierarchy.html. It's also here: http://www.haskell.org/~simonmar/lib-hierarchy.html As we agree on locations for libraries on this list, I've been putting them in the document. Not all the libraries exist yet - this is just a place to put the design of the hierarchy. Multimedia.SDL sounds ok to me. Cheers, Simon

10 31

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 Simon Marlow 31 Mar '04

31 Mar '04

> 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? Cheers, Simon

4 3

RE: State of DData
by Simon Marlow 31 Mar '04

31 Mar '04

> > > 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. > > If the Report calles (==) an equality method then (==) should > implement equality for every Eq instance. Arguably then, anything which is an instance of Monad should be a monad. And '+' should be addition. etc. etc. Haskell doesn't require any of these to be true, and similarly it doesn't require that every instance of '==' is equality. Cheers, Simon

4 3

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