Semantic Domain, Function, and denotational model.....

Daryoush,
Hopefully, the other replies about proving the monad laws already answered
your previous question: yes!
As for notions of semantic domain and denotational model, these ideas go
back quite a ways; but, were given solid footing by Dana
Scotthttp://en.wikipedia.org/wiki/Dana_Scott.
In a nutshell, we have essentially three views of a computation
- Operational http://en.wikipedia.org/wiki/Operational_semantics --
computation is captured in a program and rules for executing it
- Logical http://en.wikipedia.org/wiki/Proof-theoretic_semantics --
computation is captured in a proof and rules for normalizing it
- Denotational http://en.wikipedia.org/wiki/Denotational_semantics --
computation is captured as a (completely unfolded) mathematical structure
In the latter view we think of computations/programs as denoting some
(usually infinitary) mathematical object. Our
aimhttp://en.wikipedia.org/wiki/Domain_theoryis to completely define
the meaning of programs in terms of maps between
their syntactic representation and the mathematical objects their syntax is
intended to denote. (Notationally, one often writes such maps as [| - |] :
Program -> Denotation.) For example, we model terms in the lambda calculus
as elements in a D-infinity domain or Bohm trees or ... . Or, in more modern
parlance, we model terms in the lambda calculus as morphisms in some
Cartesian closed category, and the types of those terms as objects in said
category. The gold standard of quality of such a model is full
abstractionhttp://en.wikipedia.org/wiki/Denotational_semantics#Full_abstraction--
when the denotational notion of equivalence exactly coincides with an
intended operational notion of equivalence. In symbols,
- P ~ Q <=> [| P |] = [| Q |], where ~ and = are the operational and
denotational notions of equivalence, respectively
The techniques of denotational semantics have been very fruitful, but
greatly improved by having to rub elbows with operational characterizations.
The original proposals for denotational models of the lambda calculus were
much too arms length from the intensional structure implicit in the notion
of computation and thus failed to achieve full abstraction even for toy
models of lambda enriched with naturals and booleans (cf the so-called full
abstraction for PCF
problemhttp://en.wikipedia.org/wiki/Programming_language_for_Computable_Functions).
On the flip side, providing a better syntactic exposure of the use of
resources -- ala linear logic -- aided the denotational programme.
More generally, operational models fit neatly into two ready-made notions of
equivalence
- contextual
equivalencehttp://encyclopedia2.thefreedictionary.com/Contextual+equivalence--
behaves the same in all contexts
- bisimulation http://en.wikipedia.org/wiki/Bisimulation -- behaves the
same under all observations
Moreover, these can be seen to coincide with ready-made notions of
equivalence under the logical view of programs. Except for syntactically
derived initial/final denotational models -- the current theory usually
finds a more "home-grown" denotational notion of equivalence. In fact, i
submit that it is this very distance from the syntactic presentation that
has weakened the more popular understanding of "denotational" models to just
this -- whenever you have some compositionally defined map from one
representation to another that respects some form of equivalence, the target
is viewed as the denotation.
Best wishes,
--greg
Date: Mon, 15 Sep 2008 10:13:53 -0700
From: "Daryoush Mehrtash"
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
-- L.G. Meredith Managing Partner Biosimilarity LLC 806 55th St NE Seattle, WA 98105 +1 206.650.3740 http://biosimilarity.blogspot.com

I noticed that Wikipedia has listed a few text books on the topic:
http://en.wikipedia.org/wiki/Denotational_semantics#Textbooks
Any recommendations on which one might be a "better" read?
Thanks,
Daryoush
2008/9/16 Greg Meredith
Daryoush,
Hopefully, the other replies about proving the monad laws already answered your previous question: yes!
As for notions of semantic domain and denotational model, these ideas go back quite a ways; but, were given solid footing by Dana Scott. In a nutshell, we have essentially three views of a computation
Operational -- computation is captured in a program and rules for executing it Logical -- computation is captured in a proof and rules for normalizing it Denotational -- computation is captured as a (completely unfolded) mathematical structure
In the latter view we think of computations/programs as denoting some (usually infinitary) mathematical object. Our aim is to completely define the meaning of programs in terms of maps between their syntactic representation and the mathematical objects their syntax is intended to denote. (Notationally, one often writes such maps as [| - |] : Program -> Denotation.) For example, we model terms in the lambda calculus as elements in a D-infinity domain or Bohm trees or ... . Or, in more modern parlance, we model terms in the lambda calculus as morphisms in some Cartesian closed category, and the types of those terms as objects in said category. The gold standard of quality of such a model is full abstraction -- when the denotational notion of equivalence exactly coincides with an intended operational notion of equivalence. In symbols,
P ~ Q <=> [| P |] = [| Q |], where ~ and = are the operational and denotational notions of equivalence, respectively
The techniques of denotational semantics have been very fruitful, but greatly improved by having to rub elbows with operational characterizations. The original proposals for denotational models of the lambda calculus were much too arms length from the intensional structure implicit in the notion of computation and thus failed to achieve full abstraction even for toy models of lambda enriched with naturals and booleans (cf the so-called full abstraction for PCF problem). On the flip side, providing a better syntactic exposure of the use of resources -- ala linear logic -- aided the denotational programme.
More generally, operational models fit neatly into two ready-made notions of equivalence
contextual equivalence -- behaves the same in all contexts bisimulation -- behaves the same under all observations
Moreover, these can be seen to coincide with ready-made notions of equivalence under the logical view of programs. Except for syntactically derived initial/final denotational models -- the current theory usually finds a more "home-grown" denotational notion of equivalence. In fact, i submit that it is this very distance from the syntactic presentation that has weakened the more popular understanding of "denotational" models to just this -- whenever you have some compositionally defined map from one representation to another that respects some form of equivalence, the target is viewed as the denotation.
Best wishes,
--greg
Date: Mon, 15 Sep 2008 10:13:53 -0700 From: "Daryoush Mehrtash"
Subject: Re: [Haskell-cafe] Semantic Domain, Function, and denotational model..... To: "Ryan Ingram" Cc: Haskell Cafe Message-ID: Content-Type: text/plain; charset=ISO-8859-1
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
-- L.G. Meredith Managing Partner Biosimilarity LLC 806 55th St NE Seattle, WA 98105
+1 206.650.3740
http://biosimilarity.blogspot.com
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Daryoush,
The two chapters in the Handbook of Logic in Computer Science -- especially
the one http://www.cs.bham.ac.uk/%7Eaxj/pub/papers/handy1.pdf by Abramsky
and Jung -- are good. i noticed that Lloyd Allison wrote a book on
practical denotational semantics. i've never read it, but i was intrigued by
his work using minimal message length as the basis for a generic framework
in Haskell for machine-learning models. He might have something useful to
say.
It is difficult to judge what would be a good book for you, however, because
i don't know if you what your aim is. Do you want context, history and
mathematical foundations or a quick way to understanding enough FP-speak to
write better commercial code? As i said, a lot of people loosely speak of
the *target* of some compositionally defined function (usually based on some
structural recursion) that preserves some operational notion of equality as
the denotation. This is almost certainly what is going on in the references
you cited early. You can kind of leave it at that.
On the other hand, if you wish to go deeper, the study of the meaning of
programs is highly rewarding and will change the way you think. One
particularly fruitful place is games semantics. Guy McCusker's PhD thesis
might be a way in. Abramsky and Jagadeesan's papers might be a way in. As i
said before, the places where denotational and operational semantics have
had to rub elbows has been useful to both approaches. One of the hands down
best characterizations of the relationship of the logical and operational
view of computation is Abramsky's Computational Interpretations of Linear
Logic http://www.comlab.ox.ac.uk/people/samson.abramsky/cill.ps.gz. In
this paper Samson repeats the same process 3 times --
1. specifies a logic by giving syntax for formulae and proof rules
2. derives a term language (syntax of programs) and operational semantics
that is sound w.r.t a type system given by the logical formulae
3. derives a virtual machine for the term language
4. refines the logic by an analysis of where the logic fails to capture
our intuitions about resources -- looping back to step 1
The starting point is Intuitionistic Logic which yields the core of a
standard functional language. The next iteration is Intuitionistic Linear
Logic, which yields a linear FPL. The next iteration is Classical Linear
Logic which yields a concurrent language. Following the development of this
process will clarify the relationships between the logical and operational
view -- which ultimately bear on reasonable interpretations of denotational
interpretations.
If you make the step to say that the denotation must be the completely
unfolded structure -- the tree of reductions, the collection of possible
plays, etc -- then there are ways to see how these views logical,
operational and denotational are all calculable from one another -- and why
you might want to have all of them in any complete account of computation.
Best wishes,
--greg
On Wed, Sep 17, 2008 at 11:03 AM, Daryoush Mehrtash
I noticed that Wikipedia has listed a few text books on the topic:
http://en.wikipedia.org/wiki/Denotational_semantics#Textbooks
Any recommendations on which one might be a "better" read?
Thanks,
Daryoush
Daryoush,
Hopefully, the other replies about proving the monad laws already answered your previous question: yes!
As for notions of semantic domain and denotational model, these ideas go back quite a ways; but, were given solid footing by Dana Scott. In a nutshell, we have essentially three views of a computation
Operational -- computation is captured in a program and rules for executing it Logical -- computation is captured in a proof and rules for normalizing it Denotational -- computation is captured as a (completely unfolded) mathematical structure
In the latter view we think of computations/programs as denoting some (usually infinitary) mathematical object. Our aim is to completely define the meaning of programs in terms of maps between their syntactic representation and the mathematical objects their syntax is intended to denote. (Notationally, one often writes such maps as [| - |] : Program -> Denotation.) For example, we model terms in the lambda calculus as elements in a D-infinity domain or Bohm trees or ... . Or, in more modern
2008/9/16 Greg Meredith
: parlance, we model terms in the lambda calculus as morphisms in some Cartesian closed category, and the types of those terms as objects in said category. The gold standard of quality of such a model is full abstraction -- when the denotational notion of equivalence exactly coincides with an intended operational notion of equivalence. In symbols,
P ~ Q <=> [| P |] = [| Q |], where ~ and = are the operational and denotational notions of equivalence, respectively
The techniques of denotational semantics have been very fruitful, but greatly improved by having to rub elbows with operational characterizations. The original proposals for denotational models of the lambda calculus were much too arms length from the intensional structure implicit in the notion of computation and thus failed to achieve full abstraction even for toy models of lambda enriched with naturals and booleans (cf the so-called full abstraction for PCF problem). On the flip side, providing a better syntactic exposure of the use of resources -- ala linear logic -- aided the denotational programme.
More generally, operational models fit neatly into two ready-made notions of equivalence
contextual equivalence -- behaves the same in all contexts bisimulation -- behaves the same under all observations
Moreover, these can be seen to coincide with ready-made notions of equivalence under the logical view of programs. Except for syntactically derived initial/final denotational models -- the current theory usually finds a more "home-grown" denotational notion of equivalence. In fact, i submit that it is this very distance from the syntactic presentation that has weakened the more popular understanding of "denotational" models to just this -- whenever you have some compositionally defined map from one representation to another that respects some form of equivalence, the target is viewed as the denotation.
Best wishes,
--greg
Date: Mon, 15 Sep 2008 10:13:53 -0700 From: "Daryoush Mehrtash"
Subject: Re: [Haskell-cafe] Semantic Domain, Function, and denotational model..... To: "Ryan Ingram" Cc: Haskell Cafe Message-ID: Content-Type: text/plain; charset=ISO-8859-1
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 < dmehrtash@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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- L.G. Meredith Managing Partner Biosimilarity LLC 806 55th St NE Seattle, WA 98105
+1 206.650.3740
http://biosimilarity.blogspot.com
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- L.G. Meredith Managing Partner Biosimilarity LLC 806 55th St NE Seattle, WA 98105 +1 206.650.3740 http://biosimilarity.blogspot.com
participants (2)
-
Daryoush Mehrtash
-
Greg Meredith