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