Kevin Atkinson:
> I have a generic mutable array class which has a few basic methods:
>
> class MArray ... where
> newArray :: Int -> m (mutArray st el)
> write :: mutArray st el -> Int -> el -> m ()
> read :: mutArray st el -> Int -> m el
> freeze :: m mutArray st el -> m array el
> thaw :: m array el -> m mutArray st el
>
> and it turns out that it is possible to create a full fledge
> non-mutable array based on the mutable array class with the help of
> this method:
>
> thawRunFreeze :: Array el
> -> (m mutArray st el -> m ())
> -> Array el
>
> Which will, as the signature suggests and name suggest, thaw an array,
> perform some actions on the mutable array, and then freeze it,
> returning the new array.
>
> The only problem is that it is impossible to have a generic
> thawRunFreeze method in Haskell. So I had to resort to some ugly code
> generation.
Thanks for the example. If I understand you here, what you intend is
not that there always _should_ be a thawRunFreeze, for any type, but
that it should be possible to have an implemention, or semi-generic
hierarchy of implementations, of this which either uses or doesn't use
such a method, as appropriate/available.
I think this is certainly do-able, and I've seen it addressed, if
not necessarily entirely unqualifiedly solved, in a couple of papers.
If this is your main concern about the flexibility of Haskell types,
then be of good cheer as I'm certain this one is soluble, entirely
within the basic 'look and feel' of Haskell typing.
Which isn't to say that I'm not handwaving over a morass of technical
details, or expecting the language committee to agree on any such things
within the netx language revision or three. ;-)
Slán,
Alex.
