Benjamin Franksen wrote:
> > append :: (IArray UArray e, MArray (STUArray s) e (ST s)) => ...
I believe there must be an MArray instance for every s for this to work.
If I understand types correctly (which isn't all that certain), the
correct context would be
> > append :: (IArray UArray e, foral
On Fri, Aug 26, 2005 at 08:27:43PM -0400, ChrisK wrote:
> This is flexible, but the type annotation becomes unnatural, and the
> error messages make C++ template error reporting look clear by
> comparison.
Are you getting 2MB long error messages from GHC? ;->
Best regards
Tomasz
_
On Thursday 25 August 2005 19:58, Udo Stenzel wrote:
> [...] you'll need a type signature somewhere to help ghc resolve
> the overloading of newArray and readArray, which is surprisingly
> tricky due to the "s" that must not escape. This works:
>
> compute :: Int -> Int
> compute n = runST ( do
>
On Fri, Aug 26, 2005 at 08:27:43PM -0400, ChrisK wrote:
> to figure out since there was no Data.Array.ST.Lazy. Does anyone know
> why it was left out? I'll put a note on the HaskellTwo page about that...
Some time ago when I wanted a lazy hashtable I came up with this,
which, after minimal testi
Alistair Bayley wrote:
>>There are also STArray examples on the wiki at
>>http://haskell.org/hawiki/ImperativeHaskell
>>
>>This includes a very high performance use of STUArray example (from
>>Autrijus), and a ST.Lazy example that I wrote that uses STArray.
>
>
> Thanks. I saw these, but couldn
> There are also STArray examples on the wiki at
> http://haskell.org/hawiki/ImperativeHaskell
>
> This includes a very high performance use of STUArray example (from
> Autrijus), and a ST.Lazy example that I wrote that uses STArray.
Thanks. I saw these, but couldn't quite figure out what I neede
> > makeArray :: Int -> Int -> a -> ST s (STArray s Int a)
> > makeArray lower upper val = newArray (-lower, upper) val
> ^
> Is negation of lower intentional here?
Yes, 'tis. Arguable as to whether or not it's a good idea, as it
changes the inerface. In my
On Fri, Aug 26, 2005 at 04:22:11PM +0100, Bayley, Alistair wrote:
> makeArray :: Int -> Int -> a -> ST s (STArray s Int a)
> makeArray lower upper val = newArray (-lower, upper) val
^
Is negation of lower intentional here?
Best regards
Tomasz
___
Hi,
There are also STArray examples on the wiki at
http://haskell.org/hawiki/ImperativeHaskell
This includes a very high performance use of STUArray example (from
Autrijus), and a ST.Lazy example that I wrote that uses STArray.
--
Chris
___
Haskell-C
> From: Udo Stenzel [mailto:[EMAIL PROTECTED]
>
> You messed the argument order to readArray up.
Yes, that won't help :-)
> Even with that repaired,
> you'll need a type signature somewhere to help ghc resolve the
> overloading of newArray and readArray, which is surprisingly
> tricky due
> t
> From: Ketil Malde [mailto:[EMAIL PROTECTED]
>
> Greg Buchholz <[EMAIL PROTECTED]> writes:
>
> > Diff arrays have an immutable interface, but rely on
> internal updates in
> > place to provide fast functional update operator //.
>
> While a cool concept, ISTR that somebody benchmarked these s
Udo Stenzel <[EMAIL PROTECTED]> writes:
> You messed the argument order to readArray up. Even with that repaired,
> you'll need a type signature somewhere to help ghc resolve the
> overloading of newArray and readArray, which is surprisingly tricky due
> to the "s" that must not escape.
I have s
Greg Buchholz <[EMAIL PROTECTED]> writes:
> Diff arrays have an immutable interface, but rely on internal updates in
> place to provide fast functional update operator //.
While a cool concept, ISTR that somebody benchmarked these some time
ago, and found the performance to be fairly poor in prac
Bayley, Alistair wrote:
> compute :: Int -> Int
> compute n = runST ( do
> arr <- newArray (-1, 1) n
> readArray 1 arr
> )
You messed the argument order to readArray up. Even with that repaired,
you'll need a type signature somewhere to help ghc resolve the
overloading of newArray and r
On 8/25/05, Bayley, Alistair <[EMAIL PROTECTED]> wrote:
> Hello all,
>
> I have a pure function which uses immutable arrays from Data.Array, but it
> spends about 95% of its time doing array updates. The arrays are used in a
> single-threaded manner (no need for the old values after an array updat
Bayley, Alistair wrote:
>
> I have a pure function which uses immutable arrays from Data.Array, but it
> spends about 95% of its time doing array updates. The arrays are used in a
> single-threaded manner (no need for the old values after an array update),
This is probably completely off-topi
Hello all,
I have a pure function which uses immutable arrays from Data.Array, but it
spends about 95% of its time doing array updates. The arrays are used in a
single-threaded manner (no need for the old values after an array update),
and the arrays are not returned; just one of the elements. So
17 matches
Mail list logo