hn-classics/_stories/1984/14459278.md

---
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'
year: 1984

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