- Libraries - Haskell.org

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

RE: Foreign.GreenCard.StdDIS (was Re: X11 libraries)
by Simon Marlow 15 May '03

15 May '03

> When I got back to work on putting an HGL release together, I > realized that > I'd have to do a fresh release of GreenCard first since it > has a bunch of > updates to work with hierarchial names, ffi, etc. The > GreenCard distrib > contains what ought to be the master copy of the > StdDIS.{gc,hs} so I figure > it ought to be made a proper library package, put in the > hierarchial library > namespace, etc. Obvious places to put it in the library > hierarchy are: > > Foreign.GreenCard.StdDIS.hs > GreenCard.StdDIS.hs > Apps.GreenCard.StdDIS.hs > <SomeOtherPrefix>.GreenCard.StdDIS.hs There is reasonable justification for each of these - I don't have any strong preferences. Malcolm prefers Foreign.GreenCard.hs; that's fine by me. > (btw it seems like we might see more apps with support > libraries -especially > if the app generates Haskell code- so this may be an instance > of a more general problem.) FWIW, in Happy and Alex I just copy some boilerplate code directly into the generated Haskell to avoid this problem. The boilerplate isn't baked into the Happy or Alex binary, it's installed as a separate file. > [btw GreenCard raises an additional issue for any library > building/ packaging > infrastructure. If you want to use GreenCard, you need > StdDIS.gc and (the > makefile which invokes) GreenCard needs to know where to find > it. So we need > a standard place for it to live or a way to locate it once installed.] We've solved this problem several times (GHC, hsc2hs, Happy, Alex, Haddock). The solution I normally use for Unix systems is to have a small script which invokes the main binary passing it a flag which indicates the location of its auxiliary files (usually something like /usr/local/lib/happy). You can build a location-independent binary package which just fiddles with this script at install time. On Windows, it's rather easier because a binary can get at its own filesystem location at runtime. This all assumes the user normally wants the standard StdDIS.gc and won't want to fiddle with it, I guess. Cheers, Simon

1 0

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

15 May '03

> "Simon Marlow" <simonmar(a)microsoft.com> writes: > > > 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. > > The latest version of the libraries document is looking good, and > thanks for keeping it rolling Simon. No problem! > In the section on Portability, bit-wise operations (i.e. Data.Bits) > are noted as non-portable, yet as far as I'm aware they are supported > by all the implementations now. Would anyone object if I move that > bullet item to the section on "extensions that can be assumed > portable"? Yes, please do. I was vaguely aware that NHC had adopted Data.Bits, but hadn't got around to checking that fact. > Also, in section 4.4, the allocation of libraries to maintainers is > a somewhat rough approximation, I'd say. No doubt we can gradually > refine it. For instance, Debug.QuickCheck.* is currently allocated to > this mailing list, but I'm sure it should really be under the control > of John Hughes and Koen Claessen - I know that they are planning a new > release soon. Sure. > I have never heard of the System.DL library before, and couldn't > guess from the name what functionality it aimed to provide. I had > to go look at the source code to determine what it does! A definite > candidate for clearer naming - I would suggest System.DynamicLinker > or something along those lines. Yes. System.DL is a Haskell interface to the Unix libdl library, which in fact appears to be part of the latest revision of the POSIX standard, so it should probably be called System.Posix.DyamicLinker. I just noticed on my ToDo list for System.Posix I have it down as System.Posix.DynamicLoader. Volker, what do you think about renaming it to one of these? Cheers, Simon

2 1

(No Subject)
by >>SparkleThings.com Hair Accessories 12 May '03

12 May '03

Dear Customer, SparkleThings.com has new and beautiful hair accessories that will make you look absolutely wonderful. Click here or the above image to go to http://www.sparklethings.com Thank you SparkleThings.com

1 0