Hi,
I was wondering if anyone could give me some help with this problem ?
I'm trying to hold some state in a StateMonad whilst I iterate over a
large tree, and finding that I'm running out of stack space very
quickly. The simplified program below exhibits the same problem.
This is the first tim
On Tue, Dec 30, 2003 at 02:12:15PM +, Joe Thornber wrote:
> Hi,
>
> I was wondering if anyone could give me some help with this problem ?
> I'm trying to hold some state in a StateMonad whilst I iterate over a
> large tree, and finding that I'm running out of stack space very
> quickly. The
Hi,
I think the problem is in the State Monad itself;
State Monad is lazy to compute its state.
I am not a haskell expert, and there may be better ideas. But anyhow,
when I use these >>>= and >>> instead of >>= and >>,
your example runs fine. I hope it becomes some help.
m >>>= k = State $ \s
On Wed, Dec 31, 2003 at 02:54:18AM +0900, Koji Nakahara wrote:
> Hi,
>
> I think the problem is in the State Monad itself;
> State Monad is lazy to compute its state.
>
> I am not a haskell expert, and there may be better ideas. But anyhow,
> when I use these >>>= and >>> instead of >>= and >>,
On Tue, Dec 30, 2003 at 08:28:11PM +0100, Tomasz Zielonka wrote:
> On Wed, Dec 31, 2003 at 02:54:18AM +0900, Koji Nakahara wrote:
> > Hi,
> >
> > I think the problem is in the State Monad itself;
> > State Monad is lazy to compute its state.
> >
> > I am not a haskell expert, and there may be bet
I've read 4 messages following this, but I'd like to pursue this a little
to test my own understanding...
At 14:12 30/12/03 +, Joe Thornber wrote:
I was wondering if anyone could give me some help with this problem ?
I'm trying to hold some state in a StateMonad whilst I iterate over a
large
On Wed, Dec 31, 2003 at 11:54:27AM +, Graham Klyne wrote:
> My *intuition* here is that the problem is with countLeaves2, in that it
> must build the computation for the given [sub]tree before it can start to
> evaluate it. Maybe this is why other responses talk about changing the
> state m
At 12:36 31/12/03 +, Joe Thornber wrote:
On Wed, Dec 31, 2003 at 11:54:27AM +, Graham Klyne wrote:
> My *intuition* here is that the problem is with countLeaves2, in that it
> must build the computation for the given [sub]tree before it can start to
> evaluate it. Maybe this is why other r
On Wed, Dec 31, 2003 at 02:38:06PM +, Graham Klyne wrote:
> getOrCachePositionValue pos =
> do { mcache <- gets (findPos pos) -- Query cache for position
>; case mcache of
>Just cached -> return (cachedVal cached) -- Return cached value
>Nothing ->
At 15:37 31/12/03 +, Joe Thornber wrote:
On Wed, Dec 31, 2003 at 02:38:06PM +, Graham Klyne wrote:
> getOrCachePositionValue pos =
> do { mcache <- gets (findPos pos) -- Query cache for position
>; case mcache of
>Just cached -> return (cachedVal cached) -- Ret
On Fri, Jan 02, 2004 at 02:46:04PM +, Graham Klyne wrote:
> If your calculation really needs to update the cache state as it goes
> along, then I agree that it needs to be run in the state monad. But even
> then, I'd be inclined to look for sub-calculations that can be evaluated as
> ordina
11 matches
Mail list logo
