September 2002 - Libraries

Re: Orderable IORefs
by Marcin 'Qrczak' Kowalczyk 21 Sep '02

21 Sep '02

Wed, 18 Sep 2002 14:37:39 +1000, Andrew J Bromage <ajb(a)spamcop.net> pisze: > At the moment it's called Data.IOStableRef, but I'm not sold on the > name. IOOrdRef has too many adjacent O's for my liking. Any other > thoughts? OrdIORef? -- __("< Marcin Kowalczyk \__/ qrczak(a)knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/

1 0

Re: MonadRef class or the like?
by Ashley Yakeley 18 Sep '02

18 Sep '02

At 2002-09-18 15:22, Hal Daume III wrote: >Ashley: Proposes: > data Ref m a = MkRef { get :: m a, set :: a -> m () } > class RefMonad m where { newRef :: a -> m (Ref m a) } >wants to ensure (like John) that it is easy to move these things across >lifted monads. This is what I ended up doing for HBase: <http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/hbase/Source/HBa se/Category/MonadReference.hs?rev=HEAD&content-type=text/plain> -- Ashley Yakeley, Seattle WA

1 0

MonadRef class or the like?
by Hal Daume III 18 Sep '02

18 Sep '02

Is there any particular reason there isn't a class for monads for which things like IORef/STRef exist? I suppose the naive approach would require functional dependencies + mp typeclasses[1], which is a decent reason :), but has anyone come up with something that doesn't require extensions? [1] i'm thinking of something like: class MonadRef m r | m -> r, r -> m where newRef :: a -> m (r a) readRef :: r a -> m a writeRef :: r a -> a -> m () updateRef :: (a -> a) -> r a -> m () i think you need the FD in both directions (certainly you need m -> r); i think the latter would serve to disambiguate things like readRef (having not actually implemented this, though, i don't know). - Hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

2 2

Orderable IORefs
by Andrew J Bromage 18 Sep '02

18 Sep '02

G'day all. I hacked up a quick implementation of IORef-like things which are members of Ord, implemented as a pair of a Unique and an IORef. At the moment it's called Data.IOStableRef, but I'm not sold on the name. IOOrdRef has too many adjacent O's for my liking. Any other thoughts? Cheers, Andrew Bromage

1 0

module Data.Bits
by Malcolm Wallace 11 Sep '02

11 Sep '02

I have just been implementing the library module `Data.Bits' for nhc98, as part of an effort to bring that compiler up-to-date with the latest FFI spec. The FFI spec says that the operations called 'shift' and 'rotate', shift and rotate their argument to the right. However, the GHC implementation in CVS shifts and rotates to the left, and is documented to do so. Who is right? FWIW, before I read any documentation I expected the undecorated forms to be rightward. Regards, Malcolm

3 8

RE: module Data.Bits
by Simon Marlow 11 Sep '02

11 Sep '02

> The FFI Addendum actually doesn't commit to which operations > are in the class. It just says defines all these ops to > have a context `Bits a', which is definitely the case. In > other words, you proposed implementation is valid by the > spec and your argument for it makes sense to me. The spec really ought to say what the member functions of the class are, if we expect people to be able to define their own instances of Bits, and I don't see why we shouldn't allow that. I think Malcolm's proposed change looks reasonable, although there was probably a reason why these functions weren't made class members in the first place. Alastair: it was your design originally I believe, any thoughts? I think it would be a small optimisation in GHC too, at least for shifts by non-constant amounts. Cheers, Simon

3 2

RE: module Data.Bits
by Simon Marlow 09 Sep '02

09 Sep '02

> I have just been implementing the library module `Data.Bits' > for nhc98, > as part of an effort to bring that compiler up-to-date with > the latest FFI spec. > > The FFI spec says that the operations called 'shift' and 'rotate', > shift and rotate their argument to the right. However, the GHC > implementation in CVS shifts and rotates to the left, and is > documented to do so. > > Who is right? FWIW, before I read any documentation I expected the > undecorated forms to be rightward. I think it's probably a mistake in the FFI addendum. As far as I can tell, the GHC/Hugs implementation of Bits has always worked the other way around. Cheers, Simon

1 0

Re: [Haskell-i18n] SourceForge Project Active
by Martin Norbäck 01 Sep '02

01 Sep '02

tor 2002-08-29 klockan 04.20 skrev Ashley Yakeley: > A SourceForge project for the internationalisation effort is active at > <http://sourceforge.net/projects/haskell-i18n/> Searching for "haskell" att sourceforge gave me these: hfl (Andrew Bromage) Haskell Foundation Library "The future of the Haskell standard library is here." CVS contains edison and some Monads hbase (Ashley Yakeley) "Common Haskell code for other semantic.org projects, and other useful things." CVS contains a number of good-looking modules (Org.Org.Semantic.*), among other things HBase.Text.UTF8. haskell-libs Haskell User-Submitted Libraries "Haskell User-Submitted Libraries includes anything we can get our hands on and clean up for general use, as well as new libraries that would be useful to the general Haskell community. Submit your libs, or join the project to create needed libs!" CVS contains Imap.hs haskell-i18n (the latest addition :) Perhaps we should try and merge these, is there any point in having multiple projects and repositories when we have hierarchical libraries? Regards, Martin -- Martin Norbäck d95mback(a)dtek.chalmers.se Kapplandsgatan 40 +46 (0)708 26 33 60 S-414 78 GÖTEBORG http://www.dtek.chalmers.se/~d95mback/ SWEDEN OpenPGP ID: 3FA8580B

4 4