perm filename COMSCH[SCH,LSP] blob sn#772847 filedate 1984-10-25 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00007 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	 Common Scheme Messages
C00006 00003	∂15-Oct-84  2159	@MIT-MC:willc%indiana.csnet@csnet-relay.arpa 	questions for workshop (long message)  
C00029 00004	∂15-Oct-84  2202	@MIT-MC:willc%indiana.csnet@csnet-relay.arpa 	feature list for workshop (long message)    
C00047 00005	∂17-Oct-84  2245	@MIT-MC:willc%indiana.csnet@csnet-relay.arpa 	TI position (long message)   
C00068 00006	∂20-Oct-84  0746	@MIT-MC:brooks%indiana.csnet@csnet-relay.arpa 	Environments and Macros
C00088 00007	∂22-Oct-84  1307	MEEHAN@YALE.ARPA 	T blurb
C00091 ENDMK
C⊗;
;;; Common Scheme Messages

∂15-Oct-84  2156	@MIT-MC:willc%indiana.csnet@csnet-relay.arpa 	agenda for workshop
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 15 Oct 84  21:56:06 PDT
Received: from indiana by csnet-relay.csnet id ag08264; 16 Oct 84 0:36 EDT
Date: Mon, 15 Oct 84 20:24:56 est
From: Will Clinger <willc%indiana.csnet@csnet-relay.arpa>
Message-Id: <8410160124.AA11707@iuvax.UUCP>
To: scheme%mit-mc.arpa@csnet-relay.arpa
Subject: agenda for workshop

Agenda for workshop on Scheme.


First day.

Distribution of agenda, list of questions, list of features, and
supporting materials.  [10 minutes]

Moderator's statement of purpose and procedure.  [20 minutes]

Straw poll using list of questions.  [1 hour]

Nominations of new questions to be added to the list.  [30 minutes]

Discussion of questions.  [4 hours]

    nil, t, and else				[15 minutes]
    lexical conventions				[10 minutes]
    scope rules for keywords of special forms	[20 minutes]
    names of special forms			[10 minutes]
    semantics of constants			[5 minutes]
    semantics of definitions			[20 minutes]
    semantics of fluid variables		[5 minutes]
    ontology of variables			[15 minutes]
    semantics of special forms			[10 minutes]
    macros					[30 minutes]
    input and output				[30 minutes]
    naming conventions				[5 minutes]
    procedures					[5 minutes]
    numbers					[15 minutes]
    symbols					[5 minutes]
    lists					[10 minutes]
    strings					[5 minutes]
    vectors					[5 minutes]
    new topics added by the participants	[20 minutes]

Identification of research areas that need more work and
discussion of research under way.  [2 hours]



Second day.

Final vote on list of questions.  [3 hours]

Discussion of list of features.  [2 hours]

    lexical features		[25 minutes]
    special variables		[5 minutes]
    special forms		[30 minutes]
    data types			[15 minutes]
    procedures			[30 minutes]
    input and output		[15 minutes]

Final vote on list of features.  [2 hours]

Arrangements for future coordination.  [1 hour]

∂15-Oct-84  2159	@MIT-MC:willc%indiana.csnet@csnet-relay.arpa 	questions for workshop (long message)  
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 15 Oct 84  21:58:15 PDT
Received: from indiana by csnet-relay.csnet id ah08264; 16 Oct 84 0:36 EDT
Date: Mon, 15 Oct 84 20:27:55 est
From: Will Clinger <willc%indiana.csnet@csnet-relay.arpa>
Message-Id: <8410160127.AA11758@iuvax.UUCP>
To: scheme%mit-mc.arpa@csnet-relay.arpa
Subject: questions for workshop (long message)

List of questions to be considered at the workshop.



----------------------------------------------------------------
		       Nil, t, and else...

Should (nil) be the same as (()) ?

Should () evaluate to the same thing as '() ?

Should nil evaluate to the same thing as () ?

Should nil evaluate to the same thing as '() ?

Should 'nil evaluate to the same thing as nil ?

Should nil be a symbol?

If nil should be a symbol, should its evaluation semantics be
those of a: 
    static constant
    lexical constant
    lexical variable

Should 't evaluate to the same thing as t ?

Should t be a symbol?

If t should be a symbol, should its evaluation semantics be those
of a:
    static constant
    lexical constant
    lexical variable

Should else be a:
    noise word recognized by certain special forms
    static constant
    lexical constant
    lexical variable

----------------------------------------------------------------
		     Lexical conventions...

Should the following characters be alphabetic?

	[ ] { }

If they are not alphabetic, what are they?

Should symbols be converted to upper case unless slashified?

Should slashification be indicated by backslash for single
characters, as in \" ?

And by enclosure in vertical bars for entire symbols, as in |"| ?

Should abc|def|g be the same symbol as abcdefg?

For the #\ character syntax, which of the following are the
correct choices?

	#\SP		#\SPACE		(ascii " ")
	#\DOT		#\PERIOD	(ascii ".")
	#\LF		#\NEWLINE	(ascii "
						")
	#\CR

	none of the above

