- Libraries - Haskell.org

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

Food for thought: Numeric.Special
by Matthew Donadio 06 Jun '03

06 Jun '03

Hi all, I am currently working on a module where I need some "special" math functions (elliptic integrals and Jacobi elliptic functions). This got me thinking that there may be a place in the Numeric hierarchy for a Special branch. I think the only sane way to do this is with FFI, and I think the GNU Scientific Library (GSL) is the best target for this. Some people may have access to the IMSL or NAG libraries, but I doubt that most do. I also believe that GSL is available for all of the targets currently served by the various Haskell compilers, including Windows The best way to attack this is probably to have a module for each group of functions. So there would be Numeric.Special.Gamma, Numeric.Special.Zeta, etc. The Haskell names would match the GSL names minus the gsl_sf prefix. Most (all?) of the functions are pure, and basically accept doubles or ints as parameters and return a double. So, it's not a hard job, but there are a zillion functions. I am willing to (slowly) tackle the job since I already have it started. Thoughts? Comments? -- Matthew Donadio <m.p.donadio(a)ieee.org>

4 5