On 8/24/10 3:54 AM, C. McCann wrote:
What sets an iteratee-style design apart from something conventional
based on a State monad is that the iteratee conceals its internal
state completely (in fact, there's no reason an iteratee even has to
be the "same" function step-to-step, or have a single consistent
"state" type--almost has an existential flavor, really), but is at
another function's mercy when it comes to actually doing anything.
All of which doesn't really shed too much light on the denotation of
these things, I suppose, as there's barely anything there to talk
about; the iteratee automaton itself is a terribly simple construct,
relying on an underlying monad to perform actions, on an external
"push" data source to recurse, and being given only bite-size chunks
of data at each step. It's little more than foldl with a "pause"
button attached.
Which was exactly my point about comparing conventional parsers and
iteratees to build/foldr and unfoldr/destroy fusion. Except, I do think
that this sheds some light on what the denotation of iteratees is.
--
Live well,
~wren
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
