worley@EDDIE.MIT.EDU (Dale Worley) (01/27/89)
From: encore!uokmax!glcowin@Central.Sun.COM (Greg Cowin)
Overlooking the real problem of defining a programming language
seems to be very common. The problem is providing a formal
semantic definition. This problem is not easily solved, although
it can be done.
I beg to differ. Formally defining the semantics of a programming
language isn't as hard as it looks, *provided* you take one of two
approaches. The first is to describe the language entirely in terms
of a set of formal objects. For instance, the Lisp CONS operation can
be described as "Create a new CONS-cell object, whose first item is
the first argument, and second item is the second argument. Return
that object.", CAR is then "Return the first item of the CONS-cell
object which is the argument.", etc. The benefit (and problem) with
this method is that there is no leaking-through of the Von Neumann
machine which is implementing the language. The result is that Lisp
or Scheme programs which don't use I/O and other "known non-portable"
features are very portable.
The second method is to describe a mapping from the language features
into a generalized Von Neumann architecture. This is necessary, for
instance, in Fortran (EQUIVALENCE) and C (pointer arithmetic). This
allows the user to program "closer to the metal", and specify manually
things which an optimizing compiler should be doing for him. Trouble
starts brewing because the "generalized Von Neumann architecture"
usually has lots of unspoken assumptions which turn into gotchas when
someone constructs either hardware or a compiler that violates an
assumption. The ANSI C draft is wrestling with a bunch of them: an
address might not be decrementable, because it could step a pointer
off the beginning of a memory segment; the address of an object may be
representable in several ways, which are not obviously equivalent;
alignment; where padding may be inserted in structures and arrays.
Dale
--
Dale Worley, Compass, Inc. compass!worley@think.com
Seen in a technical journal: "You'll always offend someone when you deal with
a large group of people. There's always someone that can't stand Bambi."
--
Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.EDU
Plausible paths are { decvax | harvard | yale | bbn}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers. Meta-mail to ima!compilers-requeststeve@hubcap.clemson.edu (Steve Stevenson) (01/30/89)
> The second method is to describe a mapping from the language features > into a generalized Von Neumann architecture. Not any longer. In fact, that's probably been part of the problem all along. We kept too close to the obvious pragmatic requirement of writing compilers. Steve (really "D. E.") Stevenson steve@hubcap.clemson.edu fpst@hubcap.clemson.edu Department of Computer Science, (803)656-5880.mabell Clemson University, Clemson, SC 29634-1906 -- Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.EDU Plausible paths are { decvax | harvard | yale | bbn}!ima Please send responses to the originator of the message -- I cannot forward mail accidentally sent back to compilers. Meta-mail to ima!compilers-request