May 2003 - Libraries - Haskell.org

Re: Converting things to and from binary
by Hal Daume III 20 May '03

20 May '03

I'm going to chime in here for the first time. There was a *long* discussion of this on the libraries list a few months back. See http://haskell.org/pipermail/libraries/2002-November/000691.html and the discussion that followed. I think that we should (a) move this discussion to the libraries list and (b) work from the point reached by those discussions - Hal -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume On Tue, 20 May 2003, George Russell wrote: > Derek wrote (snipped) > > What's wrong with NHC's Binary/BinArray library? There seems to be a > > GHC port on the GreenCard page. > > The home page of the York Binary library seems to be > http://www.cs.york.ac.uk/fp/nhc13/libs/Binary.html > Malcolm will doubtless have something to say here. However I would > say not that there's something "wrong" with the Binary/BinArray > library, but that it seems to be addressed towards a different > class of problems (specifically data-compression) to those > I am interested in (blasting data rapidly in and out). The main > differences are > (1) the framework I proposed in the original message: > http://haskell.org/pipermail/glasgow-haskell-users/2003-May/005166.html > is byte-based, while the York Binary framework is bit-based. > I would imagine that this means the York Binary framework would be > very much less efficient at handling long sequences of bytes, > since they will presumably have to be shifted before > being written to the destination. > (2) the York Binary library uses the IO monad, and presumably > various variables within a BinHandle, to keep track of state. > I think this is unnecessary, for example I don't think the > process of converting a value to a byte array should really > have to go through IO. We are supposed to be functional > programmers after all. > (3) the York binary library provides two things you can > write bits to (a Handle, and a fixed area in memory) and a > large set of operations (seek and co), but it would be > difficult for a normal programmer to extend this. (For > example, what about someone in GHC wanting to write to > a Posix Fd?) On the other hand the framework I propose > has only two basic operations for writing, and two for > reading, which means it should be much easier to define > alternative consumers and sources of binary data. > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >

2 2

architecture-dependent types
by Ross Paterson 20 May '03

20 May '03

Should not Foreign.C.Types, Foreign.C.TypesISO and System.Posix.Types export their types opaquely? That would make their interface and documentation architecture-independent.

1 0

Blowfish
by Dominic Steinitz 18 May '03

18 May '03

I have been unable to track down the email of the author (Doug Hoyte) of the blowfish code on http://sourceforge.net/forum/forum.php?forum_id=263682. I'd like to include it the Crypto library. I think I can under the terms of the licence (GNU GPL) provided I reproduce the copyright information. Does this sound ok? Or alternatively does someone have Doug's email address so I can check it's ok with him directly. Many thanks, Dominc.

3 2

Crytpo for nhc
by Dominic Steinitz 18 May '03

18 May '03

I have been trying to write a Crypto library and so far it works with ghc and hugs. Am I right in thinking I am going to struggle with nhc? It uses Word8 and Word64 heavily. For example, cipher block chaining relies on xoring Word64. I attach the library and a test program. I'd be grateful for any suggestions on how to make it work with nhc. Dominic Steinitz

2 2

RE: list monad transformer
by Simon Marlow 16 May '03

16 May '03

> i would gladly volunteer for the task. in fact i have my own monad > transformer library which is very simillar to the ghc one in some > respects, and i have been wanting to merge the two together... > > how does one go about "owning" a library :-) ? You volunteer (as you have done), and if there are no objections then you become the maintainer. Since this library resides in CVS, we'd give you CVS write access. Cheers, Simon

1 0

RE: list monad transformer
by Simon Peyton-Jones 16 May '03

16 May '03

We could do with someone to take ownership of the Control.Monad libraries. Andy Gill wrote them but I don't think he's actively maintaining them, which leaves discussions like this in mid air. Simon | -----Original Message----- | From: haskell-admin(a)haskell.org [mailto:haskell-admin@haskell.org] On Behalf Of Andrew J Bromage | Sent: 16 May 2003 05:20 | To: Iavor Diatchki | Cc: Haskell Mailing List; libraries(a)haskell.org | Subject: Re: list monad transformer | | G'day all. | | On Thu, May 15, 2003 at 11:12:32AM -0700, Iavor Diatchki wrote: | | > given that, we should either remove the | > #ListT# transformer from the monad library, or (perhaps better) put a | > big warning that it should only be used with commutative monads. | | My personal choice would be to dump it and replace it with Ralf | Hinze's backtracking monad transformer, which _does_ preserve | commutativity. If someone with checkin rights is listening in, | I'd be very happy to contribute my implementation, which is about | as stable as it's ever going to be. | | Cheers, | Andrew Bromage | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

2 1

RE: Hierarchical libraries document updated
by Simon Marlow 16 May '03

16 May '03

> What's the Module field in the module header comment for? No deep reasons. Some shallow reasons: it looks nicer to have the module name at the top of the module, and very naive tools which pull out bits from the header might want to get at the module name. Haddock could easily detect any inconsistencies, but it doesn't. I'm not that strongly attached to keeping it... Cheers, Simon

1 0

Hierarchical libraries document updated
by Simon Marlow 16 May '03

16 May '03

