apfelmus:
> Duncan Coutts wrote:
> > On Wed, 2006-11-29 at 20:27 +0100, [EMAIL PROTECTED] wrote:
> >
> >> On the implementation level, lazy evaluation is in the way when
> >> crunching bytes.
> >
> > Something I rather enjoyed when hacking on the ByteString lib is finding
> > that actually lazy e
Duncan Coutts wrote:
> On Wed, 2006-11-29 at 20:27 +0100, [EMAIL PROTECTED] wrote:
>
>> On the implementation level, lazy evaluation is in the way when
>> crunching bytes.
>
> Something I rather enjoyed when hacking on the ByteString lib is finding
> that actually lazy evaluation is great when cr
On Wed, 2006-11-29 at 20:27 +0100, [EMAIL PROTECTED] wrote:
> On the implementation level, lazy evaluation is in the way when
> crunching bytes.
Something I rather enjoyed when hacking on the ByteString lib is finding
that actually lazy evaluation is great when crunching bytes, though you
do need
> I personally find doing higher order functions with IO extremely
> difficult, and the resulting compiler errors are often downright scary.
> But this is probably a direct consequence my rather limited
> understanding of the monadic operators that the do notion hides. It
> seems that one has to be
On Tue, 2006-11-28 at 15:10 +0300, Bulat Ziganshin wrote:
> Hello Niko,
>
> Tuesday, November 28, 2006, 1:42:10 PM, you wrote:
>
> > I personally find doing higher order functions with IO extremely
> > difficult, and the resulting compiler errors are often downright scary.
> > But this is probabl
Hello Niko,
Tuesday, November 28, 2006, 1:42:10 PM, you wrote:
> I personally find doing higher order functions with IO extremely
> difficult, and the resulting compiler errors are often downright scary.
> But this is probably a direct consequence my rather limited
> understanding of the monadic
[EMAIL PROTECTED] wrote:
> I tried to show how the code can be rewritten in a more declarative
> manner by the use of the higher order function (accumM) which is akin to
> the accumulation function (Data.Array.accum) for immutable arrays. This
Ok, given this explanation and your detailed annotatio
> nor that I would really understand the code you've posted. On the positive
> side of things, you've given me a lot to think about. Maybe in the
> fullness of time I shall return and say 'Lo! I can write leakless
> Haskell code!'. But alas, that time seems so distant now.
I tried to show how the
On Thu, Nov 23, 2006 at 10:13:25PM +0100, Udo Stenzel wrote:
> [EMAIL PROTECTED] wrote:
> > >> (lo, hi) <- getBounds buf
> > >
> > > to
> > >
> > > let (lo,hi) = bounds buf
> >
> > The interface changed between GHC 6.4.2 and 6.6.
> > But no honorable Haskell paladin would ever
[EMAIL PROTECTED] wrote:
> >> (lo, hi) <- getBounds buf
> >
> > to
> >
> > let (lo,hi) = bounds buf
>
> The interface changed between GHC 6.4.2 and 6.6.
> But no honorable Haskell paladin would ever dare to use UndeadArrays.
Hm, and 'bounds' is simply gone? Hope that doesn't
Udo Stenzel wrote:
> Niko Korhonen wrote:
>> I have the following code whose purpose is to add dither (noise) to a given
>> array. The code looks very straightforward but apparently it has a memory
>> leak
>> somewhere.
>
> No, it doesn't. It can't, because it doesn't even compile. After
> corr
Ah, yet another UndeadArray necromancer exhausting his stack of bones.
May the forces of light suggest to structure the incantation of darkness?
modifyArray arr i f =
readArray arr i >>= \y -> writeArray arr i (f y)
accumM :: (MArray a e m, Ix i) =>
(e -> e' -> e) -> a i e
12 matches
Mail list logo
