May 2003 - Libraries - Haskell.org

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

Soliciting comments on Edison
by Andrew J Bromage 16 Jun '03

16 Jun '03

G'day all. As some of you know, I'm hacking up Edison. I'd like some suggestions on namespace issues. Note that at the moment, "Edison" has its own top-level name in the libraries document, and I'm happy for things to stay that way for now. First, an overview. Edison is a library of data structures, based around three main concepts: - A Sequence is any container where order is maintained (e.g. stacks, queues, deques, lists etc). - A Collection is a container where order is not maintained, or rather, is maintained by constraints on the ADT (e.g. sets, bags, priority queues etc). - An Association is a container which maps some key type to some data type (e.g. search trees, hash tables etc). The main feature of Edison which distinguishes it from other data structure libraries is that you do not choose data structures by the set of operations which you can perform on them because, for example, all Sequences support the same set of operations. Instead, you pick your data structure by implementation, and live with the fact that some operations are going to be slow on some implementations (e.g. snoc on simple lists is O(n)). Clearly, this is suboptimal. From a programmer's perspective, I shouldn't have to remember the difference between a BinaryRandList and a JoinList. Hence, I have started to implement what I call "facade" types, which wrap underlying implementations to give them names which better reflect what they are used for. Rather than use an Edison.ListSeq, you use an Edison.Stack and use meaningful operations like push and pop rather than cons and tail. I also want to support concurrently accessible data structures, embedded in the IO monad, which will probably be implemented as wrapper functions on top of channels or ports. So now there are three kinds of ways to look at a data structure: - As a concrete implementation - As a facade, exposing those operations that it is optimised for - As a concurrently accessible abstraction The simplest namespace would be something like this: Edison -- Top-level modules may include: Prelude Sequence Collection Association Facade -- Need a better name Stack Queue Deque FiniteMap FiniteTrie Concurrent Stack Queue Deque FiniteMap FiniteTrie Impl Sequence BraunSeq MyersStack Collection SplayHeap BalancedSet BalancedBag Assoc PatriciaLoMap Another option is to dump everything in "Facade" into the top level, but presumably that would require everything in Concurrent to be in the top level too which seems to pollute the top-level namespace a bit too much. Thoughts? Cheers, Andrew Bromage

3 3

monad transformer library (was: Re: list monad transformer)
by Iavor Diatchki 14 Jun '03

14 Jun '03

hello, (appologies for the long post) Andrew J Bromage wrote: > G'day. > > On Mon, May 19, 2003 at 05:15:30PM -0700, Iavor Diatchki wrote: >>i >>think the main probelm with adding transformers to the library is that >>the amount of code grows quadratically in the number of transformers >>(as one has to specify how each one interacts with every other one). > > > I personally think that there is too much of that in the existing > library. Consider, for example, the declarations at the end of > Control.Monad.State: > > instance (MonadState s m) => MonadState s (ReaderT r m) where > get = lift get > put = lift . put > > instance (Monoid w, MonadState s m) => MonadState s (WriterT w m) where > get = lift get > put = lift . put > > IMO, this is a misfeature. As a maintainer, working out what > instances are correct is a hassle and, as you note, leads to quadratic > code complexity in the worst case. As a user, I know what monad > transformers I have stacked on top of each other and I know where to > find the "lift" function. actually i disagree with this quite strongly :-) ideally i want no lifts in my program. things like: lift $ lift $ lift $ raise "error" are, well, annoying. also if i have a state and an environment (Reader they call it in the library) i can decide to switch them around as they do not inetract with each other. now all the lifts need to be changed. and besides if one has 1 of each transformer the whole "lift" thing is pointless as there is no ambiguity as to what you mean (i.e. put clearly refers to the state transformer wherevr it is). when there is more than one copy of a transformer things are different. then some sort of addressing is necessary, which is what motivated adding the "indexes" to my library. they work quite well, but i still think there must be a better way to achieve the same effect... as for maintenance, for a number of methods (i.e. ones where computions do not appear as arguments) there are standard ways of lifting. for example, what i've been using lately (don't remember if it is on my website) is: get' = lift get and then all instances for get use get' unfortunatelly i can't quite capture this commonality with a single instance. perhaps (as bellow) overlapping instances (in some form) could help. > The one exception is liftIO, which is very useful because if IO is > anywhere in your stack of monad transformers, it must be at the > bottom. I think there's also an argument for liftST. actually the library can be generalized there. in my library i have a class: class (Monad m, Monad n) => HasBase m n | m -> n where inBase :: n a -> m a for each monad transformer there is an instance: instance HasBase m n => HasBase (t m) n inBase = lift . inBase for every base monad (i.e. one not made out of transformers) there is an instance: instance HasBase m m where inBase = id we can cut down the number of instances if overlapping intsnaces are used, but it is not quite clear (at least to me) how they interact with functional dependencies. using this calss you don't need liftIO and liftST, and liftId, and liftFudgets, etc... bye iavor

4 6

Haskell library infrastructure coordinator
by Simon Peyton-Jones 10 Jun '03

10 Jun '03

Gentle Haskell librarians It is common ground that "better libraries" is perhaps the single thing that would boost Haskell most; and that the best way to better libraries is the bazaar model, not the cathedral. There has therefore been quite a lot of discussion recently on this list about a) What does Joe Haskell Programmer have to do to build and distribute a Haskell library, so that it is easy for users to install and use? b) What infrastructure exists to ease Joe's task, especially building distributions, perhaps for for multiple platforms and multiple Haskell compilers? Lots of suggestions emerged, and lots of people have knowledge and willingness to help. What we need, though, is someone to coordinate this group. It's difficult to reach technical agreement in a distributed group without one person who is willing to * Make proposals * Moderate discussion * Be open minded; not impose his/her own views * Drive discussion towards taking decisions * Document the consensus * Probably implement some core infrastructure, or at least coordinate the efforts of others to do so * Restrain ambition: something modest that works is better than something aspirational that doesn't Simon Marlow and I would like to propose Isaac Jones for this coordination role. He is knowledgeable, open minded, and not connected with any particular Haskell implementation. Most important of all, he is willing! (Very much not to be taken for granted -- it's a big job.) You should know him from his postings to this list. Is that acceptable to everyone? Does anyone want to propose anyone else (check they are willing first), or themselves? A huge thank-you to Isaac. Haskell only works because people contribute to it. Simon and Simon