Unreadable objects should be printed as
    #{...}
    #<...>
    something else

Is the #!... syntax a good idea for miscellaneous objects?

----------------------------------------------------------------
	  Scope rules for keywords of special forms...

Should the keywords of special forms have global or lexical scope?

Should the keywords of special forms be shadowed by lambda-binding?

Should the keywords of special forms be shadowed by local syntax
definitions?

Should the keyword of a special form be assigned using set! ?

What should happen when the keyword of a special form appears
other than in the car position of a form?

----------------------------------------------------------------
		    Names of special forms...

Should it be

	(lambda x ...)
or
	(mulambda x ...) ?

Should it be

	(lambda (a b . c) ...)
or
	(mumulambda (a b . c) ...)
or
	something else altogether?

For each of the following sets of names of special forms, choose
the better:

	{ labels, letrec }
	{ and, conjunction }			; also { disjunction, or }
	{ define, define!, defrec, defrec! }	; meaning IU's defrec
	{ define, define!, lset }		; for variables
	{ set, set! }
	{ do, step }
	{ begin, block, sequence }
	{ bind, fluid-let }

----------------------------------------------------------------
		    Semantics of constants...

Which of the following should evaluate to themselves?

	nothing
	numbers
	strings
	characters
	everything except symbols and conses

Side effects to quoted constants should
    be ok
    be an error
    signal an error

If side effects to quoted constants are ok, then should
structured constants be freshly consed?

----------------------------------------------------------------
		   Semantics of definitions...

For the define special form, should (define (foo ...) ...) be
equivalent to (define foo (lambda (...) ...)) ?

Should (define ((foo ...) ...) ...) be equivalent to
(define (foo ...) (lambda (...) ...)) ?  Et cetera?

Should

	(define (foo x)
	  (define (bar y) ...)
	  (define (baz z) ...)
	  ...)

be closer in its semantics to

	(define (foo x)
	  (letrec ((bar (lambda (y) ...))
	  	   (baz (lambda (z) ...)))
	    ...))

or to

	(define (foo x)
	  (set! bar (lambda (y) ...))
	  (set! baz (lambda (z) ...))
	  ...)

Assuming the first answer on the previous question, should
embedded definitions be required to come first in a definition,
or should

	(define (foo x)
	  (print (bar 3))
	  (define (bar y) ...)
	  (foo (+ x 1)))

be legal?

If embedded definitions are not required to come first in a
definition, what should their semantics be?

Assuming embedded definitions are required to come first in a
definition, should embedded definitions be allowed in a lambda?
In other words, should

	(mapcar (lambda (x)
		  (define (bar y) ...)
		  (define (baz z) ...)
		  ...)
		...)

be legal?

What value should be returned by a define form?

----------------------------------------------------------------
		 Semantics of fluid variables...

Should
	(let ((x 3))
	  (fluid-let ((x 4))
 	    x))

evaluate to 3 or to 4?

----------------------------------------------------------------
		    Ontology of variables...

Should lexical variables be the only kind of variable,
semantically speaking?

If there are semantically important variables other than lexical
variables, then which of the following kinds of variables should
there be:

	fluid variables
	locale variables
	global variables
	base variables
	other kinds of variables

----------------------------------------------------------------
		  Semantics of special forms...

Cond clauses should have:
    exactly two forms
    two or more forms
    one or more forms

If no cond clause is selected, then:
    the value of the cond expression should be nil
    it should be an error
    an error should be signalled

Each pattern of a case clause should consist of:
    a value (on which eq? is meaningfully defined)
    a value or list of values

If no case clause is selected, then:
    the case expression should return nil
    it should be an error
    an error should be signalled

In the following transcript, what should happen?

>>>(define foo (lambda (n) (if (0? n) t (foo (1- n)))))
foo
>>>(define bar foo)
bar
>>>(bar 3)
t
>>>(define foo (lambda (x) (list x)))
foo
>>>(bar 3)
???				; t or (2)?

Should set (set!) have the setf feature?

The do (step) special form should have:
    exactly one return form
    one or more return forms (all but the last are executed for effect)
    zero or more return forms (if zero, then the value of the
        test is returned)

Should it be permissible to omit update expressions for do (step)
variables?

(begin) should
    return nil
    be an error
    signal an error    

----------------------------------------------------------------
			    Macros...

Does anybody have a syntax and semantics for macros that is good
enough and stable enough that we should consider committing
ourselves to it for a period measured in years?

----------------------------------------------------------------
		       Input and output...

The following programs prompt for input, read input, print output
to a file, and then repeat the cycle.  These examples are
intended to illustrate incompatibilities between the various
implementations in the matter of input and output.

; T (fourth edition)

