Plus ca change...
I advocated overloaded array operations in similar manner some years
back among pH enthusiasts---this being years before functional
dependencies, though, the multiparameter type classes worked only in
the pH compiler. :-) (I recall audible complaints from Simon P-J among
others.
> Some commented type signatures in MArray interface mention ST instead
> of the generic monad. Signatures of MArray class operations have
> "a s ix e" instead of "a ix e".
Oh, thanks. As you can see, I've been through a few iterations with the
design already :)
> A proposal to resolve name cla
Wed, 29 Mar 2000 04:52:17 -0800, Simon Marlow <[EMAIL PROTECTED]> pisze:
> I'd like to solicit some comments on the following proposal for
> generalising GHC's various array mechanisms.
_
|| / \ || |
| /\ | ( ) | /\ | |
|/ \| \_/ |/ \| .
Some commented type signatures
Simon Marlow wrote:
> Actually, I'm slightly concerned about your use of small arrays: the static
> (one-off) cost of allocating an array is quite high compared to eg. tuples
> or records. Are arrays the only solution here?
You're right of course that arrays are quite expensive, but
it is not c
> My main comment is please don't ignore a simple update operation
> on immutable arrays, with a type something like
> update :: Ix ix => a ix e -> ix -> e -> a ix e
> I don't care about the name but I do care about the functionality.
> I'm perfectly happy with the naive, dirt simple, O(n) imple
Simon Marlow wrote:
> class HasBounds a => IArray a e where
> (!) :: Ix ix => a ix e -> ix -> e
> array :: Ix ix => (ix,ix) -> [(ix,e)] -> a ix e
>
> class (Monad m, HasBounds a) => MArray a e m where
> read:: Ix ix => a ix
