main :: MMap k v -> MMap kk vv

Dictionary lookups on a key block until that key arrives in the dictionary.

lookup :: MMap k v -> k -> v

Sometimes you want to wait on all keys at the same time, and produce a result. This form accomplishes this:

mapp :: MMap k v -> (k -> v -> MMap kk vv) -> MMap kk vv

The only caveat is that if mapp ever detects that the result of the function for two key-value pairs disagree at a key, it must signal an error.

All destruction actions are pushed to the top level of the model. The option to delete input records can be provided. If a record is deleted, all computations that depended on its existence can be automatically recomputed.

I admit I was hoping you’d covered this base already in your work or knew someone who did :-).

I’m not sure I have a good enough sense of what you mean by a “precise denotation” to come up with one.

I can think of some of my own approaches to the problem, and I may try some experiments to see what works out in practice, but I’m not sure if they are going to be as “good” as the procedural version.

For example, if the input is given as a list of lines of text and the output is given as a list of lines, then one could have a function from input lines to output lines. Like:

    prog [] = ["What is your name?"]
    prog [name] = (prog []) ++ ["Hello, " ++ name ++ "!  How old are you?"]
    prog [name, age] = (prog [name]) ++ ["Well, you look much younger..."]

Presumably I can devise a function from time to a list of input lines, and pass that into this function to get the output lines.

I know this approach has major flaws, but is this an example of what you mean by casting something in terms of denotation?

printLine "What is your name?"
name ← readLine
printLine "Hello, " ++ name ++ "! How old are you?"
age ← readLine
printLine "Well, you look much younger..."

Is FRP unsuitable for this kind of application?

Did you somehow get the impression that I have a bias against monads? If so, how?

Many of my best friends are monads (e.g. (partially applied) pairings, functions, Maybe, Future, backtracking, …). These friends are all denotative. They have precise & tractable meanings I can work with. In contrast, there are non-denotative types, like IO. And while IO happens to be a Monad, it’s also a Functor, Applicative, Monoid (when applied to a Monoid), and even a Num (when applied to a Num)! These classes don’t hinder or help denotative-ness.

My goal here is to remind people of the quest of denotative programming and hopefully inspire some curiosity and creative exploration of new denotative alternatives to Haskell’s IO.

Btw, it was mildly ironic that in your talk you had to resort to textual notation to describe the constructs behind Eros That is somewhat like asking for the visual equivalent of the understanding that lists, maybe and IO are in some sense “the same”.

The download link at http://www.haskell.org/haskellwiki/Eros is broken.