(define main
  (labels ((get-list
            (lambda ()
              (display "Please give me a list to reverse: " (standard-output))
              (read (standard-input)))))
    (lambda (filename)
      (let ((output (open filename '(out))))
        (do ((list (get-list) (get-list)))
            ((null? list) (close output))
            (print (reverse list) output)
            (newline output))))))

; MIT Scheme (seventh edition)

(define (main filename)
  (define (get-list)
    (princ "Please give me a list to reverse: ")
    (read))
  (define output (open-printer-channel filename))
  (define (loop list)
    (if (null? list)
        (close-channel output)
	(sequence (print (reverse (list)) output))
		  (loop (get-list)))))
  (loop (get-list)))

; Scheme 312 Version -3.00

(define main
  (letrec ((get-list
            (lambda ()
              (printstring "Please give me a list to reverse: ")
              (read))))
    (lambda (filename)
      (let ((output (outfile filename)))
        (do ((list (get-list) (get-list)))
            ((null? list) (close output))
            (print (reverse list) output)
            (newline output))))))

; Scheme 84 Version 0.5

(define main
  (letrec ((get-list
            (lambda ()
              (print "Please give me a list to reverse: ")
              (read))))
    (lambda (filename)
      (let ((output (open filename 'write)))
        (do ((list (get-list) (get-list)))
            ((null? list) (close output))
	    (fluid-let ((output-port output))
              (display (reverse list))
              (newline)))))))

Is the Scheme 84 idea of routing all I/O through fluid
identifiers a good one?

How should the following basic I/O operations be done?

Read an object from the standard input:

	(read (standard-input))
	(read)

Print an object to the standard output, with slashification:

	(print object (standard-output))	; T
	(prin1 object)				; MIT Scheme
	(display object)			; Scheme 84

Print an object to the standard output, without slashification:

	(display object (standard-output))	; T
	(princ object)				; MIT Scheme
	(print object)				; Scheme 84

Print a string to the standard output, without the double quotes.

	(write-string (standard-output) object)	; T
	(princ object)				; MIT Scheme
	(printstring string)			; Scheme 312
	(print object)				; Scheme 84

Write an end of line to the standard output:

	(newline (standard-output))
	(newline)

Read a character from the standard input:

	(read-char (standard-input))		; T
	(tyi)					; MIT Scheme
	(tyi %conin)				; Scheme 312
	(read-char)				; Scheme 84

Peek at a character from the standard input:

	(block0 (read-char (standard-input))
		(unread-char (standard-input)))
	(peekch)
	(tyipeek)

Write a character to the standard output:

	(write-char (standard-output) char)	; T
	(tyo char)				; MIT Scheme
	(tyo char %conout)			; Scheme 312

Open a file for input:

	(open filename '(in))			; T
	(open-reader-channel filename)		; MIT Scheme
	(infile filename)			; Scheme 312
	(open filename 'read)			; Scheme 84

Open a file for output:

	(open filename '(out))			; T
	(open-printer-channel filename)		; MIT Scheme
	(outfile filename)			; Scheme 312
	(open filename 'write)			; Scheme 84

Close an open file:

	(close object)
	(close-channel channel)

Test for end of file on an open input file:

	(block0 (eof? (read-char stream))
		(unread-char stream))
	(let ((eof '(eof)))
	  (eq? (peekch channel eof) eof))
	(=? (tyipeek port) -1)

Test if an object that has been read is the end of file:

	(eof? object)
	(eq? object EOF)

Pretty print an object on the standard output:

	(pretty-print object (standard-output))	; T
	(pp object)				; MIT Scheme
	(pretty-print object)			; Scheme 312

Pretty print (some approximation to) the definition of a
procedure on the standard output:

	(pp name-of-procedure)			; T
	(pp procedure)				; MIT Scheme
	(pretty '(name-of-procedure))		; Scheme 312, Scheme 84

Generate wallpaper:

	(transcript-on filename)		; T, Scheme 84
	(photo filename)			; MIT Scheme

Stop generating wallpaper:

	(transcript-off)			; T, Scheme 84
	(tofu)					; MIT Scheme

----------------------------------------------------------------
		      Naming conventions...

Are the T naming conventions for procedures acceptable?

Should the names of variables whose values are not procedures or
whose value is intended to change begin and end with asterisks,
with t and nil as exceptions to the rule?

----------------------------------------------------------------
			  Procedures...

Should various sorts of procedures be distinguishable at run
time?  (E.g. primitives, system functions, continuations,
fluid-closures, closures, engines.)

Which is the better name?

	{ procedure?, proc?, applicable? }

----------------------------------------------------------------
			   Numbers...

Should various sorts of numbers be distinguishable at run time?
(E.g. fixnums, bignums, ratios, floats, complexes.)

Which is the better name?

	{ integer?, fix? }
	{ -1+, 1- }
	{ subtract1, sub1 }
	{ div, quotient, / }
	{ =, =? }
	{ <, <? }
	{ >, >? }
	{ >=, >=? }
	{ <=, <=? }
	{ =0?, 0?, =0 }
	{ <0?, <0 }
	{ >0?, >0 }
	{ N=0?, <>0?, <>0, !=0?, !=0, not=0?, nonzero? }
	{ atan, arctan }
	{ atan2, atan }		; two arguments
	{ ->integer, fix }
	{ ->float, float, floor, ceiling, truncate, round }

Should trigonometric functions take their arguments in radians?

----------------------------------------------------------------
			   Symbols...

Which is the better name?

	{ symbol->string, pname }
	{ concatenate-symbol, concat }
	{ alphaless?, alpha< }
	{ generate-symbol, generate-uninterned-symbol, gensym }
	
----------------------------------------------------------------
			    Lists...

Which is the better name?

	{ pair?, cons? }
	{ proper-list?, list? }		; true if cdr of last cons is nil
	{ alikev?, equal? }
	{ nth, list-ref }
	{ nthcdr, list-tail }
	{ lastcdr, last, last-pair }
	{ map, mapcar }
	{ walk, mapc }

Taking the car or cdr of nil should:
    yield nil
    be an error
    signal an error

atom? is true of what things?

----------------------------------------------------------------
			   Strings...

Which is the better name?

	{ list->string, list-to-string }
	{ string->list, string-to-list }

----------------------------------------------------------------
			   Vectors...

Which is the better name?

	{ list->vector, list-to-vector }
	{ vector->list, vector-to-list }
	{ vector-elt, vector-ref }
	{ vset, vector-set! }
	{ vector-length, vector-size }

∂15-Oct-84  2202	@MIT-MC:willc%indiana.csnet@csnet-relay.arpa 	feature list for workshop (long message)    
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 15 Oct 84  22:01:44 PDT
Received: from indiana by csnet-relay.csnet id ai08264; 16 Oct 84 0:39 EDT
Date: Mon, 15 Oct 84 20:30:54 est
From: Will Clinger <willc%indiana.csnet@csnet-relay.arpa>
Message-Id: <8410160130.AA11798@iuvax.UUCP>
To: scheme%mit-mc.arpa@csnet-relay.arpa
Subject: feature list for workshop (long message)

List of features to be considered at the workshop.

For each of the following features (e.g. special forms, data types,
and procedures) should the feature be

    essential -- every implementation of Scheme must have it.
        Programs written in Essential Scheme will run on any
        implementation of Scheme worthy of the name.

    optional -- not every implementation of Scheme will have it,
        but all implementations that have the feature will use
        the same syntax and semantics for the feature.  Code that
        makes use of optional features will run on any
        implementation of Scheme that supplies the optional
        features.

    extended -- not every implementation of Scheme will have it,
        and the feature's syntax and semantics may vary even
        among implementations that have the feature.  Code that
        makes use of extended features is not portable.  (E.g. at
        the moment input and output is an extended feature.)

----------------------------------------------------------------

Lexical features

The space character is a whitespace character.
The tab character is a whitespace character.
The newline character is a whitespace character.
The carriage return character is a whitespace character.
The line feed character is a whitespace character.
The form feed character is a whitespace character.

Any whitespace character is a delimiter.
Left parenthesis is a delimiter.
Right parenthesis is a delimiter.
Left bracket is a delimiter.
Right bracket is a delimiter.
Left curly brace is a delimiter.
Left parenthesis is a delimiter.
Right curly brace is a delimiter.
Semicolon is a delimiter.
Single quote is a delimiter.
Double quote is a delimiter.
Backquote is a delimiter.
End of file is a delimiter.

Backslash is an escape character.

Lists are opened by left parentheses and closed by right
parentheses.

When notating lists, matching left and right brackets are
stylistic alternatives to matching left and right parentheses.

Conses may be notated as (x . y), where y is any object.

Possibly improper lists may be notated as (... x . y).

Strings are delimited by double quotes.

Double quotes may be included inside strings by escaping them.

Quote marks have the meanings we have grown to know and love.

Backquote and comma work as we are accustomed.

With a backquoted list, comma at-sign works as we are accustomed.

Comments are opened by semicolons and closed by end of line
characters.

Sharp sign macros are introduced by a sharp sign.

Unreadable objects are printed using sharp sign notation.  (We
need to agree whether the notation is #{...} or #<...>.)

Vectors may be written using sharp sign notation.  (We need to
agree whether the notation is #(...) or something else.)

Binary numbers may be written using the #b notation.

Octal numbers may be written using the #o notation.

Decimal numbers may be written using the #d notation.

Hexadecimal numbers may be written using the #x notation.

Special characters may be written using the #\ notation.  (We
need to agree on the names for the special characters using this
notation.)

Miscellaneous objects may be written using the #[...] syntax.

Miscellaneous objects may be written using the #! syntax.

Integers may be written in the usual way, with or without signs.

Floating point numbers may be written using decimal points.  (We
need to agree on the notation.)

Floating point numbers may be written using exponents.  (We need
to agree on the notation.)

Symbols may be written as sequences of characters that contain no
special characters and begin with a character that cannot begin a
number.

Sequences of characters containing no special characters are
interpreted as numbers if possible; if not possible they are
interpreted as symbols.

When the 26 letters of the alphabet are used to write a symbol,
case is immaterial unless the letter is slashified.

----------------------------------------------------------------

Special variables (constants?)


nil evaluates to the empty list.

nil evaluates to some false value.

t evaluates to some true value.

else evaluates to some true value.

----------------------------------------------------------------

Special forms


quote

lambda (with a proper list of bound variables)

lambda (with a symbol in place of a list of bound variables)

lambda (with a possibly improper list of bound variables)

lambda (with destructuring -- we need to agree on pattern syntax)

mulambda

let

let*

labels or letrec

rec

named-lambda

if

cond

case

and or conjunction

or or disjunction

locale

make-environment

the-environment

access

defrec (such that (defrec i e) means (define i (rec i e)))

define (with what semantics?)

set or set!

do or step

iterate

block or sequence or begin

block0 or begin0

catch (with dynamic extent restriction)

catch (without dynamic extent restriction)

throw

delay (memoized)

force (memoized)

freeze (not memoized)

thaw (not memoized)

locative

fluid-lambda

fluid

fluid-set!

fluid-let or bind

fluid-bound?

dynamic-wind

unwind-protect

define-constant

define-integrable

define-syntax or ...

----------------------------------------------------------------

Data types


The essential data types are disjoint.

There is an object nil that represents false and the empty list.

Procedures are a kind of object.

Numbers are a kind of object.

Symbols are a kind of object.

Pairs (conses?) are a kind of object.

Structures are a kind of object.

Characters are a kind of object.

Strings are a kind of object.

Vectors are a kind of object.

Bytevectors are a kind of object.

Streams (channels?  ports?) are a kind of object.

Locales (environments?) are a kind of object.

Syntax tables are a kind of object.

Macros are a kind of object.

Locatives (refs?) are a kind of object.

----------------------------------------------------------------

Procedures


NULL?		NULL?		null?		null?
		NIL?
NOT		NOT		not		not


PROCEDURE?	APPLICABLE?	procedure?	proc?
APPLY		APPLY		apply		apply
call-with-current-continuation			call/cc


NUMBER?		NUMBER?		number?		number?
INTEGER?	INTEGER?			fix?
RATIO?
FLOAT?						float?
ODD?		ODD?
EVEN?		EVEN?
1+		1+		1+
ADD1				add1		add1
-1+		-1+		1-
SUBTRACT1			sub1		sub1
+ (...)		+ (...)		+ (2)		+ (2)
				plus (...)
- (2)		- (...)		- (2)		- (2)
- (1)				-- (1)		minus (1)
* (...)		* (...)		* (2)		* (2)
				times (...)
/		/ (...)				/
DIV		QUOTIENT	/		/
REMAINDER	REMAINDER	remainder	remainder
MOD
		INTEGER-DIVIDE
ABS		ABS		abs		abs
GCD		GCD
MIN (...)	MIN (...)	min (...)	min (...)
MAX (...)	MAX (...)	max (...)	max (...)
		random (1)			random (1)
=		=		=?		=
EQUAL?
<		<		<?		<
LESS?
>		>		>?		>
GREATER?
N=
NOT-EQUAL?
>=		>=		>=?		>=
NOT-LESS?
<=		<=		<=?		<=
NOT-GREATER?
=0?				0?		=0
ZERO?		ZERO?
<0?						<0
NEGATIVE?	NEGATIVE?
>0?						>0
POSITIVE?	POSITIVE?
N=0?
NOT-ZERO?
>=0?
NOT-NEGATIVE?
<=0?
NOT-POSITIVE?
EXP		EXP				exp
LOG		LOG				log
EXPT		EXPT				expt
SQRT		SQRT				sqrt
SIN		SIN				sin
COS		COS				cos
TAN		TAN				tan
ASIN						arcsin
ACOS						arccos
						arctan
ATAN2		ATAN
LOGAND				logand
LOGIOR				logior
LOGXOR				logxor
LOGNOT				lognot
				lsh
				rot
ASH
BIT-FIELD
SET-BIT-FIELD
->INTEGER					fix
->FLOAT						float
		FLOOR
		CEILING
		TRUNCATE
		ROUND

All trigonometric functions take their arguments in radians.


SYMBOL?		SYMBOL?		symbol?		symbol?
EQ?		EQ?		eq?		eq?
NEQ?
SYMBOL->STRING			pname
		ascii				symbol->ascii
STRING->SYMBOL
CONCATENATE-SYMBOL				concat
		ALPHALESS?	alphaless?	alpha<
		EXPLODE				explode
		IMPLODE				implode
GENERATE-SYMBOL	GENERATE-UNINTERNED-SYMBOL
				gensym		gensym


PAIR?		PAIR?		cons?		pair? (?)
ATOM?		ATOM?		atom?		atom? (?)
LIST?
PROPER-LIST?	LIST?
ALIKE?
ALIKEQ?
ALIKEV?		EQUAL?		equal?		equal?
CONS		CONS		cons		cons
LIST		LIST		list		list
CONS*		LIST*
COPY-LIST
						copy
CAR		CAR		car		car
CDR		CDR		cdr		cdr
C....R		C....R		c..r		c...r
NTH		LIST-REF			nth
NTHCDR		LIST-TAIL
		NTH
		NTHCDR
LAST
LASTCDR		LAST				last-pair
		FIRST
		SECOND
		THIRD
		FOURTH
		FIFTH
		SIXTH
		SEVENTH
		EIGHTH
		SET-CAR!	set-car!	set-car!
		SET-CDR!	set-cdr!	set-cdr!
LENGTH		LENGTH		length		length
APPEND (...)	APPEND (>=2)	append (2)	append (>=2)
APPEND! (...)					append! (>=2)
REVERSE		REVERSE		reverse		reverse
REVERSE!					reverse!
SUBLIST
SUBST
SUBSTQ
SUBSTV
						subst
COPY-TREE
MEM?
MEMQ?
		MEMQ		memq		memq
		MEMV
		MEMBER		member		member
ASS
ASSQ		ASSQ		assq		assq
		ASSV
		ASSOC		assoc		assoc
ANY?
EVERY?
DEL
DELQ
DEL!
DELQ!						delq!
						delete!
MAP		MAPCAR		mapcar		mapcar
MAPCDR
MAP!
WALK		MAPC		mapc		mapc
WALKCDR
TREE-HASH

The car of nil is nil.

The cdr of nil is nil.


STRING?				string?		string?
				string-equal?
		ALPHALESS?	alphaless?	alpha<

MAKE-STRING
STRING-APPEND
COPY-STRING
CHAR->STRING
LIST->STRING			list-to-string
STRING->LIST			string-to-list
STRING-LENGTH
STRING-EMPTY?
STRING-ELT
NTHCHAR
 et cetera


VECTOR?		VECTOR?		vector?
				vector-equal?
MAKE-VECTOR
		VECTOR
		VECTOR-CONS	vector-cons
LIST->VECTOR			list-to-vector
VECTOR->LIST			vector-to-list
VECTOR-ELT	VECTOR-REF	vector-ref
VREF
VSET		VECTOR-SET!	vector-set!
COPY-VECTOR
VECTOR-FILL
VECTOR-REPLACE
VECTOR-LENGTH	VECTOR-SIZE	vector-length
VECTOR-POS
VECTOR-POSQ
WALK-VECTOR

----------------------------------------------------------------

Input and output


All input and output is routed through the stream to which
certain distinguished variables are bound.

There is a way to read an object from the standard input.

There is a way to write objects to the standard output, with
slashification.

There is a way to write objects to the standard output, without
slashification.

There is a way to write a string to the standard output, without
the double quotes.

There is a way to write an end of line to the standard output.

There is a way to read a character from the standard input.

There is a way to peek at a character from the standard input.

There is a way to write a character to the standard output.

There is a way to open a file for input.

There is a way to open a file for output.

There is a way to close an open file.

There is a way to test for end of file on an open input file.

There is a way to test if an object that has been read is the end
of file.

There is a way to pretty print an object on the standard output.

There is a way to pretty print some approximation to the
definition of a procedure on the standard output.

There is a way to generate a transcript file.


∂17-Oct-84  2245	@MIT-MC:willc%indiana.csnet@csnet-relay.arpa 	TI position (long message)   
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 17 Oct 84  22:44:41 PDT
Received: from indiana by csnet-relay.csnet id ae03417; 18 Oct 84 1:23 EDT
Date: Wed, 17 Oct 84 13:42:40 est
From: Will Clinger <willc%indiana.csnet@csnet-relay.arpa>
Message-Id: <8410171842.AA05383@iuvax.UUCP>
To: scheme%mit-mc.arpa@csnet-relay.arpa
Subject: 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"
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]
-------


∂20-Oct-84  0746	@MIT-MC:brooks%indiana.csnet@csnet-relay.arpa 	Environments and Macros
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 20 Oct 84  07:46:11 PDT
Received: from indiana by csnet-relay.csnet id a004289; 20 Oct 84 10:32 EDT
Date: Sat, 20 Oct 84 09:14:01 est
From: Gary Brooks <brooks%indiana.csnet@csnet-relay.arpa>
Message-Id: <8410201414.AA06193@iuvax.UUCP>
To: scheme%mit-mc.arpa@csnet-relay.arpa
Subject: Environments and Macros

Previously, there has been a debate between Chris Haynes, David Bartley
and myself (Gary Brooks) as to the nature of environment structure in
Scheme and its interaction with macros.

We disagree with almost all of what David Bartley said and much, if not
all of what Chris Haynes said.  Not only do we disagree with the
principles that were advocated in their proposals, we are horrified by
their complexity.  Instead of analyzing each proposal on a point by point
basis, we propose yet another framework that we contend is simple and
straightforward, and allows one to express the type of things one wants to.


Namespaces
----------

First a bit of nomenclature.  The term 'namespace' has been bandied
around a lot in the last few notes.  But what is a namespace?  As far as
I can tell, it is just an association of identifiers to values, or, in
other words an environment!  Why use two words when one will do?  Don't --
**poof** no more namespaces, just environments.


The Environment Problem
-----------------------

The environment problem is concerned with determining the environment in which
an identifier (symbol) is to be interpreted.  In the following       
discussion, reserved words are viewed as constituting an
environment which is given priority over other environments.

The crux of the problem, which can be found in Scheme84 as well as the
two other proposals, is the proliferation of environments.  For example,
if we examine Scheme84 we find that we have a (core) reserved word
environment, a global macro environment, a global primitive environment, a
global environment for everything else, a lexical environment, and a
fluid environment.  When the environment of an identifer is not textually
specified (as it is for fluids), problems arise when we try to determine the
precedence of each environment in the process of interpreting an
identifier.

The problem of determining environment precedence is further aggrevated
by making preferencing (scope rules) dependent on the position of an
identifer in an application, as the two prior proposals advocated.
For example, in Scheme84, the reserved word and the macro environments
are given precedence for identifiers in functional position.  However,
the lexical and global (initial lexical) environment are given precedence
in argument positions.  The complicated and unintuitive scope rules
resulting from position sensitive precedence is intolerable.

Usually, non free identifiers are interpreted globally (i.e.  in the
initial lexical environment).  If, while looking up identifiers, we give
priority to any of the other global environments (e.g.  macro) over that
of lexical scope (which was advocated in previous proposals), we
contaminate our notion of lexical scope.  Given the elegance and
simplicity of the traditional lambda calculus based lexical scoping, this
type of preferencing is a "feature" we are reluctant to incorporate.

In general, no matter what preferencing scheme one adopts in the presence
of multiple global environments, too many rules are needed.  However, if
we simply abolish the proliferation of global environments and rely
solely on lexical scope (augmented with an initial lexical environment,
which we view as containing a binding for all possible identifiers) we
can avoid the problems encountered by preferencing environments.

This immediately raises the question of how macros, primitives, core
items, etc.  are distinguished.  We proprose that they be distinguished
by type (i.e.  we introduce a new kind of typed object for each class of
items).  This emphasizes the point that the name of some entity is not
important, the type of an entity is!  From a compiler's point of view,
determining whether an identifier is a macro, primitive, or core item is
simple.  The compiler need only check the type of (the binding of)
each free identifier in the initial environment.

Some may object to this scenario on the grounds that it allows an
identifier bound to an item of one type (e.g.  macros, primitives, and core
items) to be redefined to be another type.  In particular, some people
are concerned that a crucial macro (e.g.  let) may be redefined as
something else (e.g.  a closure).  I contend that this redefinition
problem is mistakenly concerned with the type of object being redefined.
For example, even if the appropriate machinery prohibited the
redefinition of someone's favorite macro as a closure, there would still
be no conceivable way of preventing his favorite macro from being
redefined as another totally random macro.  Furthermore, one might
reasonably want to redefine a macro as a closure to, say, effect a
different space/time tradeoff.

Multiple Initial Environments:
------------------------------

A related environment problem is how one accounts for the multiple
"global" (initial) environments required in large scale software systems.
While there is much controversy on this issue, we propose a simple
framework that provides for multiple initial environments and allows for
user specified (programmed) inheritance between them.  The perspective
that we advocate is based on the principle that the relationship between
a free identifier and its L-value is determined at compile-time.  We
model initial environments as maps between free identifiers and L-values.
The compiler interface is modified by requiring the compiler to take an
additional argument, an initial environment.  

We point out that this scenerio allows for most inheritance schemes
(e.g. packages) by simply constructing a new environment out of existing
ones.  However, this scenario does prohibit dynamic (i.e., runtime)
resolution of free identifiers.  For those who desire such capabilities,
we advocate treating them in a manner similar to fluids, but not to
conflate them with initial environments.   For example, someone who
desires to create a Unix-like shell environment for an operating system
need only define the relevant macros for defining and side-effecting such
"shell" variables.


Binding and variable Injection
------------------------------

Lexical identifer problems arise when a lexical identifier or a lexical
identifier binding is injected into an existing lexical contour within a
code segment as the result of a macro expansion.  

Variable injection:

In the first case, a macro may inject an identifier into an existing lexical 
contour.  While this may be the desired intension, often it is not.  For
example, consider the following code fragment:

		(lambda (and)
		   (frob a b d))

It is transformed (via the macro frob) to:

		(lambda (and)
		   (and a (or b d)))

Note that what is (presumably) a reference to the global macro 'and' in the
definition of frob has been shadowed by the lambda variable 'and' in a
user program.  In such a case, we say that the injected variable 'and' is
captured by an existing binding.

The problem is centered on the injection of the symbol 'and' into the
lambda body.  Using the normal lexical/global lookup of a symbol we don't
get the binding of 'and' which the macro writer intended.  To see why, we
must look at the way macros are defined.  Consider the definition of frob:
(We use typed macros as advocated above.  Also, 'macro' is like lambda, but
constructs a macro object instead of a closure.)

	(define frob
	   (macro (x y z)
		  `(and ,x (or ,y ,z))))
	
While this might look ok, it suffers from the injected variable problem.
The cause of the problem is the quotation of 'and'.  I contend that when
the macro writer writes the macro (macro definition time), he/she expects
the value of 'and' to be the value of 'and' in the macro environment
(i.e.  the environment when the macro 'frob' is expanded).  Since, in
past versions of Lisp or Scheme, macros have not been typed objects,
there has been no way to do this properly.

However, if we allow the injection of typed objects directly into a piece
program "text" (structure), we can avoid the aforementioned capturing
problem.  To do so only requires the compiler to recognize semantic
objects, like closures or macros, as constants (i.e., we inject semantic
domains into the syntatic domains).  We can then achieve the macro
writers intension by writing frob as:

	(define frob
	   (macro (x y z)
		  `(,and ,x (,or ,y ,z))))

In this case the global binding of 'and' (presumably a macro object) at
the time the macro is invoked, and NOT the symbol 'and', will be included
in the transformed code, thus avoiding this category of variable capture

For those who object to the predominance of commas in the definition of
'frob', let me postulate four new reader macros:

	↑  Constructs the corresponding list, but evaluates its
	   atomic subcomponents.
	,  Used to evaluate non-atomic subcomponents (i.e. an
	   application).
	`  When used inside the scope of a "↑", inhibits evaluation 
	   of the following (atomic) subcomponent.
	@  Splices the following subcomponent into a list.

Frob could thus be written as:

	(define frob
	   (macro (x y z)
		  ↑(and x (or y z))))

Lastly, we point out that the technique of including semantic domains in
syntatic domains has merit in its own right.  It is crucial in order to
define macros which require data structures injected into the code, as in
the definition of own variables or evaluate-once.  It is also useful
in inserting macro "help" functions directly into macro-expanded code, so
as to share code between different macro-expansions of the same macro.
We believe that this technique of "higher-dimensional programming" has
much to offer, but has, to date, barely been explored.

Binding injection:

A similar problem arises when a lexical binding is injected into an
existing lexical context because of a macro expansion.  Consider the
following two argument version of the macro or:

		(define or
		   (macro (exp1 exp2)
			  `(let [[v ,exp1]]
			      (if v v ,exp2))))
		
This works fine, unless the second expression passed to or is 'v'.  In
this case:


		(lambda (v)
		   (or exp1 v))

expands to:

		(lambda (v)
		   (let [[v exp1]]
		      (if v v v)))


We then say the user variable v (i.e., exp2) is captured by
the injected binding of v by the macro.  We point out that such captures
may actually be desired,  although this technique is often
frowned upon.

The capture of variables due to injected bindings can be easily avoided.
All that is required is to ensure that whenever a macro injects a binding,
the macro must guarantee that the name of the injected bound variable is 
unique.   Unique names can easily be created by a gensym-like function.

Currently, there are two techniques that guarantee unique identifers in
injected bindings.  One technique requires explict programmer
construction of unique names in the text of a macro.  For example, the
'or' macro above could be defined as

	(define or 
	   (macro (exp1 exp2)
	      (let [[new-var (gen-variable "or-var")]]
	        ↑(let [[new-var exp1]]
		   (if new-var new-var exp2)))))

Where (gen-variable <string>) constructs a unique, uninterned symbol,
whose print name consists of <string> concatenated with a (preferably) 
unique integer.

Macro expansion of:

		(lambda (v)
		   (or <exp1> v))

would become:

		(lambda (v)
		   (<let-macro> [[or-var0001 <exp1>]]
		      (<core-if> or-var0001 or-var0001 v)))

which once again avoids capture.



This category of variable capture due to injected bindings is addressed
from a different perspective by Eugene Kohlbecker's note "Position
Statement on Macros".  Both approaches both attack the unpleasant aspects
of "freezing" and "thawing" to get around name clashes by guarenteeing
the uniquenes of injected binding identifiers.  The Beta expansion which
Eugene advocates differs from the approach above by 1) providing a
framework which alleviates the user's concern for the variable clashes
created by injected bindings, and 2) performing minimal "gensyming" of
identifiers.  


				-- brooks

∂22-Oct-84  1307	MEEHAN@YALE.ARPA 	T blurb
Received: from YALE.ARPA by SU-AI.ARPA with TCP; 22 Oct 84  13:07:06 PDT
Received: by YALE-BULLDOG.YALE.ARPA; 22 Oct 84 16:02:01 EDT (Mon)
Message-Id: <8410222002.AA05044@YALE-BULLDOG.YALE.ARPA>
Date:    Mon, 22 Oct 84 15:06:55 EDT
From: Jim Meehan <Meehan@YALE.ARPA>
Subject: T blurb
To: rpg@SU-AI.ARPA

We (Cognitive Systems) are in the process of generating some sales
brochures and other such publicity for T.  We're marketing Yale's (i.e.,
Rees and Adams') native implementations for the VAX and the Apollo,
as well as our own versions that run on top of Common Lisp and LISP/VM.
It would be great to have some friendly quotes about the T language
from some Famous People, and since you said (either in Austin or
Monterey, I forget which) that you liked T, I wondered if you would
do us a favor and say something nice about T that we could quote you
on.

If you think this is inappropriate, or a nuisance, that's OK; sorry
to bother you.  I'm also not asking you to say that T is better than
Common Lisp or anything like that.  *We* think T is the nicest thing
since sliced bread, but they know that already.

Also, if you'd like to express NOT-for-attribution reservations or
suggestions about T, I'd be interested in that, too.
-------