Mon, 13 Mar 2000 02:37:11 -0800, Simon Marlow <[EMAIL PROTECTED]> pisze:
> This stuff should probably be cleaned up. How about we move all
> the stuff in MutableArray that's really to do with ByteArrays (well,
> MutableByteArrays) into ByteArray, and nuke MutableArray?
Would it be possible and desirable to make switching between
polymorphic and byte arrays easier (whether mutable or not)?
By "switching" I mean overloading. And switching between byte arrays
containing e.g. Floats and Doubles. I don't like specifying types
in each operation very much. C2HS and the new FFI is much nicer than
readInt32OffAddr etc. I recently experimented with various array types,
which required changing every piece of array accessing code.
Byte arrays are currently untyped, so it would mean to either hide
the typeless interface (who would want to read an Int from a Double
array?) or have an additional layer with overloaded operations (ugh,
it was meant to be a simplification, not additional complexity...).
Overloading has one drawback: can easily lead to ambiguities if used
too much. But I still prefer disambiguation by specifying types in
right places than by using different names of operations. Users of
most other languages would laugh if they heard that accessing array
elements in GHC uses different syntax for about six kinds of arrays!
So I'm not sure what amount of overloading arrays is best. I tend
for much overloading, but present GHC uses it very little. Indices
are overloaded, good. What remains:
- Kinds of arrays. Mutable <-> immutable probably require very different
interfaces, but otherwise various arrays are quite similar.
- Types of elements for byte arrays with unboxed elements.
- State monads: IO, ST, LazyST. There are stToIO and unsafeIOtoST,
OK, but it would be easier to have both IO and non-IO versions of
a function if operations on mutable variables were overloaded.
It would be nice if the array interface fitted into Edison, but I
don't see how it would be possible now. Arrays are neither sequences
nor associative containers, they don't easily extend and shrink.
BTW: Specifying types related to ST is hard when the argument of the ST
type must be monomorphic. Would be easier with return type signatures
implemented:
action arg :: ST s [Int] = do
arr <- newSTArray ...
let
subAction :: type variable "s" can be used here
subAction = ... access arr ...
Pattern type signatures would also make sense on the left of the
monadic <- arrow.
PS. I am frustrated that a nice version of plasma fractal function
that uses self-referencing lazy Array is twice slower and uses much
more memory than an imperative version with a mutable array, which
uses more complicated formulae to determine the order of computation
of elements of the array. It would be a nice example of laziness
simplifying the algorithm, but now it's an example of laziness causing
bad performance :-(
--
__("$ P+++ L++>$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-
