[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
TI position (long message)
Received: from ti-csl by csnet-relay.csnet id ab06137; 17 Oct 84 10:29 EDT
Date: 16 Oct 1984 1740-CDT
From: David Bartley <Bartley@TI-CSL>
Subject: TI "Position paper"
Received: from csl60 by ti-csl; Wed, 17 Oct 84 07:41 CST
Via: RAND-relay; 17 Oct 84 9:53-EST
Will, here is a copy of the current TI-CSL (Computer Science Lab) position
going into the SCHEME meeting next week. I had hoped to get it to you
before you mailed out your agenda, but I don't think there is any harm
done. Feel free to distribute it to the other participants. Thanks!
-- David Bartley [Bartley@TI-CSL]
TI-CSL Position on "Standardizing" SCHEME
Texas Instruments is actively using SCHEME as an educational tool,
systems programming language for AI and database architectures, and in
research into the principles of programming languages and computer
architectures. We have found the MIT videotape course and the recent
book by Abelson and Sussman to be an excellent way to "rehabilitate"
software developers within TI. Our experience so far shows that
first-class functions and continuations are elegant and efficient
mechanisms for expressing control for operating systems and simulation
studies. We also are studying a "core" SCHEME which is suitable as an
intermediate representation for other languages, including Common LISP,
Pascal, and Prolog.
Our philosophy on "standardizing" SCHEME at this time is as follows.
MIT SCHEME has become a de facto standard within TI for educational
purposes. Nearly a hundred programmers have taken the MIT course
within TI during the last year or so, and there is already a demand for
MIT SCHEME language support on our various computer facilities. On the
other hand, our systems programming and research work has been with
Indiana University's SCHEME 84. We are convinced that SCHEME (or at
least a recognised "core") must remain a simple and elegant yet
powerful and expressive language. Thus, we hope to reach agreement on
at least those aspects of the language which are addressed in the MIT
videotapes and book, while agreeing to cooperate on incorporating other
aspects as they become mature.
As a developer and manufacturer of products based on LISP, TI is
determined to give full support to Common LISP. It is important to the
success of SCHEME at TI that trivial incompatibilities between SCHEME
and Common LISP be eliminated. This policy will also make it easier to
develop a Common LISP system on top of SCHEME.
We are committed to making SCHEME a first-class language throughout
TI by developing first-class production quality implementations. To
achieve this, we are prepared to invest in extensive compiler
development work. Our perspective on "efficiency" is this: we intend
to discover what architectural features are required to support
languages appropriate for solving problems, not to tailor languages to
the capabilities of current machines. On the other hand, it is
imperative that we implement SCHEME efficiently on machines as small as
As a research tool, our dialect of SCHEME will certainly diverge from
other SCHEME implementations. (For example, we are investigating
unification and multiple dynamic inheritance.) However, we are very
eager to help establish a portable basis for the language. Such a
basis should be constructed on a solid core of key concepts which
together distinguish SCHEME from other languages, plus mechanisms for
extending the base language. Portable programs can then carry their
syntax with them, if necessary.
We are encouraging this process for several reasons. First, aligning
the dialects of SCHEME is a giant step towards building a larger
community of SCHEME users and fans. A large user base is needed before
we can expect a steady flow of quality software written in SCHEME.
Second, a large, unified community can give SCHEME the credibility
needed to co-exist with Common LISP and the other "name" languages.
Third, TI is eager to build and strengthen ties with universities and
other research organizations and individuals.
The following sections of this paper briefly outline our opinions
about various aspects of the design of the SCHEME language. Many of
these topics are not yet mature enough to be standardized.
Abbreviations: CL=Common LISP, IUS=Indiana SCHEME 84, MITS=MIT SCHEME
(7th ed.), T=T (4th ed.), ZL=ZetaLISP.
This is an area where compatibility with CL is critical. For
example, alphabetic case should not be significant. However, the
characters '!' and '?' should be first-class constituents.
Generally speaking, we support the current convention in which a
suffix '!' indicates side-effecting, suffix '?' indicates (pure?)
predicates, infix '->' indicates coercions, etc.
However, we hope to avoid trivial incompatibilities between SCHEME
and CL. Allowing more than one name for the same thing may be
acceptable, particularly as we migrate users away from our current
SEMANTICS OF CONSTANTS
The semantics of the names NIL and T must be clarified. If the
name NIL is given special meaning by READ and PRINT (that is, both
(FOO . NIL) and (FOO) read the same way) then NIL should not be
merely a standard variable.
We see no way to avoid the traditional interpretation that '() is
both the empty list and the FALSE value.
SEMANTICS OF VARIABLES
We are unhappy with the concept of a single global environment as
it currently exists in IUS and most LISPs. Several mechanisms for
explicitly managed environments have been proposed. We would like
to see a proposal that includes persistent objects and ZL/CL-style
We have several problems with the nature of DEFINE in MITS.
Unfortunately, this is one of the most visible aspects of the
language in the MIT course and book. We prefer the use of LET or
LETREC/LABELS (see below) for extending the lexical environment.
Binding/creation should be clearly distinguished from assignment
and the scope should be clearly visible; DEFINE looks too much like
assignment and has confusing semantics. Likewise, we tend to the
view that SET! should not create new bindings.
We prefer the name LETREC to LABELS; regardless, the values bound
definitely should NOT be restricted to be LAMBDA expressions. This
might be thought worthwhile if it guaranteed that the bindings were
all compile-time only, but SET! prevents that. Also, it would
rule out such innocent cases as the following.
(letrec ((foo (let ((private-var 4))
(lambda (arg) body))))
We have several concerns about namespace issues for fluids, NIL and
T, and syntactic elements of the language (keywords, macros):
True DYNAMIC binding should be implemented using a name space of
fluid identifiers which is DISJOINT from lexicals. Special forms
to fetch, set, and bind fluids can distinguish the names via
syntax. We prefer FLUID, FLUID-SET!, and FLUID-LET operations.
FLUID-LAMBDA can be defined in terms of LAMBDA plus FLUID-LET.
As mentioned above, NIL seems to be a distinguished name for the
constant '(), since the reader and printer presumably treat them
interchangeably. Treating the same name NIL as both a data item
and a "standard variable" is confusing (but marginally acceptable).
We prefer to think of such constants as immutable and therefore
closer in spirit to parameterless macros than to variables.
The case for the name T is much weaker; T is not treated specially
by the reader or printer; its use as a non-NIL value is more a
convention than a required language feature. We'd like to see
special-casing of T removed from the language (cf. comments on
Regardless of the decision on T and NIL, the meaning of the
following should be specified:
(eq? T 'T) (eq? NIL 'NIL)
(symbol? T) (symbol? NIL)
(set! T x) (set! NIL x)
(lambda (T)...) (lambda (NIL) ...)
(T x y z) (NIL x y z)
We have conducted a debate with IU for some time on how to
distinguish syntactic elements (macros) from ordinary names
(variables) while using the same lexical rules to construct
instances of each. I think we are agreed that the two sets of
names must be disjoint, but we have not agreed on what to do when
new bindings involve names previously bound in the other namespace.
This dilemma strikes at the heart of lexical scoping in SCHEME.
Its solution will also require an answer to the problems of global
variables and multiple environments.
For esthetic and pragmatic reasons, we would like to find a
solution that involves only local contextual information, in the
spirit of lexical scoping. This would allow pretty-printers and
screen editors to display more of the meaning of a program fragment
to a user.
SEMANTICS OF PROCEDURES
Wherever possible, operations should return meaningful (or at least
consistent) values. We suggest the following as examples:
(set! a b) ==> b
(exchange a b) ==> b ; from similarity to set!
(print a) ==> a
(newline) ==> nil
As users, we appreciate the notational convenience of n-ary
procedures -- MULAMBDA in IUS and the "dotted rest" parameter in T
and MITS. We also think destructuring binds (e.g. T's DESTRUCTURE)
can be useful. But we are concerned that we may lose the ability
to reason mechanically about programs (e.g. type inference) the
further SCHEME gets from its roots in the lambda calculus.
We also feel that MITS has been overzealous in allowing such
primitives as '>' to take an arbitrary number of arguments. When
practically every common function takes an arbitrary number of
arguments, it is hard to detect certain common user errors.
SEMANTICS OF SPECIAL FORMS
Syntactic extensions to SCHEME should obey lexical scoping rules,
but must be distinct from lexical variable bindings.
SET! should be generalized to include the semantics of SETF (CL).
(Similarly for DEFINE, if it is an assignment operation instead of
a binding operation.)
We should avoid defining special forms that gratuitously
side-affect the user's namespace by reserving words in certain
ways. For example, ELSE is treated specially by COND in MITS and
IUS and in CASE by IUS and T. Why not teach 'T or 'ELSE for COND
or use IF instead? For CASE, we prefer the following syntax:
(case1 . body1)
(case2 . body2)
ELSE . body)
(uppercase is used only to distinguish terminal from non-terminal
At TI, SCHEME will eventually have to support all of the data types
of CL and other languages.
A distinguished UNBOUND type and ways to set and test for it are
needed. It is not clear which references to an unbound value
should cause an exception.
Similarly, we intend to support IEEE floating point and its
Upward continuations are a MUST for our purposes.
We need to find ways to recognize downward-only continuations and
We need to decide what UNWIND-PROTECT means in the general case.
We are interested in dealing with atomic transactions in SCHEME.
UNDOing a transaction is similar to invoking a continuation but has
It may help us achieve portability of SCHEME programs if we can
relegate groups of functions to optional libraries. With any luck,
we'll be able to write the libraries themselves (or less efficient
but more portable versions of them) in a standard subset of the
language. I/O and extended MATH functions should probably be
handled this way.
COND, CASE, and IF should NOT "fall through" when no cases apply.
An atom comparison primitive is needed, such as EQV? (MITS) or
EQUIV? (T). It should probably be identical to CL's EQL.
CASE should use EQV? or EQUAL? instead of EQ? Optimizing compilers
can reduce the strength of the test for individual cases.
We would like to explore ways to embed comments in the internal
representation of source programs. We have considered ZL-style
documentation strings and treating ';' as an infix operator.
-- David Bartley, 16 October 1984, 1500ct [Bartley@TI-CSL]