358 lines
15 KiB
Markdown
358 lines
15 KiB
Markdown
---
|
|
created_at: '2017-06-01T10:54:30.000Z'
|
|
title: Texas Instruments on Scheme (1984)
|
|
url: https://groups.csail.mit.edu/mac/ftpdir/scheme-mail/HTML/rrrs-1984/msg00010.html
|
|
author: soegaard
|
|
points: 65
|
|
story_text:
|
|
comment_text:
|
|
num_comments: 13
|
|
story_id:
|
|
story_title:
|
|
story_url:
|
|
parent_id:
|
|
created_at_i: 1496314470
|
|
_tags:
|
|
- story
|
|
- author_soegaard
|
|
- story_14459278
|
|
objectID: '14459278'
|
|
|
|
---
|
|
[Source](https://groups.csail.mit.edu/mac/ftpdir/scheme-mail/HTML/rrrs-1984/msg00010.html "Permalink to TI position (long message)")
|
|
|
|
# TI position (long message)
|
|
|
|
* * *
|
|
|
|
[[Date Prev][1]][[Date Next][2]][[Thread Prev][1]][[Thread Next][2]][[Date Index][3]][[Thread Index][4]]
|
|
|
|
# TI position (long message)
|
|
|
|
* * *
|
|
* _To_: [scheme%mit-mc.arpa@csnet-relay.arpa][5]
|
|
* _Subject_: TI position (long message)
|
|
* _From_: Will Clinger <[willc%indiana.csnet@csnet-relay.arpa][6]>
|
|
* _Date_: Wed, 17 Oct 84 13:42:40 est
|
|
* * *
|
|
|
|
|
|
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"
|
|
To: willc@INDIANA
|
|
cc: Bartley@TI-CSL
|
|
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
|
|
|
|
David Bartley
|
|
|
|
|
|
Our Goals
|
|
|
|
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
|
|
8088-based micros.
|
|
|
|
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.
|
|
|
|
|
|
LEXICAL CONVENTIONS
|
|
|
|
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.
|
|
|
|
|
|
NAMING CONVENTIONS
|
|
|
|
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
|
|
dialects.
|
|
|
|
|
|
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
|
|
packages.
|
|
|
|
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))))
|
|
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
|
|
ELSE, below).
|
|
|
|
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:
|
|
|
|
(CASE exp
|
|
(case1 . body1)
|
|
(case2 . body2)
|
|
...
|
|
ELSE . body)
|
|
|
|
(uppercase is used only to distinguish terminal from non-terminal
|
|
symbols)
|
|
|
|
|
|
DATA TYPES
|
|
|
|
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
|
|
'not-a-number' values.
|
|
|
|
|
|
CALL/CC
|
|
|
|
Upward continuations are a MUST for our purposes.
|
|
|
|
We need to find ways to recognize downward-only continuations and
|
|
optimize them.
|
|
|
|
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
|
|
other ramifications.
|
|
|
|
|
|
LIBRARIES
|
|
|
|
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.
|
|
|
|
|
|
MISCELLANEOUS
|
|
|
|
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]
|
|
-------
|
|
|
|
|
|
|
|
|
|
* * *
|
|
* Prev by Date: [**Revised invitation list][1]**
|
|
* Next by Date: [**Scheme Conference Participants][2]**
|
|
* Prev by thread: [**Revised invitation list][1]**
|
|
* Next by thread: [**Scheme Conference Participants][2]**
|
|
* Index(es):
|
|
* [**Date**][3]
|
|
* [**Thread**][4]
|
|
|
|
[1]: https://groups.csail.mit.edu/msg00009.html
|
|
[2]: https://groups.csail.mit.edu/msg00011.html
|
|
[3]: https://groups.csail.mit.edu/maillist.html#00010
|
|
[4]: https://groups.csail.mit.edu/threads.html#00010
|
|
[5]: mailto:scheme%25mit-mc.arpa%40csnet-relay.arpa
|
|
[6]: mailto:willc%25indiana.csnet%40csnet-relay.arpa
|
|
|