[Haskell-cafe] Semantic Domain, Function, and denotational model.....

[Ryan Ingram]

Here's a quick overview that might help you.

For a reactive behavior, we have two types to think about:

type B a = Time -> a
    (the semantic domain)

data Behavior a = ?
    (the library's implementation).
at :: Behavior a -> B a
    (observation function)

This is really just classic "information hiding" as you would do with
any abstract data type.  Consider a simple "stack" data structure that
supports push and pop.

> data S a = S
>     { popS :: Maybe (a, S a)
>     , pushS :: a -> S a
>     }

> data Stack a = ?
> observeStack :: Stack a -> S a

As a library user, you don't really care about the implementation of
Stack, just as a user of Conal's library doesn't really care about the
implementation of Behavior.  What you *do* care about is that you can
think about it in the simpler terms of "Time -> a" which is the model
he has chosen.

The rest of the library design comes from taking that model and
thinking about what typeclasses and operations "Time -> a" should
support, and creating typeclass morphisms between Behavior a and B a
where necessary.  For example:

> -- This makes (r -> a) into a functor over a; it is a generalization of Time -> a
> instance Functor ((->) r) where
>    -- fmap :: (a -> b) -> (r -> a) -> (r -> b)
>    fmap f x = \r -> f (x r)
>    -- or, "fmap = (.)", if you're golfing :)

In order for the morphism between B and Behavior to make sense, you
want this law to hold:
   fmap f (at behavior) = at (fmap f behavior)
for all behavior :: Behavior a.

The fmap on the left applies to B which is (Time ->); the fmap on the
right applies to Behavior.

Conal writes this law more elegantly like this:
> instance(semantic) Functor Behavior where
>    fmap f . at = at . fmap f

As long as you as the user can think about behaviors generally as
functions of Time, you can ignore the implementation details, and
things that you expect to work should work.  This drives the design of
the entire library, with similar morphisms over many typeclasses
between Event and E, Reactive and B, etc.

  -- ryan

On Mon, Sep 15, 2008 at 10:13 AM, Daryoush Mehrtash <dmehrtash at gmail.com> wrote:
> Interestingly, I was trying to read his paper when I realized that I
> needed to figure out the meaning of denotational model, semantic
> domain, semantic functions.  Other Haskell books didn't talk about
> design in those terms, but obviously for him this is how he is driving
> his design.   I am looking for a simpler tutorial, text book like
> reference on the topic.
>
> Daryoush
>
> On Mon, Sep 15, 2008 at 1:33 AM, Ryan Ingram <ryani.spam at gmail.com> wrote:
>> I recommend reading Conal Elliott's "Efficient Functional Reactivity"
>> paper for an in-depth real-world example.
>>
>> http://www.conal.net/papers/simply-reactive
>>
>>  -- ryan
>>
>> On Sun, Sep 14, 2008 at 11:31 AM, Daryoush Mehrtash <dmehrtash at gmail.com> wrote:
>>> I have been told that for a Haskell/Functional programmer the process
>>> of design starts with defining Semantic Domain, Function, and
>>> denotational model of the problem.  I have done some googling on the
>>> topic but haven't found a good reference on it.    I would appreciate
>>> any good references on the topic.
>>>
>>> thanks,
>>>
>>> daryoush
>>>
>>> ps.  I have found referneces like
>>> http://en.wikibooks.org/wiki/Haskell/Denotational_semantics  which
>>> talks about semantic domain for "the Haskell programs 10, 9+1, 2*5"
>>> which doesn't do any good for me.    I need something with a more real
>>> examples.
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>
>>
>