9 20

ANNOUNCE: HaXml-1.09
by Malcolm Wallace 09 Jun '03

09 Jun '03

HaXml-1.09 ---------- We announce a refresh release of the HaXml toolkit for manipulating XML documents from Haskell. There are no major new features here, just a bunch of bugfixes, and a few incremental changes in the API. * ghc-6.0 is supported. * hmake is no longer required to build HaXml, provided you have ghc --make. * A new combinator 'path' has been added to Text.XML.HaXml.Combinators, allowing queries to be expressed in the style of XPath. * Some of the signatures in Text.XML.HaXml.Xml2Haskell have changed, in particular, there are new functions readXml and showXml that convert to/from Strings, hGetXml and hPutXml that use file Handles, and the old functions that use filenames are renamed to fReadXml and fWriteXml. * DtdToHaskell previously generated incorrect code for reading an XML element given the following DTD fragment: <!ELEMENT foo (a,b)+ > * The parser had a fault when reading conditional sections nested inside an IGNORE section in a DTD. * In Text.XML.HaXml.Html.Generate, all functions now generate HTML tags in lower-case rather than upper-case, to conform to the XHTML standard. * DtdToHaskell now accepts NOTATION types for attributes. They are treated just like enumeration types. * If you give an output filename as a command-line argument to DtdToHaskell, it now uses the filename as the basis for the generated module name. * Fixed a configuration bug on the Cygwin platform with ghc-5.04.x. * make install now places the executables (DtdToHaskell, Xtract, Validate, MkOneOf, Canonicalise) into the directory specified by ./configure --prefix=... Regards, Malcolm

2 3

Name allocation (was: RE: Haskell library infrastructure coordinator)
by Simon Marlow 04 Jun '03

04 Jun '03

Peter Simons writes: > I'd like to have complementary libraries in there. For instance: I > have written a set of QuickCheck combinators, which can be used to > generate random expressions to test parsers. If this were to be added > to "hslibs", it would probably go to "Debug.QuickCheck.Parser". > > Of course, we could add a prefix like "HSLibs" to _all_ libraries > included in the repository, to make sure they don't collide with the > standard ones, but IMHO this is overkill. It's also not a guarantee that your libraries won't collide. The only way (currently) to have such a guarantee is to use User.To.Cryp.Simons as the root of your library tree. Perhaps there's a demand for a part of the hierarchy that is a "free for all", with no formal process for acquiring names, where collision is "at your own risk". Suggestions for the root name for this hierarchy are welcome: Unstable or Temp perhaps? Cheers, Simon

7 7

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