I'd like to solicit some comments on the following proposal for generalising
GHC's various array mechanisms.
The aims are twofold:
- make it really easy to replace an existing
(immutable) Array with a strict unboxed
array type (i.e. just by changing the type
forgot the attachments...
begin 600 ArrayBase.hs
M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM
M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2T*+2T@("1)9"0*+2T*
M+2T@*,I(%1H92!'2$,@55A;2`R,#`P"BTM"@IM;V1U;4@07)R87E"87-E
M('=H97)E"@II;7!OG0@4U0*:6UP;W)T($%D9'(*:6UP;W)T($)Y=5!G)A
How can I build fptools suite on system without Haskell installed ?
(I'm using Linux-x86 system but prefer to compile everything myself).
I've build ghc configured with --enable-hc-boot; but when I try to
configure it without this switch to build the hi files (as described
in the manual), I get
How can I build fptools suite on system without Haskell installed ?
(I'm using Linux-x86 system but prefer to compile everything myself).
I've build ghc configured with --enable-hc-boot; but when I try to
configure it without this switch to build the hi files (as described
in the manual),
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 e - ix - m e
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
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
