- Libraries - Haskell.org

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

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

12 Jun '03

1 0

RE: Existing libraries and tools
by Simon Marlow 12 Jun '03

12 Jun '03

> Whilst we're thinking about library infrastructure, binary > packages, orphaned > libraries, etc. I just found what I think is the most > comprehensive list of > Haskell libraries and tools in existence. This list is > basically all the > Haskell-related FreeBSD ports for: > > http://www.freshports.org/haskell/ > > It's a very impressive list - far more comprehensive than for > any other platform. Yes, Oliver Braun deserves endless gratitude and many virtual beers for all the effort he's put into FreeBSD support for Haskell. Thanks Olli! Cheers, Simon

1 0

Existing libraries and tools
by Alastair Reid 11 Jun '03

11 Jun '03

Whilst we're thinking about library infrastructure, binary packages, orphaned libraries, etc. I just found what I think is the most comprehensive list of Haskell libraries and tools in existence. This list is basically all the Haskell-related FreeBSD ports for: http://www.freshports.org/haskell/ It's a very impressive list - far more comprehensive than for any other platform. A very useful feature is that each entry includes links to the homepages of libraries and tools so it's easy to find a source package if you don't happen to use FreeBSD. I realized how useful this list was while creating a table of which libraries are available on which packaging systems. The table is near the bottom of: http://haskell.org/hawiki/LibrariesAndTools Apologies for any errors. Please make any necessary corrections directly... -- Alastair Reid

1 0

Re: openFile and text mode vs. binary mode
by Graham Klyne 10 Jun '03

10 Jun '03

At 10:33 10/06/03 +0100, Simon Marlow wrote: > hSetBinaryMode :: Handle -> Bool -> IO () What (of any real value) is lost by fixing the IO mode at the point of obtaining the handle? I'm guessing that having an option to change the mode later may at best create additional work, and maybe even create inconsistencies in behaviours on different systems. #g ------------------- Graham Klyne <GK(a)NineByNine.org> PGP: 0FAA 69FF C083 000B A2E9 A131 01B9 1C7A DBCA CB5E

1 0

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

RE: monad transformer library
by Simon Peyton-Jones 09 Jun '03

09 Jun '03

You do know that in GHC (though not Hugs) you can say newtype Foo = MkFoo Baz deriving( Monad, MyClass, This, That ) That is, deriving works for arbitrary classes for newtypes, just using the instance for the representation type. This greatly alleviates the pain you refer to. It's documented in the GHC user manual. Mind you, it's probably no help to you because we must support Hugs and nhc here S | -----Original Message----- | From: libraries-admin(a)haskell.org [mailto:libraries-admin@haskell.org] On Behalf Of Iavor Diatchki | Sent: 04 June 2003 21:16 | To: Iavor Diatchki | Cc: Ross Paterson; libraries(a)haskell.org | Subject: Re: monad transformer library | | hello, | | Iavor Diatchki wrote: | >> Use of type synonyms, like | >> | >> type Reader r = R.ReaderT r Identity | >> | >> is more economical, but will lead to more complex error messages. | > | > this is a good point and i will change that, unless anyone objects? | | i am having 2nd thoughts about that. using newtypes will require an | alwful lot of "fake" instances making the libarary about 2 times bigger. | i tried to make a few errors and the error messages did not seem much | worse with the "type" -- what happens is that "missing instances" are | reported for the Identity monad, rather than the "Reader" monad. | this seems reasonable as methods usually just search for the first layer | that implements a given "feature", until they hit the "base case". using | newtype changes the base case from Identity to Reader, which in some | case i think is perhaps more confusing. any thoughts? | | bye | iavor | | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries

4 3

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

07 Jun '03

1 0