> > 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 < apfel...@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 >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
