[Haskell-cafe] Fwd: Semantics of iteratees, enumerators,
enumeratees?
Conal Elliott
conal at conal.net
Sun Aug 22 22:03:18 EDT 2010
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):
With the encouragement & help of Conrad Parker, I've been looking at
> iteratees, enumerators, enumeratees. I can find plenty written about them,
> but only about benefits and implementation. In sifting through chunks,
> error/control messages, and continuations, I find myself longing for a
> precise semantic basis. I keep wondering: what simpler & precise semantic
> notions do these mechanisms implement? Has anyone worked out a denotational
> semantics for iteratees, enumerators, enumeratees -- something that
> simplifies away the performance advantages & complexities? I've worked out
> something tentative, but perhaps I'm covering old ground.
>
- Conal
---------- Forwarded message ----------
From: Conal Elliott <conal at conal.net>
Date: Sun, Aug 22, 2010 at 11:02 PM
Subject: Re: Semantics of iteratees, enumerators, enumeratees?
To: John Lato <jwlato at gmail.com>
Hi John,
I just remembered: Luke Palmer wrote an accessible & helpful description of
this approach to library design. See his post *Semantic
Design<http://lukepalmer.wordpress.com/2008/07/18/semantic-design/>
*.
(I've switched to using the more specific term "denotational design", since
I specifically intend denotational semantics, not operational.)
Denotational design is at the heart of most of what I do, particularly
including the three pieces of work you mentioned: functional images (Pan),
FRP, and automatic differentiation.
My main goal is simplicity with precision. Without the precision, I can't
tell whether the simplicity is real or illusory.
We functional programmers have a strong advantage over imperative
programming (including OO) in that we can achieve semantic precision. I
want to see us exploit this advantage! And not settle for being a power
tool for generating semantically inscrutable imperative computations.
Regards,
- Conal
On Sun, Aug 22, 2010 at 10:43 PM, John Lato <jwlato at gmail.com> wrote:
> Hi Conal,
>
> I've always regarded your work in essentially the same category as Edward
> Kmett's (and most of Oleg's): stuff that's incredible powerful and concise,
> but I can't understand at all what it means. I've admired a lot of your
> work, particularly on Pan, FRP, and automatic differentiation, but most of
> the rest I couldn't understand at all.
>
> I'll take a look at your *Denotational Design* paper again; maybe now that
> I have a lot more experience I'll be able to make sense of it.
>
> John
>
>
> On Sun, Aug 22, 2010 at 8:18 AM, Conal Elliott <conal at conal.net> wrote:
>
>> Hi John,
>>
>> Thanks for the reply. A denotational semantics would be independent of
>> any implementation, so it would apply to any of them, as long as they have
>> the same programming interface. The purpose is to simply & precisely say
>> what the types and their building blocks (API) mean by providing a precise,
>> implementation-independent, and simple-as-possible math model. Such a
>> semantics can be used to prove properties and to define correctness of any
>> implementation. It also gives clear feedback on how elegant or inelegant a
>> library design is.
>>
>> For instance, given a type, Map k v, of finite maps, we might say the
>> meaning is the type of partial functions from k to v, either k -> v (where
>> absent is _|_) or k -> Maybe v (where absent is Nothing). Then we'd give
>> the meaning of each Map operation as a function of the meanings of its
>> arguments. This example and several others are given in the paper *Denotational
>> design with type class morphisms<http://conal.net/papers/type-class-morphisms/>
>> *.
>>
>> Regards, - Conal
>>
>> On Sun, Aug 22, 2010 at 8:31 PM, John Lato <jwlato at gmail.com> wrote:
>>
>>> Hi Conal,
>>>
>>> To my knowledge, nobody has attempted this. Oleg may have some ideas,
>>> but I don't think he's written about it. I really don't know anything about
>>> denotational semantics, so I couldn't do this myself. For some time I've
>>> thought it would be good if somebody were able to put together a formal
>>> semantics for iteratees, so I'd be very interested if you'd share what you
>>> have so far.
>>>
>>> Would a denotational semantics apply equally to multiple implementations,
>>> or would it be tied to a specific implementation?
>>>
>>> John
>>>
>>> On Sun, Aug 22, 2010 at 3:47 AM, Conal Elliott <conal at conal.net> wrote:
>>>
>>>> With the encouragement & help of Conrad Parker, I've been looking at
>>>> iteratees, enumerators, enumeratees. I can find plenty written about them,
>>>> but only about benefits and implementation. In sifting through chunks,
>>>> error/control messages, and continuations, I find myself longing for a
>>>> precise semantic basis. I keep wondering: what simpler & precise semantic
>>>> notions do these mechanisms implement? Has anyone worked out a denotational
>>>> semantics for iteratees, enumerators, enumeratees -- something that
>>>> simplifies away the performance advantages & complexities? I've worked out
>>>> something tentative, but perhaps I'm covering old ground.
>>>>
>>>> - Conal
>>>>
>>>> _______________________________________________
>>>> Iteratee mailing list
>>>> Iteratee at projects.haskell.org
>>>> http://projects.haskell.org/cgi-bin/mailman/listinfo/iteratee
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100822/96d5db82/attachment-0001.html
More information about the Haskell-Cafe
mailing list