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