So long as the [s] is a fixed list (say [1,2,3,4]) there is no space
leak.My understanding was that the space leak only happens if there is
computation involved in building the list of s. Am I correct?
If so, I still don't have any feeling for what needs to be saved on the heap
to be
There's still the space used by the closure b.
An example:
expensiveParser :: Parser Char ExpensiveStructure
simple :: Parser Char Int
withExpensive :: ExpensiveStructure - Parser Char Int
withExpensive _ = mzero -- actually always fails, not using its argument.
example = do
e -
I (think) I understand the problem. What I don't have any intuition about
is how much space would Expensive Structure take if it was basically an
IO Char computation fed into a simple function (say checks for char being
equal to a). Is there any way to guess, know the size of the buffer that
In Section 2.5 of Generalizing Monads to Arrows paper
(linkhttp://www.cs.chalmers.se/%7Erjmh/Papers/arrows.ps)
John Huges talks about the space leak inherit in monadic implementation of
backtracking parsers.
newtype Parser s a = P( [s] = Maybe (a, [s]))
instance MonadPlus Parser where
P
On Tue, May 26, 2009 at 5:03 PM, Daryoush Mehrtash dmehrt...@gmail.com wrote:
newtype Parser s a = P( [s] - Maybe (a, [s]))
(fixed typo)
instance MonadPlus Parser where
P a mplus P b = P (\s - case a s of
Just (x, s') - Just (x, s')
