[prev in list] [next in list] [prev in thread] [next in thread]
List: haskell-cafe
Subject: RE: [Haskell-cafe] FiniteMap-like module for unordered keys?
From: "Simon Marlow" <simonmar () microsoft ! com>
Date: 2004-11-11 12:21:30
Message-ID: 3429668D0E777A499EE74A7952C382D102B2C5F6 () EUR-MSG-01 ! europe ! corp ! microsoft ! com
[Download RAW message or body]
On 10 November 2004 10:54, Graham Klyne wrote:
> At 23:25 09/11/04 +0100, Remi Turk wrote:
>>> (I looked at Data.HashTable, but I couldn't figure why it needs to
>>> be implemented in the IO monad, except to optimize the internal
>>> implementation. Also, it's not clear to me how it behaves when a
>>> key is inserted that already exists.)
>> A hash-table becomes rather useless without mutable state AFAICS.
>> Without it, one might almost just as well use a list of pairs...
>> Actually, some kind of freezeHashTable may be useful, and
>> a HashTable in the ST monad is definitely useful: I guess patches
>> are welcome..
>
> I can see why using (something like) a state monad might be useful,
> but not why it needs to be an IO monad, unless there's some fairly
> low-down optimization being performed.
>
> (I'm not asking for this, BTW, just commenting on the apparent lack.
> For my application, I am using a list of pairs, as I expect these
> tables to be relatively small.)
There is no good reason that Data.HashTable needs to be in the IO monad,
other than that's where I wanted to use it and having two versions (or
using lots of stToIO) would have been a pain.
The performance of ST & IO are the same. Long ago, when IO exceptions
were implemented explicitly in the IO monad, IO used to be less
efficient than ST.
Cheers,
Simon
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic