- Libraries - Haskell.org

RE: IOError vs. Exception vs. IOException
by Simon Peyton-Jones 04 Nov '02

04 Nov '02

I'd be happy with these changes. | -----Original Message----- | From: Ross Paterson [mailto:ross@soi.city.ac.uk] | Sent: 04 November 2002 09:52 | To: Simon Peyton-Jones | Cc: Simon Marlow; Alastair Reid; libraries(a)haskell.org | Subject: Re: IOError vs. Exception vs. IOException | | On Mon, Nov 04, 2002 at 08:57:06AM -0000, Simon Peyton-Jones wrote: | > | > | FWIW, I agree with you, and I don't have any objections to changing it | > | (but Simon P.J. might). | > | > I doubt I'd have an objection. Want to make a concrete proposal to the | > libraries list? I didn't get exactly what it was from your messages. | | [redirecting to libraries] | Two (mostly) independent proposals: | | 1) Move bracket and bracket_ from System.IO (or GHC.Exception) to | haskell98/IO.hs. These two should now never be used anyway (except | in all-H98 programs), and this would save users of the new libraries | from having to hide them. | | 2) Define | | type IOError = IOException -- was Exception | | (or vice versa), leave the type of Prelude.ioError as IOError -> IO a, | but add to Control.Exception | | throwIO :: Exception -> IO a | | If both are done, the only overlap seen by users of the new libraries | is Prelude.catch vs Control.Exception.catch and System.IO.try vs | Control.Exception.try. In each case there's a type distinction | reflecting the semantic distinction.

1 0

Re: IOError vs. Exception vs. IOException
by Ross Paterson 04 Nov '02

04 Nov '02

On Mon, Nov 04, 2002 at 08:57:06AM -0000, Simon Peyton-Jones wrote: > > | FWIW, I agree with you, and I don't have any objections to changing it > | (but Simon P.J. might). > > I doubt I'd have an objection. Want to make a concrete proposal to the > libraries list? I didn't get exactly what it was from your messages. [redirecting to libraries] Two (mostly) independent proposals: 1) Move bracket and bracket_ from System.IO (or GHC.Exception) to haskell98/IO.hs. These two should now never be used anyway (except in all-H98 programs), and this would save users of the new libraries from having to hide them. 2) Define type IOError = IOException -- was Exception (or vice versa), leave the type of Prelude.ioError as IOError -> IO a, but add to Control.Exception throwIO :: Exception -> IO a If both are done, the only overlap seen by users of the new libraries is Prelude.catch vs Control.Exception.catch and System.IO.try vs Control.Exception.try. In each case there's a type distinction reflecting the semantic distinction.

1 0

Data.Array Annoyance
by Ashley Yakeley 28 Oct '02

28 Oct '02

It is difficult to make empty zero-based arrays indexed by unsigned integer types. Supposing I want to make zero-based arrays of type "Array Word16 a". How do I make the empty array? Perhaps there should also be a different kind of array type that uses Enum indexes instead of Ix indexes... -- Ashley Yakeley, Seattle WA

1 0

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