TI position (long message)

[Will Clinger <willc%indiana.csnet@csnet-relay.arpa>]

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]
-------