Folks, I've updated the document at http://www.haskell.org/~simonmar/libraries/libraries.html to reflect some changes in how the libraries situation is evolving. This document is the central place where the workings of the hierarchical library system is described: it discusses how new libraries are contributed, where they live, what form they take and so on. The document is also in CVS (fptools/libraries/doc/libraries.sgml). Previously, we talked about the "Core Libraries" which were all going to be kept in one place (fptools/libraries), and this has pretty much been the situation up to now. But from here on, I expect things to become more distributed: people will maintain their own libraries and do releases independently of the compilers, and when we have a separate library infrastructure there will be no need for libraries to reside in the fptools tree. So with this in mind, the document now talks about "Reference Libraries". It is more clear about how names in the hierarchy are allocated (namely by asking on libraries(a)haskell.org) and it has a full list of what names have been allocated so far, who maintains those libraries and where to get the code. The evolution of a library infrastructure will have an impact on much of this, so I suggest that this document is the right place to record the results of that discussion (if/when there are some!). Comments welcome, as usual. Cheers, Simon

4 4

list monad transformer
by Iavor Diatchki 16 May '03

16 May '03

hello, in his thesis [1], sheng liang mentions that we cannot define a list monad transformer. for some time now i was wondering why is that but never had the time to look into it, until the other day. what basically breaks is the associativity law, as the one form (#lhs# bellow) traverses the "choice tree" in a breadth first search manner, while the other (#rhs# bellow) does it in a depth first search manner. when the underlying monad is not commutative (i.e. the order of effects in it matters) we run into a probelm. here is an example: > import Control.Monad.List > > pr x = lift (putStr $ show x ++ " ") > > test :: (ListT IO (), ListT IO ()) > test = (m >>= f >>= g, m >>= \x -> f x >>= g) > where m = do pr "m: "; pr 1 `mplus` pr 2 > f _ = do pr "f: "; pr 3 `mplus` pr 4 > g _ = do pr "g: "; pr 5 `mplus` pr 6 > > main = do let (lhs,rhs) = test > runListT lhs > putStrLn "" > runListT rhs the transformer will work for commutative monads (intuition is above, formal proof is in [2]). given that, we should either remove the #ListT# transformer from the monad library, or (perhaps better) put a big warning that it should only be used with commutative monads. a rule of thumb for determining the commutativity of a monad is (using terminology from the library): the #Identity# monad is commutative the #ReaderT# transformer preserves commutativity the #ErrorT# transformer preserves commutativity the #WriterT# transformer preserves commutativity if its monoid (for collecitng output) is commutative bye iavor References ========== [1] Modular Monadic Semantics and Compilation. Sheng Liang. Ph.D. Thesis, Yale University, 1997. [2] Composing Monads. Mark P. Jones and Luc Duponcheel, Research Report YALEU/DCS/RR-1004, Yale University, New Haven, Connecticut, USA, December 1993.

4 3

RE: X11 libraries
by Simon Marlow 15 May '03

15 May '03

> > According to the current hierarchy document[1] we have these > > libraries under Graphics.X11.Xlib. Perhaps these names would be > > correct: > > > Graphics.X11.Xlib > > Graphics.X11.Xlib.Types > > Graphics.X11.X1ib.StdDIS > > > The reason for separating Xlib into its own hierarchy is that there > > are other APIs under X11 (Xt, Xaw, Xmu). > > That makes sense except that I didn't tell you enough about Types and > StdDIS. Types contains generic X11 types (which would be used by Xt, > Xaw, etc). StdDIS contains generic GreenCard definitions and would > also be used by Xt, etc. So I see things developing as follows: > > Graphics.X11 -- reexports all children except StdDIS > Graphics.X11.StdDIS -- should be shared by all GC'd files > Graphics.X11.Types -- shared by all X11 impls > Graphics.X11.Xlib > Graphics.X11.Xt > Graphics.X11.Xaw > Graphics.X11.Xmu > > [StdDIS is just a copy of the file included in GreenCard distributions > and would go away if we were to do the sensible thing and have a > single StdDIS somewhere in the libraries tree.] Ok for Graphics.X11.Types. For StdDIS, if it is shared by all greencard-generated source, then it probably should be something like Greencard.StdDIS and kept in a separate greencard package. For now, putting it in Graphics.X11.StdDIS (and not advertising its existence) should be fine. > > Win32 is currently listed as being under System.Win32. However, > > since we've just put Dotnet at the top of the hierarchy, and Win32 > > contains a range of both systems and graphics stuff, I'd be happy > > for it to be at the top of the hierarchy too. > > I think I'd prefer both to be under System. For Dotnet at least, there's a whole hierarchy that lives under it that mirrors the .NET class hierarchy. System.Dotnet.System.Xml would be a bit of a mouthful, for example. But also these libraries don't fall into any single category in the Haskell hierarchy, so there's no reason we should place them under System any more than Graphics, for example. System.Posix is different: it only deals with system interaction (although the network bits of System.Posix really live under Network, so it's not a clean break). > > HGL is assigned Graphics.HGL, which seems like the right thing. > > Ok, I'll put it there. Or Graphics.Rendering.HGL as Malcolm suggested (actually this is probably more accurate). > > The NHC folks seem to be using their own Makefiles, called > > Makefile.nhc98. > > I'll probably do the same. > > Hmmm, I wonder if the existing scriptMakefile used by Hugs to convert > and compile the libraries should be moved into libraries/base ? By all means... > I gather that the Win32 library is needed for windows version of GHC > so it's a bit moer of an issue there... It's distibuted with the Win32 GHC, but isn't needed by it (AFAIK). Cheers, Simon

4 6