Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!decwrl!jumbo!ehs
From: ehs@jumbo.dec.com (Ed Satterthwaite)
Newsgroups: comp.lang.misc
Subject: Re: Xerox PARC's Cedar (long)
Summary: more Mesa/Cedar history
Message-ID: <13770@jumbo.dec.com>
Date: 27 May 89 04:36:43 GMT
References: <17504@mimsy.UUCP> <2309@cpoint.UUCP>
Organization: DEC Systems Research Center, Palo Alto
Lines: 94

I've tried to stay out of this thread of postings, but maybe it's time to
add a little more history.  I wrote major parts of the Mesa and Cedar
compilers (pre 1986 versions) and also take some of the credit and blame
for the language designs.  I have not worked for Xerox since 1986, nor am
I currently active in the area of programming language or compiler design.
I hear rumors that there is now a version of the Cedar compiler that has
been liberated from Xerox' proprietary machine architectures.  I otherwise
have no knowledge of the current state of the system or of Xerox' plans
for distribution.

Mesa is a so-called systems implementation language.  It was originally
developed in the Computer Science Laboratory of Xerox PARC for programming
the Alto, but it arrived a little too late to completely displace BCPL for
that purpose.  There were several generations of Mesa.  The first version
was weakly typed and let the underlying hardware show through.  Subsequent
versions were strongly typed and tried to abstract away from the hardware
a bit more.  Although the syntax looks a lot like Pascal, the semantic
models underlying Mesa are much closer to Algol 68 (a much underrated
language) than to Pascal.  The only major area in which we followed Pascal
instead of Algol 68 (variant records instead of unions) caused us no end
of subsequent grief.

Mesa has a strongly developed notion of modules that separate interface
definition and implementation, similar to Modula-2 or Ada.  It preceded
both of those; in fact, Modula-2 appeared after Klaus Wirth had spent a
sabbatical period at PARC and used Mesa to write a nifty system for
interactive collaboration on design drawings.  Other significant features
of Mesa include language support for lightweight processes (generally
successful), coroutines and exceptions (in retrospect, too grandiose and
baroque).  It supports "object-oriented" programming for a number of
definitions of that term.  It does not, however, have subclassing, except
by programmer convention and controlled breaches of the type system, so I
do not consider it a true OOP language.

To my knowledge, there is no good documentation of the Mesa language.
Despite some valiant efforts to patch it up over the years, the manual is
a disaster.  Here are some references that try to convey the flavor, but
they are incomplete and obsolescent:

Geschke, Morris & Satterthwaite, Early experience with Mesa, Comm. ACM,
  August 1977, 540-533.

Lauer & Satterthwaite, The impact of Mesa on system design.  Proc. 4th
  International Conference on Software Eng., Sept. 1979, 174-182.

Aside from providing some general intellectual stimulation, Smalltalk and
Mesa did not have much influence on one another.  Smalltalk did pioneer a
lot of ideas about user interfaces and styles of interaction that later
showed up in Mesa-coded applications.

Mesa was subsequently ported to a series of Xerox workstations with
heavily microcoded architectures, the so called D-machines (Dolphin,
Dorado, Dandelion, etc.), some of which were marketed under 110x numbers.
The language was adopted by various engineering and development groups
within Xerox, most notably the ones that produced what became Star,
Viewpoint, MDE, etc.  To my knowledge, Mesa was used for programming the
controller of only one high-end copier.  By almost all measures, the code
was considered less satisfactory than the code written for a similar
copier in PDP-11 assembly language (a provocative result, although other
variables make it meaningless to draw strong conclusions from this).

"Cedar" is the name of both an integrated programming environment (base
system, language, support tools, set of conventions, libraries and
packages, etc.) and the language used in that environment.  The former was
described by a long paper in TOPLAS several years ago; I don't have the
reference handy.  The latter is an extension of Mesa.  Significant
additions are automatic garbage collection and a dynamic type system based
on the notion of a universal reference (pointer) type, REF ANY.  Other
postings have discussed the merits, or lack thereof, of garbage
collection; I sometimes found it very useful but tended to wave it off in
most of my own "serious" programming.  REF ANY was an attempt to combine
the best features of statically and dynamically typed languages.  IMHO, it
ended up achieving the worst of both worlds instead.  It's unfortunate
that Modula-2+ and Modula-3 have retained REF ANY, especially since the
latter doesn't really seem to need it.  In Cedar, REF ANY was widely used
in the standard interfaces, often in ugly ways that turned static errors
into dynamic ones.  Its presence was also an excuse to avoid tackling
polymorphism in any really satisfactory way.

Most of the other Cedar extensions migrated back into Mesa.  By
then, Mesa had accumulated a lot of fairly ugly warts and barnacles.  It
would have been nice to expunge those from Cedar, but nearly all were
retained as "deprecated features" for backward compatibility.  Again,
there was no really satisfactory documentation when I left in 1986.  The
best approximation is a Xerox technical report:

A Description of the Cedar Language, Butler Lampson, CSL-83-15,
  December 1983

but it's pretty heavy going, and the underpinnings presented in the first
few sections would now be done rather differently.

Ed Satterthwaite
ehs@src.DEC.COM / {...}!decwrl!ehs