Re: Formal semantics of language semantics

Mark <whopkins@alpha2.csd.uwm.edu> wrote:
>The real problem, as I related in a nearby article, is simply that the
>field is not very well-developed and at this stage in history there is
>still a somewhat illucid attempt to try and cram things that don't
>belong together into a single monolithic formalism, without further
>factoring out


I am with you so far.


>In particular, as related in the last article: control flow is a
>purely syntatic phenomenon that should be factored out at the syntatic
>level before you get to the semantics. A semantics should see nothing
>but pure expressions.


Hmm. "Purely" syntactic? "Nothing but PURE expressions"?


Let's consider an example. Not being a specialist in this area, I
shall use English, but am thinking semi-mathematically.


Routine X has two arguments A and B and the semantic constraint
that they may not be the same.


Routine Y has three arguments P, Q and R, and calls X(P,Q) in one
path and X(Q,R) in another.


Routine Z calls Y(M,N,N) in one place and Y(M,M,N) in another.


The semantics that I am wanting to define is that the path taken
when Z calls Y(M,N,N) may not cause the path that calls X(Q,R) to
be taken and similarly with Y(M,M,N) and X(P,Q).


Now, in the case where this is provably safe, it is quite possible
that the proof involves some quite high-level mathematics. E.g.
the path switches might involve two properties that are related
only through the Extended Riemann Hypothesis.


Can you handle that semantic constraint?




Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email: nmm1@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679

Return to the comp.compilers page.
Search the comp.compilers archives again.