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

15 Sep 2008

      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  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  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  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@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe