I have omitted the chunking [Char] because I don't like it; invariance with respect to the chunk sizes is something that should be left to the iteratee abstraction.
I have this same reservation about iteratees. And related one for enumerators and enumeratees. Assuming my sense of their intended meanings is on track, they allow lots of well-typed but bogus values. Defining and adhering to a precise denotational model would eliminate all of these abstraction leaks, as Luke Palmer alludes to in http://lukepalmer.wordpress.com/2008/07/18/semantic-design/ . - Conal On Mon, Aug 23, 2010 at 4:06 PM, Heinrich Apfelmus < apfelmus@quantentunnel.de> wrote:
Conal Elliott wrote:
For anyone interested in iteratees (etc) and not yet on the iteratees mailing list.
I'm asking about what iteratees *mean* (denote), independent of the various implementations. My original note (also at the end below):
In my world view, iteratees are just a monad M with a single operation
symbol :: M Char
that reads the next symbol from an input stream. In other words, they're a very simple parser monad. The emphasis is not on parsing, but on the fact that one and the same monadic value can be run on different streams
runHandle :: M a -> Handle -> IO a runString :: M a -> String -> a runByteString :: M a -> ByteString -> a
The monad M may also include convenience like exceptions and liftIO .
I have omitted the chunking [Char] because I don't like it; invariance with respect to the chunk sizes is something that should be left to the iteratee abstraction.
Regards, Heinrich Apfelmus
-- http://apfelmus.nfshost.com
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe