Date: 7-Sep-82 23:06:33-PDT (Tue)
From: UCB-KIM:jkf (John Foderaro)
Subject: results of a case poll
Message-Id: <8208080606.26883@UCB-KIM.BERKELEY.ARPA>
Received: by UCB-KIM.BERKELEY.ARPA (3.193 [9/6/82]) id a26883;
	7-Sep-82 23:06:37-PDT (Tue)
Received: from UCB-KIM.BERKELEY.ARPA by UCB-VAX.BERKELEY.ARPA (3.193 [9/6/82]) id a25688;
	7-Sep-82 23:32:17-PDT (Tue)
To: common-lisp@su-ai

 Here are the result of a poll I took of Franz Lisp users about their use of
case sensitivity:

		 Results of the case sensitivity poll.
As the letters came in, I assigned each of them a number.  Below I've listed
the results by number so that you can see how the answers correlated.
Some people only answered a few of the questions (some none at all).
The text of all the letters is at mit-mc in the file "ucb;cases text"
(and for Berkeley people it is in kim:~jkf/surv)

 1) Do you use the fact that Franz Lisp is case sensitive, that is do you
    use variables with capital letters?

    yes: 3,4,5,6,7,11,14,16,17,18,19,21,23,24,25,26,27,28,30,31,33,35,36,38
         40,41,42,43,45,47,48

    no: 8,9,10,12,13,34,37,46

    summary: yes: 31/39 = 79%  no: 8/39 = 21%
    
    If yes, do you ever have two different variables whose names differ only
    by capitalization?

     yes: 4,6,11,16,17,18,21,23,24,27,28,42,43,45,46,48
     no: 7,14,19,25,26,30,31,33,35,36,38,40

    summary: yes: 16/28 = 57%   no: 12/28 = 43%
    
    [When I refer to 'variable' I mean a symbol to which you assign a
    value ( to distinguish it from something used just for
    printing, as in (print 'Results). ]
    
 2) If a case-insensitive Common Lisp was the only lisp available on your
    machine would you:

    a) use it without complaint about the case-insensitivity

    b) ask the person in charge of Common Lisp at your site to add a switch
       to disable the code that maps all characters to the same case, thus
       making it possible for each user to make Common Lisp case-sensitive.
 
    a: 3,8,9,11,12,13,16,25,26,30,34,46
    b: 1,4,6,7,10,14,18,19,21,24,27,31,33,35,36,37,38,40,41,42,43,45,47,48

    summary: a: 12/36 = 33%     b: 24/36 = 67%
    
 3) Do you prefer an operating system to be case-sensitive (like Unix and
    Multics) or case-insensitive (like Tops-10, Tops-20, Tenex, etc etc).
 
    sensitive: 1,4,5,6,7,10,11,14,18,19,21,24,26,30,31,33,35,36,40,
	       42,43,45,47,48
    insensitive:  3,8,9,12,25,34,46

    summary: sensitive: 24/31 = 77%    insensitive: 7/31 = 23%



Date: Wednesday, 8 September 1982  01:35-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To:   common-lisp at SU-AI
Subject: Array proposal (long msg)


At the 8/21 meeting, we more or less decided on a general sort of
array/vector scheme and I volunteered to work out a detailed proposal.
The reason this has taken so long is that when I tried to work out the
details of what we had discussed (or what I THOUGHT we had discussed), I
ran into some inconsistencies.  The following proposal, then, is based
rather loosely on the 8/21 discussion.

I propose the following:

Arrays can be 1-D or multi-D.  All arrays can be created by MAKE-ARRAY
and can be accessed with AREF.  Storage is done via SETF of an AREF.
1-D arrays are special, in that they are also sequences, and can be
referenced by ELT.  Also, only 1-D arrays can have fill pointers.
Suppose we use the term VECTOR to refer to all 1-D arrays, since that is
what "vector" means in the vernacular.

Vectors can be specialized along several distinct axes.  The first is by
the type of the elements, as specified by the :TYPE keyword to
MAKE-ARRAY (actually, I would much prefer :ELEMENT-TYPE as the keyword
for this option, since :TYPE is confusing here).  A vector whose
element-type is STRING-CHAR is referred to as a STRING.  Strings, when
they print, use the ".." syntax; they also are the legal inputs to a
family of string-functions, as defined in the manual.  A vector whose
element-type is BIT (alias (MOD 2)), is a BIT-VECTOR.  These are special
because they form the set of legal inputs to the boolean bit-vector
functions.  (We might also want to print them in a strange way -- see
below.)

Some implementations may provide a special, highly efficient
representation for simple vectors.  (These are the things we were
tentatively calling "quick arrays" at the meeting -- I think "simple
vector" is a much better name.)  A simple vector is (of course) 1-D,
cannot have a fill pointer, cannot be displaced, and cannot be altered
in size after its creation.  To get a simple vector, you use the :SIMPLE
keyword to MAKE-ARRAY (or MAKE-STRING, etc.) with a non-null value.  If
there are any conflicting options specified, an error is signalled.  If
an implementation does not support simple vectors, this keyword/value is
ignored except that the error is still signalled on inconsistent cases.

We need a new set of type specifiers for simple things: SIMPLE-VECTOR,
SIMPLE-STRING, and SIMPLE-BIT-VECTOR, with the corresponding
type-predicate functions.  Simple vectors are referenced by the usual
forms (AREF, CHAR, BIT), but the user may use THE or DECLARE to indicate
at compile-time that the argument is simple, with a corresponding
increase in efficiency.  Implementations that do not support simple
vectors ignore the "simple" part of these declarations.

Strings (simple or non-simple) would self-eval; all other arrays would
cause an error when passed to EVAL.  EQUAL would descend into strings,
but not into any other arrays.  EQUALP would descend into arrays of all
kinds, comparing the corresponding elements with EQUALP.  EQUALP would
be false if the array dimensions are not the same, but would not be
sensitive to the element-type of the array.

Completely independent of the above classifications is the question of
whether or not an array is normally printed.  If the :PRINT keyword to
MAKE-ARRAY has a non-null value, the array will try to print its
contents, subject to PRINLEVEL and PRINLENGTH-type constraints;
otherwise, the array would print as a non-readable object: #<array-...>.
I would suggest that if :PRINT is not specified, all vectors should
default to printing and all other arrays should default to non-printing.

Now the only problem is how to print these arrays.  If we want this
printing to preserve all features of the array (do we?) I think that the
only reasonable solution is to make the common cases print in a
nice-looking format and use #.(make-array...) for the rest.  Simple
strings could print in the double-quote syntax, simple-bit-vectors in
the #"..." format, simple vectors of element-type T could print as
#(...).  For arrays of type element-T, we could resurrect the #nA(...)
format, where n is the number of dimensions and the list contains the
elements, nested down n levels.  (I would not allow arbitrary sequences
here -- useless and confusing.)  The vector and array representations,
but not the string or bit-vector representaions, would observe PRINLEVEL
and PRINLENGTH.  Everything else would have to use #.(make-array ...),
unless we want to make up some really horrible new notation.

Alternatively, we could print everything in the nice form, but lose the
information on whether the original was simple and whether its
element-type is T or something more restrictive.  All strings, simple or
not, would print as "...", all bit vectors as #"...", all other vectors
as #(...), and all other arrays as #nA(...).  I would prefer this, but
it might turn out to be a big screw for some applications if these
notations did not preserve all of the state or the original object.

Opinions?


Date: Wednesday, 8 September 1982  00:26-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To:   Common-Lisp at SU-AI
Subject: Vote on Cases


I think that we are all sick to death of this case-sensitivity issue.
JKF, who brought the whole matter up, has asked us to make a decision,
and I guess it's time to do this.  I had hoped to have the poll of Franz
Lisp users as input before we got down to voting, but there seem to be
delays in getting this assembled.  In any event, I think we have all had
a chance to ask any nearby unix folks and/or mathematicians what they
think, we have heard all the arguments, and I think each of us has a
pretty clear opinion by now.

The live options seem to be:

1. Retain the case-insensitive status quo, along with a switch to print
symbols out in lower-case for users who like to see things that way.
More precisely, characters are by default converted to upper-case on
read-in, and then intern does observe case.

2. Add a switch to make the reader case-sensitive and, when in
case-insensitive mode, convert things to lower-case instead of
upper-case so that the case-sensitive folks don't have to type things in
in all-caps.

3. Make the system case-sensitive always, but require that all symbols
in white-pages or yellow-pages code be entirely in lower case.

**********************************************************************

Speaking for the Spice Lisp, Vax/VMS Common Lisp, and Vax/Unix Common
Lisp implementation efforts, I vote for option 1.  I should also say
that only an overwhelming show of support by the other implementors for
option 2 or 3 is likely to budge us from this position.  I honestly do
not believe that a significant number of Unix people will stay away from
Common Lisp because of this.

-- Scott


Date: 7 September 1982 23:44-EDT
From: Richard E. Zippel <RZ at MIT-MC>
Subject:  Another modest proposal
To: Common-Lisp at SU-AI

This is really getting out of hand.  As a former mathematician, I'd like to
point out that mathematicians tend to use very brief symbols for quantities
because they want to express a huge amount of information in very few
characters.  This is accomplished with the aid of an enormous amount of
context and tradition that is lacking in computer programs.  Ponder whether
you would prefer programmers to use ``ENTROPY'' instead of ``H'' (where it
could be confused with Planck's constant).  Perhaps we should flush the EXPT
function and rely on super scripts?


Date: Tuesday, 7 September 1982  23:22-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To:   Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC>
Cc:   common-lisp at SU-AI, Guy.Steele at CMU-10A
Subject: DLW query about STRING-OUT and LINE-OUT


I too would like to retain STRING-OUT and LINE-OUT.  What were the
arguments for flushing them?

-- Scott


Date: Tuesday, 7 September 1982, 16:57-EDT
From: Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC>
Subject: Clarification of full funarging and spaghetti stacks
To: MOON at SCRC-TENEX at MIT-MC, common-lisp at SU-AI
In-reply-to: The message of 4 Sep 82 04:21-EDT from MOON at SCRC-TENEX

I thought we had already decided this.  Amazing how communication can be
so imperfect even when one works so hard at it.  Anyway, I am in favor
of giving all closures indefinite extent, i.e. allowing upward funargs.
By the way, the paper in the Lisp Conference proceedings says that we
have already decided the issue in this direction; it says that Common
Lisp solves the entire "funarg problem" including upward funargs.


Date: Tuesday, 7 September 1982  19:40-EDT
From: Jim Large <LARGE at CMU-20C>
To:   Common-Lisp at SU-AI
Subject: case flames


   Here is an excerpt from a recent post on a local bboard at C-MU
which contained advice for puzzled Unix novices.

    
    As it turns out, the padding in the /etc/termcap definition of
    "concept" is optimized for 1200 baud...

    /etc/termcap contains a definition for "Concept" (note the
    capital C) that is adequate for 9600 baud.


   This kind of thing can not be stopped by widely proclaiming that 
"Its not good style",  "It won't be portable",  etc.  But it can be 
prevented by making it impossible to do.
							Jim Large


Date: Tuesday, 7 September 1982, 16:39-EDT
From: Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC>
Subject: dlw's portability semantics
To: Kim.fateman at UCB-C70, common-lisp at su-ai
In-reply-to: The message of 2 Sep 82 22:50-EDT from Kim.fateman at Berkeley

Of course, making it easier to move previously working non-CL code into
a CL implementation is a useful thing.  If you want to propose a way to
allow the running of programs with incompatible definitions of LOOP, or
DO, or CAR, then we could have some such facility.  It has nothing to do
with LOOP, though.


Date: Tuesday, 7 September 1982, 16:48-EDT
From: Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC>
Subject: REDUCE function re-proposed
To: Guy.Steele at CMU-10A, common-lisp at SU-AI
In-reply-to: The message of 3 Sep 82 17:56-EDT from Guy.Steele at CMU-10A

Sounds good.  Regarding DT's proposed variant, the problem is that it
only works with functions that can happily accept zero arguments; your
examples used +, -, and LIST, which do accept zero arguments as well as
two, but other useful functions might not accept zero.  Common Lisp is
not especially trying to make everything work with zero arguments in all
cases.  One might argue that in all the functions that are reasonable
first arguments to REDUCE do, in fact, take any number of arguments,
because that's the kind of function they are, but I'd have to see such
an argument developed more fully before I'd be convinced.


Date: 7 Sep 1982 14:45:00-PDT
From: Kim.fateman at Berkeley
To: Common-Lisp@SU-AI
Subject: Another modest proposal

I tend to read these messages and then throw them out, but I think dlw
is wrong to say that Masinter's proposal forbids using full ascii in
portable code.  Just that the part that gets described in the yellow pages,
the interface, must be in lower case.  This can be accomplished by various
forms of synonymy (e.g. (putd 'foo(getd 'Foo)) to be crude).

The alternative which some people favor,
seems to be to throw away about half the useful characters,
and ignore the precedent from mathematics (which typically uses upper and
lower cases, plus Greek, Cyrillic, Hebrew, plus tilde's asterisks, subscripts,
superscripts).

In the spirit of this latter proposal, I suggest throwing away the characters
I,l,O,0,\,`,|,',/, because they obviously contribute to confusion;
I propose making the keys normally ascribed to 9 and 0 used
for ( and ) respectively, eliminating the need to shift.
Numbers can be written in octal, so 9 is unnecessary.  The absense of the 0
can be remedied by a set of sequence-shifting operations on strings of digits.


Date: Tuesday, 7 September 1982, 16:52-EDT
From: Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC>
Subject: DLW query about STRING-OUT and LINE-OUT
To: Guy.Steele at CMU-10A, common-lisp at SU-AI
In-reply-to: The message of 3 Sep 82 18:35-EDT from Guy.Steele at CMU-10A

    Date:  3 September 1982 1835-EDT (Friday)
    From: Guy.Steele at CMU-10A

    These functions were eliminated as a result of November issue 214.
    --Guy

Hmm.  My notes show that there was more sentiment to not flush them than
to flush them, especially on the part of you and me.  But if you say
that's what we decided in the meeting, then so be it.  I will probably
push for having them in the Lisp Machine anyway as extensions.


Date: 7 Sep 1982 14:45:00-PDT
From: Kim.fateman at Berkeley
To: Common-Lisp@SU-AI
Subject: Another modest proposal

I tend to read these messages and then throw them out, but I think dlw
is wrong to say that Masinter's proposal forbids using full ascii in
portable code.  Just that the part that gets described in the yellow pages,
the interface, must be in lower case.  This can be accomplished by various
forms of synonymy (e.g. (putd 'foo(getd 'Foo)) to be crude).

The alternative which some people favor,
seems to be to throw away about half the useful characters,
and ignore the precedent from mathematics (which typically uses upper and
lower cases, plus Greek, Cyrillic, Hebrew, plus tilde's asterisks, subscripts,
superscripts).

In the spirit of this latter proposal, I suggest throwing away the characters
I,l,O,0,\,`,|,',/, because they obviously contribute to confusion;
I propose making the keys normally ascribed to 9 and 0 used
for ( and ) respectively, eliminating the need to shift.
Numbers can be written in octal, so 9 is unnecessary.  The absense of the 0
can be remedied by a set of sequence-shifting operations on strings of digits.


Date:  7 September 1982 1754-EDT (Tuesday)
From: Guy.Steele at CMU-10A
To: Daniel L. Weinreb <dlw@SCRC-TENEX at MIT-MC>
Subject:  Re: REDUCE function re-proposed
CC: common-lisp at SU-AI
In-Reply-To:  Daniel L. Weinreb@SCRC-TENEX@MIT-MC's message of 7 Sep 82
             15:48-EST

Your objection is well-taken.  The use of the zero-argument
case does not always work; it is merely intended for convenience,
to allow omission of :INITIAL-VALUE in the common cases.
It allows some situations to work which otherwise would be
errors.  If the function can't accept zero arguments, all that
differs is that you get an error about wrong number of
arguments rather than about an empty sequence to REDUCE.


Date:  7 September 1982 1814-EDT (Tuesday)
From: Guy.Steele at CMU-10A
To: common-lisp at SU-AI
Subject:  forgot to CC this


- - - - Begin forwarded message - - - -
Date:  7 September 1982 1812-EDT (Tuesday)
From: Guy.Steele at CMU-10A
To: Kim.fateman at UCB-C70
Subject:  Re: Another modest proposal
In-Reply-To:  Kim.fateman@Berkeley's message of 7 Sep 82 16:45-EST

While I am not unsympathetic to the desires to exploit case,
I am slightly unpersuaded by the arguments from mathematics.
The conventions that arose around mathematics may perhaps have
arisen from the need for brevity (not in itself a bad thing)
due to the necessity of hand transcription, because one didn't
have computers to help one manipulate formulas.  If you had to
copy
a formula over thirty times as you simplified or otherwise dealt
with it, you would of course try to invent very consice symbols.
Also, mathematics has historically used adjacency to imply
multiplication in most contexts, ruling out multi-character
variables names.
APL is in a curious halfway poisition in this regard.  The user may have
multi-character names, but built-in functions, as a conventional
rule, may not!  Actually, they can, but all the characters must be
all written in one character position.  They ran out of pretty overstrikes
some time ago.  Recently, some APL implementations have burst forth
and provided system functions with multi-character names
beginning with the quad character.
If you only have one character, then mentioning all its
attrributes (case, boldness, hats and tildes, etc.) is not
so bad.  SUppose you use only five or six such attributes
in a very complex paper; then any name is at worst something
like "the vector capital A hat prime tilde".  But if a name
can be many characters long, having seperate attributes for
each character explodes the number of possibilities, making
it ridiculous, as KMP has observed, to try to speak them,
unless there is enough self-control to avoid using the
attributes after all.
You would go nuts if you tried to distinguish bold, italic, and
ordinary tildes and hats.
--Guy
- - - - End forwarded message - - - -


Date:  7 September 1982 1814-EDT (Tuesday)
From: Guy.Steele at CMU-10A
To: common-lisp at SU-AI
Subject:  forgot to CC this


- - - - Begin forwarded message - - - -
Date:  7 September 1982 1812-EDT (Tuesday)
From: Guy.Steele at CMU-10A
To: Kim.fateman at UCB-C70
Subject:  Re: Another modest proposal
In-Reply-To:  Kim.fateman@Berkeley's message of 7 Sep 82 16:45-EST

While I am not unsympathetic to the desires to exploit case,
I am slightly unpersuaded by the arguments from mathematics.
The conventions that arose around mathematics may perhaps have
arisen from the need for brevity (not in itself a bad thing)
due to the necessity of hand transcription, because one didn't
have computers to help one manipulate formulas.  If you had to
copy
a formula over thirty times as you simplified or otherwise dealt
with it, you would of course try to invent very consice symbols.
Also, mathematics has historically used adjacency to imply
multiplication in most contexts, ruling out multi-character
variables names.
APL is in a curious halfway poisition in this regard.  The user may have
multi-character names, but built-in functions, as a conventional
rule, may not!  Actually, they can, but all the characters must be
all written in one character position.  They ran out of pretty overstrikes
some time ago.  Recently, some APL implementations have burst forth
and provided system functions with multi-character names
beginning with the quad character.
If you only have one character, then mentioning all its
attrributes (case, boldness, hats and tildes, etc.) is not
so bad.  SUppose you use only five or six such attributes
in a very complex paper; then any name is at worst something
like "the vector capital A hat prime tilde".  But if a name
can be many characters long, having seperate attributes for
each character explodes the number of possibilities, making
it ridiculous, as KMP has observed, to try to speak them,
unless there is enough self-control to avoid using the
attributes after all.
You would go nuts if you tried to distinguish bold, italic, and
ordinary tildes and hats.
--Guy
- - - - End forwarded message - - - -


Date: Tuesday, 7 September 1982, 16:39-EDT
From: Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC>
Subject: dlw's portability semantics
To: Kim.fateman at UCB-C70, common-lisp at su-ai
In-reply-to: The message of 2 Sep 82 22:50-EDT from Kim.fateman at Berkeley

Of course, making it easier to move previously working non-CL code into
a CL implementation is a useful thing.  If you want to propose a way to
allow the running of programs with incompatible definitions of LOOP, or
DO, or CAR, then we could have some such facility.  It has nothing to do
with LOOP, though.


Date: Tuesday, 7 September 1982, 16:43-EDT
From: Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC>
Subject: case-sensitivity: an immodest proposal
To: Common-Lisp at SU-AI

In reply to the mail from ucbvax:<Kim:jkf>:

Let me clarify what Moon said.  Masinter's proposal ALLOWS private code
in a CL dialect to be written in mixed case (and the case is
significant), but FORBIDS the existing ability to write portable code in
mixed case (and have the case be ignored).  Moon said:

                                It seems to me that all the modest
    proposal accomplishes (for portable programs) is not allowing them to
    be written in upper case, hardly an improvement.

So what we have is a tradeoff in which the proposal adds restrictions to
portable use of CL, in exchange for more flexible use of non-portable
CL.  This is not consonant with CL's primary goals.  For this reason
I would also like to go on record as being opposed to the proposal.


Date: Tuesday, 7 September 1982, 16:37-EDT
From: Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC>
Subject: lambda
To: Killian at MIT-MULTICS
Cc: Common-Lisp at SU-AI
In-reply-to: The message of 1 Sep 82 15:57-EDT from Earl A. Killian <Killian at MIT-MULTICS>

I remember that the issue of letting (lambda ...) evaluate had something
to do with the function/value dualism but I can't remember what.
Presumably GLS knows what is going on with this.


Date:  4 September 1982 2312-EDT (Saturday)
From: Guy.Steele at CMU-10A
To: common-lisp at SU-AI
Subject:  Re: Clarification of full funarging and spaghetti stacks
In-Reply-To:  MOON@SCRC-TENEX's message of 4 Sep 82 03:21-EST

Well, Moon certainly hit the nail on the head.  The Colander draft
of the Common LISP Manual mentions lexical function parameters as
examples of things that have indefinite extent, contrasting with
ALGOL, in which they also have lexical scope but instead have dynamic
extent.  August issue 49 has confirmed that variables shall be
lexical and not local, but the question of extent was not addressed
or confirmed, and that is my fault.


Date:  4 September 1982 2246-EDT (Saturday)
From: Guy.Steele at CMU-10A
To: common-lisp at SU-AI
Subject:  Mailing list

I have already requested the removal of research!dbm@berkeley from
the COMMON-LISP mailing list. 


Date: Friday, 3 September 1982  20:12-EDT
Sender: TK at MIT-OZ
From: TK at MIT-MC
To:   common-lisp at sail

Date: 3-Sep-82 09:08:30-PDT (Fri)

	From: ucbvax:<Kim:jkf> (John Foderaro)
	Subject: cases, re: kmp's and moon's mail

	Kent says that he has trouble remembering cases in words.  I can
	accept that but Kent should not generalize and say that this is try of
	all people.
I would have no trouble remembering any CONSISTENT set of conventions
for labelling word boundaries.  Common lisp, for better or worse, has chosen
to label word boundaries in symbol names with a hypen.  The function name
is load-byte, not loadbyte, not LoadByte, not Load_byte, not load!byte,
or anything else.  If there is ONE convention on how we separate words, then
talking about the separations is easy.  That's why you can discuss mixed
case without getting confused.  And why you can remember it.  If you used
a mixture of the above conventions, then you would find it impossible to
talk about mixed case, too.  We are really talking [partly] about what to use 
as the word delimiter, not about case at all.  Having one delimiter is much
better than having five.

	However, I write a piece of code which is useful enough to be added to
	the public code, then that code will be translated to lower case
	before being added.

This is exactly the point.  If case is distinguished, then this process
will be painful, bug-prone, and extra work for everyone.  The only alternative
is to avoid making symbols which are unique without case.  If you do that, then
the case being folded on input is not much of a burden, since the source code
can be as pretty [or ugly, your taste] as you want.
-------


Date: Saturday, 4 September 1982  04:21-EDT
From: MOON at SCRC-TENEX
to: common-lisp at SU-AI
Subject: Clarification of full funarging and spaghetti stacks

Okay, here's the big question.  Do closures over lexical variables have
dynamic extent or indefinite extent?  In other words, do we have upward
funargs, or only downward funargs with full access to lexical variables?


Date: 4 September 1982 02:28-EDT
From: Kent M. Pitman <KMP at MIT-MC>
Subject:  Proposed definition of SUBST
To: COMMON-LISP at SU-AI

    Date: Saturday, 4 September 1982  01:02-EDT
    From: Scott E. Fahlman <Fahlman at Cmu-20c>

    Maybe the right move is to eliminate the :TEST-NOT option for SUBST.
    All you really want here is some sort of equality test, so :TEST-NOT
    makes no real sense here.  Don't we have some precedents for this?...
-----
Why not just flush all :TEST-NOTs and make a primitive COMPLEMENT as:

(DEFUN COMPLEMENT (FN) #'(LAMBDA (&REST STUFF) (NOT (APPLY FN STUFF))))

a smart compiler could generate fairly good code for this and in some
cases literal translations from things like (COMPLEMENT #'EQ) to #'NEQ could
be done, etc. I suspect the constant argument case will occur very often
so this optimization will be a very productive one. Then people would just
write :TEST (COMPLEMENT #'EQ) if it mattered to them to have the opposite 
test.

T (Yale Scheme) has this. It's much more general than :TEST-NOT (has 
many more uses), simplifies the internal code of many system functions, 
and simplifies the language definition.

-kmp


Date: 4 September 1982 02:03-EDT
From: Kent M. Pitman <KMP at MIT-MC>
Subject:  Writing PROG as a macro
To: MOON at SCRC-TENEX
cc: COMMON-LISP at SU-AI

I agree whole-heartedly with your suggestion that (PROG T ...) be replaced with
the requirement that named RETURNs match only named PROGs and un-named 
RETURNs match un-named PROG. I have always felt the special-casing of 
T to be inelegant and I think this offers just the right degree of
control.

Also, since you brought up the idea of lower level primitives to implement
PROG with, I dredge up here thoughts I presented on the subject years back...

-----Begin Forwarded Message Portions-----
Date: 12 APR 1980 2054-EST
From: KMP at MIT-MC (Kent M. Pitman)
Subject: What should we DO?
To: (BUG LISP) at MIT-MC, NIL at MIT-MC, (BUG LISPM) at MIT-MC
CC: H at MIT-MC, KMP at MIT-MC, HENRY at MIT-MC, RMS at MIT-MC
CC: MOON at MIT-MC

... I now present my feelings on this issue of how DO/PROG could be done in
order this haggling, part of which I think comes out of the fact that these
return tags are tied up in PROG-ness and so on ... Suppose you had the
following primitives in Lisp:

(PROG-BODY ...) which evaluated all non-atomic stuff. Atoms were GO-tags.
 Returns () if you fall off the end. RETURN does not work from this form.

(PROG-RETURN-POINT form name) name is not evaluated. Form is evaluated and
 if a RETURN-FROM specifying name (or just a RETURN) were executed, control
 would pass to here. Returns the value of form if form returns normally or
 the value returned from it if a RETURN or RETURN-FROM is executed. [Note:
 this is not a [*]CATCH because it is lexical in nature and optimized out
 by the compiler. Also, a distinction between NAMED-PROG-RETURN-POINT
 and UNNAMED-PROG-RETURN-POINT might be desirable -- extrapolate for yourself
 how this would change things -- I'll just present the basic idea here.]

(ITERATE bindings test form1 form2 ...) like DO is now but doesn't allow
 return or goto. All forms are evaluated. GO does not work to get to any form
 in the iteration body.

So then we could just say that the definitions for PROG and DO might be
(ignore for now old-DO's -- they could, of course, be worked in if people
really wanted them but they have nothing to do with this argument) ...

 (PROG [ <tag> ] <bvl> . <body>)

  => (PROG-RETURN-POINT (LET <bvl> (PROG-BODY . <body>)) [ <tag> ])

 (DO [ <tag> ] <bind-specs> <tests> . <body>)

  => (PROG-RETURN-POINT (ITERATE <bind-specs> <tests> (PROG-BODY . <body>))
			[ <tag> ])

Other interesting combinations could be formed by those interested in them.
If these lower-level primitives were made available to the user, he needn't
feel tied to one of PROG/DO -- he can assemble an operator with the 
functionality he really wants....
-----
Date: 15 April 1980 00:40-EST
From: "Guy L. Steele, Jr." <GLS at MIT-MC>
Subject: What should we DO?
To: BUG-LISP at MIT-MC, NIL at MIT-MC, BUG-LISPM at MIT-MC
cc: KMP at MIT-MC, H at MIT-MC, HENRY at MIT-MC, RMS at MIT-MC,
    MOON at MIT-MC

... Seriously, folks, my own position on DO and friends is largely in agreement
with KMP here.  His PROG-RETURN-POINT is simply the lexical catch advocated
by DLW, with allowances for how RETURN could be expressed in terms of that.
It is of interest to note that the S-1 NIL compiler in fact
implements a construct called PROG-BODY with precisely those semantics;
PROG is then turned into a nested LET and PROG-BODY.  This was done
to concentrate all knowledge of variable bindings into one place --
the code that handles LAMBDA.  The original intent was just to use
this construct internally to the compiler, but indeed it may be a useful
building-block for other macros.
-----End Forwarded Message Portions-----


Date:  4 September 1982 0124-EDT (Saturday)
From: Guy.Steele at CMU-10A
To: common-lisp at SU-AI
Subject:  SUBST

Well, perhaps SUBST should not have TEST-NOT, but other functions do.
I was just trying to illustrate how clumsy implementing TEST-NOT could be,
at least if you go about it the wrong way.  I am now less concerned.
(I admit to not having scanned Skef's code carefully -- sorry.)
--Guy


Date: Saturday, 4 September 1982  01:02-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To:   STEELE at CMU-20C
Cc:   common-lisp at SU-AI
Subject: Proposed definition of SUBST


Maybe the right move is to eliminate the :TEST-NOT option for SUBST.
All you really want here is some sort of equality test, so :TEST-NOT
makes no real sense here.  Don't we have some precedents for this?

How about if we call the identity function IDENTITY ?

About REDUCE:  I'm the one (or one of the ones) who complained about it
before, when we had 600 or so sequence functions and didn't need another
dozen.  I now withdraw my former objection.  I still think it's slightly
confusing, but any user who can digest lexical scoping is ready for
this.

-- Scott


Date: Saturday, 4 September 1982  00:50-EDT
From: Skef Wholey <Wholey at CMU-20C>
To:   STEELE at CMU-20C
Cc:   common-lisp at SU-AI
Subject: Proposed definition of SUBST, standard identity function

While implementing the sequence functions, I defined an Identity function for
the sole purpose of defaulting the :key parameters.  Since Identity is very
useful in general and for :key parameters in particular, and since it is an
extremely well-defined, extremely simple function, I think it would be worth
adding to the language.

--Skef


Date:  4 Sep 1982 0038-EDT
From: STEELE at CMU-20C
Subject: Flying off the handle: one more time on SUBST
To: common-lisp at SU-AI

The last (second) try was buggy; here's a corrected version.
Note the use of &REST with &KEY, and the slick use of APPLY:

(defun subst (old new tree @rest x @key test test-not key)
  (cond ((atom tree)
	 (if (satisfies-the-test old tree :test test
				 :test-not test-not :key key)
	     new tree))
	(t (let ((a (apply #'subst old new (car tree) x))
		 (d (apply #'subst old new (cdr tree) x)))
	     (if (and (eq a (car tree)) (eq d (cdr tree)))
		 tree
		 (cons a d))))))

--Guy
-------


Date: Saturday, 4 September 1982  00:28-EDT
From: MOON at SCRC-TENEX
To: Common-lisp at su-ai
cc: alan at SCRC-TENEX, dla at SCRC-TENEX
Subject:Agenda Item 74: Interaction of BLOCK and RETURN

At the meeting we commissioned GLS and SEF to make a proposal about this.
But in the meantime Bawden has come up with a good proposal, hence I am
mailing off this writeup of it.

The problem:
Blocks, named and unnamed, are used to label a point to which the RETURN
special form will transfer control.  Some special forms are defined and
documented to create a block, thus RETURN may be used inside of them.  PROG,
DO, and DOLIST are examples.  Some of these special forms might be implemented
as macros, expanding into simpler special forms such as BLOCK or PROG.  It's
easy to see how to implement DOLIST this way, for example.

Sometimes one has a macro that needs to transfer control internally within
the code it writes, using BLOCK and RETURN or the equivalent.  However,
this block is purely the internal business of this macro and should not be
visible to the user.  This is different from DOLIST, where the user is told
that there is a block there.  If the macro takes a body, and the user
writes RETURN inside that body, the RETURN should return from the block the
user expects it to return from; it shouldn't be affected by the internal
block written by the macro.  The classic example of this occurs when a
compiler optimizes (MAPCAR #'(LAMBDA ...)) by translating it into an
iteration, rather than breaking off a separate function and passing it to
MAPCAR.  The iteration is done with PROG or DO, which creates a block.  If
RETURN was used inside the body of the lambda, it should not return
unexpectedly from the MAPCAR, it should return from some enclosing form,
assuming we are using a full-lexical-scoping language.  Another example is
an error-handling macro that generates code something like:
	(PROG () (CATCH tag (RETURN body))
		 error-body)
Here the idea is that in the normal case we want to return the value(s) of body
from the form; but if a throw occurs, we want to go off and do error-body.
However, the user might well write a RETURN inside body, and this RETURN should
not be captured by the PROG, which the user has no idea is there.

Macros may generate blocks for GO as well as for RETURN.  The MAPCAR example
above was an example of this.

A solution that doesn't quite work:
The 29July Common Lisp manual, on page 72, adopts a solution to this from
the Lisp machine.  The RETURN function returns from the innermost enclosing
block, named or unnamed, except that it ignores blocks named T.  Thus macros
that need to generate blocks that are invisible to the user just name them
T, and return from them with (RETURN-FROM T value).

There are two problems with this.  One is that the named-PROG and named-DO
features have been flushed from Common Lisp; only BLOCK can have a name.
This means that it is impossible to create something that loops but is
invisible to RETURN.  The other problem is that sometimes it is necessary
to nest invisible blocks.  There is no way to nest two invisible blocks
and put a return from the outer one inside both of them, since they both
have to have the same name (T).  This problem shows up as two macros that
work separately, but mysteriously generate wrong code when used together.

The proposed solution:
Define (RETURN value) to be (RETURN-FROM NIL value); allow RETURN to return
from unnamed blocks only.  Require RETURN-FROM to be used to return from
named blocks.  Thus to make a block which is invisible to RETURN, you just
give it a name.  You can choose a unique name for a macro-generated block
the same way you would for a macro-generated variable, perhaps by using
GENSYM.

This is incompatible with the Lisp machine, where RETURN returns from named
blocks as well as unnamed ones.  However, it isn't really incompatible since
all the Lisp machine ways to create a named block have been flushed from
Common Lisp, and the BLOCK special form is new.  In the Lisp machine, we can
keep around a compatibility kludge for a while, where named PROGs and DOs generate
two blocks, one named and one not named, unless the name is T, thus getting
the old behavior.

The other problem is that we need a way for macros to perform iteration without
"capturing" RETURN.  This is handled by introducing a new special form, which
is a "naked" PROG body without an associated block and without variable bindings.
I don't know of a good name for this, but the name doesn't matter much since
only macros that implement new control-structures should be using it.
The name could be GO-BODY, meaning a body with GOs and tags in it, or
PROG-BODY, meaning just the inside part of a PROG, or WITH-GO, meaning
something inside of which GO may be used.  I don't care; suggestions anyone?

(GO-BODY &body <body>)

<body> is treated like a prog body is now.  Symbols are labels and you can use
GO to branch.  GO-BODY always returns NIL (there are NO exceptions).

Now we can flush PROG as a special form and write it as a macro:

(defmacro prog (first &rest rest)
  (cond ((listp first)	;assuming we fix it so that (listp nil) => t
	 `(let ,first
	    (block nil
	      (go-body ,@rest))))
	((eq first t)
	 `(let ,(car rest)
	    (block t
	      (go-body ,@(cdr rest)))))
	(t
	 `(let ,(car rest)
	    (block ,first
	      (block nil
		(go-body ,@(cdr rest))))))))


Date:  4 Sep 1982 0034-EDT
From: STEELE at CMU-20C
Subject: Another try at SUBST
To: common-lisp at SU-AI

How about this one?

(defun subst (old new tree @key test test-not key)
  (cond ((atom tree)
	 (if (satisfies-the-test old tree :test test :test-not test-not :key key)
	     new tree))
	(t (let ((a (subst old new (car tree) :test test :key key))
		 (d (subst old new (cdr tree) :test test :key key)))
	     (if (and (eq a (car tree)) (eq d (cdr tree)))
		 tree
		 (cons a d))))))

(defun satisfies-the-test (x y @key test test-not key)
  (if key
      (if test
	  (if test-not
	      <signal-error>
	      (funcall test x (funcall key y)))
	  (if test-not
	      (not (funcall test x (funcall key y)))
	      (eql x (funcall key y))))
      (if test
	  (if test-not
	      <signal-error>
	      (funcall test x y))
	  (if test-not
	      (not (funcall test x y))
	      (eql x y)))))

Actually, SATISFIES-THE-TEST might be useful to define for user use?
--Guy
-------


Date:  4 Sep 1982 0025-EDT
From: STEELE at CMU-20C
Subject: Proposed definition of SUBST
To: common-lisp at SU-AI

Here is a tentative definition of SUBST for inclusion in the white pages:
(defun subst (old new tree @key (test #'eql testp)
		                (test-not nil test-not-p)
				(key #'(lambda (x) x)))
  (cond (test-not-p
	 (if testp @r[<signal-an-error>]
	     (subst old new tree
		    :test #'(lambda (x y) (not (funcall test-not x y)))
		    :key key)))
	((atom tree)
	 (if (funcall test old tree) new tree))
	(t (let ((a (subst old new (car tree) :test test :key key))
		 (d (subst old new (cdr tree) :test test :key key)))
	     (if (and (eq a (car tree)) (eq d (cdr tree)))
		 tree
		 (cons a d))))))

I had two problems.  One is that :TEST-NOT is a pain to implement.
Either I have to use the subterfuge I did here, which is clumsy or slow,
or else I have to implement SUBST twice, once for the version that
uses TEST and once for the one that uses TEST-NOT.  Actually, what
I need is a function XOR, taking two boolean values (NIL/not-NIL)
and returning their xor, so that I can pass a TEST-NOT-P flag and
xor it with the result of the predicate.
The other problem is that I wish there were a standard identity function
for use in initializing the :KEY parameter.  (I refuse to use VALUES!)
Any suggestions on this or other aspects of the above definition?
--Guy
-------


Date:  3 September 1982 2339-EDT (Friday)
From: Guy.Steele at CMU-10A
To: jonl at PARC-MAXC
Subject:  Clarification of closures and GO
CC: common-lisp at SU-AI, moon@scrc-tenex at MIT-MC, hedrick at rutgers


  1) Glaaag, did the CL meeting *really* ditch the notion of being able
    to include special variables into closures?  I thought it merely decided 
    to extend the LispM syntax to include all lexically appearing variables 
    by default (sort of what NIL was proposing to do) which would mean 
    current LispM closures would be a subset of the future closures.

First of all, as has already been pointed out on the mailing list,
the word "closure" has been used to mean different things.  Here I will
always speak explicitly of "closures over lexical variables" and
"closures over special variables".

The CL meeting did *not* vote to get rid of either kind of closure.
It was to have been an item on the agenda at Hedrick's request, and I
apologize greatly for having overlooked it.  Subsequent to the meeting
the notion of eliminating closures over special variables has been
discussed on the net.  As nearly as I can tell, so far there is some
sympathy for eliminating them, and no ardent voices for retaining them.
However, a formal poll has not been conducted.

The current state of Common LISP with respect to closures is as follows:
bound variables that are not special are lexical (not local--if a compiler
can suitably determine that a lexical variable is not referred to from within
a nested lambda-expression, then it is welcome to treat it as local; this
static analysis can be performed at compile time).  Therefore the FUNCTION
construct containing a lambda-expression may need to construct a closure
over lexical variables.  Again, in the interpreter it is probably simplest
to close over all lexical variables, but compiled code can close over
only those variables that are needed (possibly none).

There is a separate construct, called CLOSURE, that constructs closures
over special variables.  It takes any function and an explicit list of
names of special variables, and constructs a closure over precisely those
special variables and no others.  It does not close over any lexical
variables whatsoever.  If you write
(DECLARE (SPECIAL B))
 ...
    (LET ((A 0) (B 1))
	(CLOSURE #'(LAMBDA (X Y) (+ A B X Y)) '(B)))
then the result of the CLOSURE operation indeed closes over both
A (a lexical variable) and B (a special variable), but for completely
independent reasons.  The use of FUNCTION implied by #' caused A to
be closed over before the CLOSURE operation ever executed.


  2) I can't believe we agreed to support full funarging.  That's incredible!
    Only the spaghetti stack does this "right", for the pseudo-mathematical
    concept you mention, and CL is nowhere near spaghetti yet.  The
    alternative is to ditch Lisp semantics and go for Scheme, and I hope
    there hasn't been any consensus on that!!!

Well, full lexical scoping as well as dynamic scoping has been agreed to;
along with CLOSURE, that's a full as I've ever seen any funarging get.
Even without CLOSURE, one still has closures over lexical variables,
which I suppose is what some people mean by "full funarging".  It is
debatable whether spaghetti stacks "do it right" (I would refer you
to my 1977 paper "Macaroni is Better than Sphagetti", except
that I don't believbe that Macaroni *is* better; nevertheless that
paper contains a critique of spaghetti stacks that may be relevant).
Even if they do "do it right", it is debatable whether that is the only
correct model.

I'm sure that Common LISP hasn't gone for SCHEME, and I suspect the T folks
at Yale would back me up there.  While Common LISP, as currently defined,
supports lexical scoping, it also supports dynamic scoping in pretty
much the traditional style, and furthermore differs from SCHEME in having
separate value and function cells.

  3) Yea, my myopic misreading of Hedrick caused me to say issue #68 (and
    #62) when I meant #8.  But again, the consensus was to allow any local
    GO (local includes all the cases in issue #8 except from within funargs);
    Non-local GO's, such as could be the case from within funargs, were
    certainly argued against, so I'd hardly say there was consensus on this
    point;  wouldn't such non-local GO's ultimately imply spaghetti also?

The consensus of the recent meeting was that PROG tags, to which GO's
refer, would have lexical scope and *dynamic extent*.  The effect of that
last phrase is to make them behave like a CATCH followed by a local GO.
That is, once you have exited a PROG by whatever means, its tags are
no longer valid and you may not GO to them.


Date:  3 September 1982 2315-EDT (Friday)
From: Guy.Steele at CMU-10A
To: common-lisp at SU-AI
Subject:  Backquote proposal

Ooops, sorry about that.
Certainly better examples should be provided; and I apologize for the
underscores going away.  SCRIBE is only *mostly* device-independent.

Anyway, I want to point out that the main reason for the formal
definition is to make it very precise (if not clear) what nesting
of backquotes does, and also to guarantee that you can't get into
trouble nesting , and ,@ in odd ways.  In some present implementations
I believe it is possible to fake backquote out into producing
an expression that gives CONS the wrong number of arguments.
--Guy


Date: Tuesday, 9 March 1982  22:10-EST
From: MOON at SCRC-TENEX
To: Guy.Steele at CMU-10A
Cc: common-lisp at SU-AI
Subject: Backquote proposal per issue 99

You just can't win.  This time you got the backquotes in but the underscores
went away.  Anyway, it looks like there isn't anything wrong with the specification;
I vote yes.

It was damned sneaky of you to use only numbers in your one nested-backquote
example, so that the reader would have no chance of figuring out when nor how
many times things wil be evaluated.  You should at least put in the example
from page 214 of the Chine Nual, since this issue confuses everyone.


Date: Tuesday, 9 March 1982  22:12-EST
From: MOON at SCRC-TENEX
To: Guy.Steele at CMU-10A
Cc: common-lisp at SU-AI
Subject: REDUCE function re-proposed

Sure, put it in.  It is useful sometimes.


Date: 3 Sep 1982 17:40 PDT
From: JonL at PARC-MAXC
Subject: Re: function specs
In-reply-to: dlw at SCRC-TENEX's message of Tuesday, 31 August 1982,
 11:21-EDT
To: Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC>
cc: Fahlman at Cmu-20c, Common-Lisp at SU-AI

Not only do I like SEF's suggestion (use the SETF syntax instead of
introducing a whole new syntax for function specs), but it seems to
resolve two important issues:
  1) Symbols should be used as names, not other datatypes
  2) There must be a uniform way to cause a defined function to be stored
    at any reasonably accessible location, regardless of whether or not
    that function "has" a name

A key word in point 2 is "store".  Thus, use SETF syntax, inventing new
accessor functions where necessary.

It's a defect if there are "locations" of relevance in compiled code which
the user can't access.  Thus if some anonymous lambda expression causes 
an internally-generated function,  *and there is some need to "get hold"
of it after compilation*, then there should be appropriate accessor functions,
regardless of the function-specs controversy.  Possibly new accessor names
need not be invented, if there can be conventions established for the
storage of compiled code constructs, but this is a lower-level implementation
matter.

Also, I feel, it's misguided to throw out symbols as names simply because
of reaction to the uncomfortable wart in MacLisp engendered by
   (DEFUN (FOO BAZZAZ) (X) . . . )






Date:  3 September 1982 1835-EDT (Friday)
From: Guy.Steele at CMU-10A
To: common-lisp at SU-AI
Subject:  DLW query about STRING-OUT and LINE-OUT

These functions were eliminated as a result of November issue 214.
--Guy


Date: 3 September 1982 18:23-EDT
From: Kent M. Pitman <KMP at MIT-MC>
Subject: More case stuff: speed and accuracy
To: common-lisp at SU-AI

I would also be interested in knowing how many people advocating function
names like LoadByte over load-byte, etc. are touch typists and what their
typing speed is. I type I think reasonably fast (upwards of 50 words a minute)
and I note that it blocks my typing speed tremendously to have to shift.
The "-" key can be hit in sequence with other keys because it's only one thing
to have to toss in, but having to shift involves coordinating two fingers to
do something at exactly the same time and then making sure I get my finger off
the shift key in time for the following character. I would anticipate that
in a system that made case matter and that had mixed case variable names,
I'd have to type considerably slower. I would consider this a reasonably
expensive price to pay since I code very fast and if I know roughly what I
want to write, my coding speed may well be bounded by my typing speed. Slower
typists or fast typists who don't code very fast may not be bothered a whole
lot may not be bothered so much by this ... This is particularly critical in
interactive debugging on systems without a toplevel text editor built into
the lisp reader where I may have just held the shift key too long and have
to rub way back just to change the shift of a character that I typed wrong
without noticing ... Yes, I know, I could have dropped a dash or typed a wrong
key, but I claim that it's easier to make a case mistake than to hit a wrong
letter in a lot of cases just because the shift key involves synchronizing
two fingers and the other types of processes that go on in typing are problems
of sequential .. Certainly the frustration level of having typed
(Setq foo 3) and then finding that you'd left the shift on too long for the
"S" is worse than the frustration level of having doing (Aetq foo 3). The
former does not "feel" to me like it has as much right to be an error. The
latter is much easier to tolerate an error message about... 


Date:  3 September 1982 1814-EDT (Friday)
From: Guy.Steele at CMU-10A
To: common-lisp at SU-AI
Subject:  Backquote proposal per issue 99

Here is the backquote proposal per issue 99.  It is exactly
what is in the latest Common LISP Manual draft, except that
I have conquered the SCRIBE bug that caused backquotes not
to print.
--Guy
-------------------------------------------------------------------------

`  The backquote (accent grave) character makes it easier to write
   programs to construct complex data structures by using a template.
   As an example, writing

       `(cond ((numberp ,x) ,@y) (t (print ,x) ,@y))

   is roughly equivalent to writing

       (list 'cond
             (cons (list 'numberp x) y)
             (list* 't (list 'print x) y))

   The general idea is that the backquote is followed by a template, a
   picture of a data structure to be built.  This template is copied,
   except that within the template commas can appear.  Where a comma
   occurs, the form following the comma is to be evaluated to produce an
   object to be inserted at that point.  Assume B has the value 3, for
   example, then evaluating the form denoted by ```(A B ,B ,(+ B 1) B)''
   produces the result (A B 3 4 B).
   If a comma is immediately followed by an at-sign (``@''), then the
   form following the at-sign is evaluated to produce a list of objects.
   These objects are then ``spliced'' into place in the template.  For
   example, if X has the value (A B C), then

       `(x ,x ,@x foo ,(cadr x) bar ,(cdr x) baz ,@(cdr x))
          -> (x (a b c) a b c foo b bar (b c) baz b c)

   The backquote syntax can be summarized formally as follows.  For each
   of several situations in which backquote can be used, a possible
   interpretation of that situation as an equivalent form is given.
   Note that the form is equivalent only in the sense that when it is
   evaluated it will calculate the correct result.  An implementation is
   quite free to interpret backquote in any way such that a backquoted
   form, when evaluated, will produce a result EQUAL to that produced by
   the interpretation shown here.

      - `simple is the same as 'simple, that is, (QUOTE simple),
        for any form simple that is not a list or a general vector.

      - `,form is the same as form, for any form, provided that the
        representation of form does not begin with ``@'' or ``.''.
        (A similar caveat holds for all occurrences of a form after
        a comma.)

      - `,@form is an error.

      - `(x1 x2 x3 ... xn . atom) may be interpreted to mean
        (APPEND x1 x2 x3 ... xn (QUOTE atom)), where the underscore
        indicates a transformation of an xj as follows:

           * form is interpreted as (LIST `form), which contains a
             backquoted form that must then be further interpreted.

           * ,form is interpreted as (LIST form).

           * ,@form is interpreted simply as form.

      - `(x1 x2 x3 ... xn) may be interpreted to mean the same as
        `(x1 x2 x3 ... xn . NIL).

      - `(x1 x2 x3 ... xn . ,form) may be interpreted to mean
        (APPEND x1 x2 x3 ... xn form), where the underscore
        indicates a transformation of an xj as above.

      - `(x1 x2 x3 ... xn . ,@form) is an error.

      - `#(x1 x2 x3 ... xn) may be interpreted to mean (MAKE-VECTOR
        NIL :INITIAL-CONTENTS `(x1 x2 x3 ... xn)).

   No other uses of comma are permitted; in particular, it may not
   appear within the #A or #S syntax.
   Anywhere ``,@'' may be used, the syntax ``,.'' may be used instead to
   indicate that it is permissible to destroy the list produced by the
   form following the ``,.''; this may permit more efficient code, using
   NCONC instead of APPEND, for example.
   If the backquote syntax is nested, the innermost backquoted form
   should be expanded first.  This means that if several commas occur in
   a row, the leftmost one belongs to the innermost backquote.
   Once again, it is emphasized that an implementation is free to
   interpret a backquoted form as any form that, when evaluated, will
   produce a result that is EQUAL to the result implied by the above
   definition.  In particular, no guarantees are made as to whether the
   constructed copy of the template will or will not share list
   structure with the template itself.  As an example, the above
   definition implies that `((,A B) ,C ,@D) will be interpreted as if it
   were

       (append (list (append (list a) (list 'b) 'NIL)) (list c) d 'NIL)

   but it could also be legitimately interpreted to mean any of the
   following:

       (append (list (append (list a) (list 'b))) (list c) d)
       (append (list (append (list a) '(b))) (list c) d)
       (append (list (cons a '(b))) (list c) d)
       (list* (cons a '(b)) c d)
       (list* (cons a (list 'b)) c d)
       (list* (cons a '(b)) c (copylist d))

   (There is no good reason why COPYLIST should be performed, but it is
   not prohibited.)


Date:  3 September 1982 1803-EDT (Friday)
From: Guy.Steele at CMU-10A
To: common-lisp at SU-AI


- - - - Begin forwarded message - - - -
Mail-From: ARPANET host CMU-20C received by CMU-10A at 2-Sep-82 03:25:30-EDT
Mail-from: ARPANET site MIT-MC rcvd at 2-Sep-82 0324-EDT
Date: 2 September 1982 03:21-EDT
From: Kent M. Pitman <KMP at MIT-MC>
Subject:  macro expansion
To: Fahlman at CMU-20C
cc: Steele at CMU-20C

    Date: Sunday, 29 August 1982  23:56-EDT
    From: Scott E. Fahlman <Fahlman at Cmu-20c>
    To:   Common-Lisp at SU-AI
    Re:   macro expansion

    ... The only quibble I have is whether we want to spell *MACROEXPAND-HOOK*
    with the stars.  We should only do this if we decide to spell all (or
    almost all) built-in global hooks this way...
-----
As I mentioned at the last common lisp meeting, I advocate the *...* naming
convention for two reasons:

 * It clearly identifies special variables. Makes it easy to tell which
   compiler "... undeclared, assumed special" warnings are worth worrying
   about.

 * It means that variables and functions are in different namespaces, which
   may be important in the package system you devise since currently there is
   no way to export only the value cell or only the function cell of a symbol.

-kmp
- - - - End forwarded message - - - -


Date:  3 September 1982 1756-EDT (Friday)
From: Guy.Steele at CMU-10A
To: common-lisp at SU-AI
Subject:  REDUCE function re-proposed

I would like to mildly re-propose the REDUCE function for Common
LISP, now that adding it would require only one new function, not ten
or fifteen:


REDUCE function sequence &KEY :START :END :FROM-END :INITIAL-VALUE
    The specified subsequence of "sequence" is reduced, using the "function"
    of two arguments.  The reduction is left-associative, unless
    :FROM-END is not false, in which case it is right-associative.
    If the an :INITIAL-VALUE is given, it is logically placed before the
    "sequence" (after it if :FROM-END is true) and included in the
    reduction operation.  If no :INITIAL-VALUE is given, then the "sequence"
    must not be empty.  (An alternative specification: if no :INITIAL-VALUE
    is given, and "sequence" is empty, then "function" is called with
    zero arguments and the result returned.  How about that?  This idea
    courtesy of Dave Touretzky.)

    (REDUCE #'+ '(1 2 3 4)) => 10
    (REDUCE #'- '(1 2 3 4)) => -8
    (REDUCE #'- '(1 2 3 4) :FROM-END T) => -2   ;APL-style
    (REDUCE #'LIST '(1 2 3 4)) => (((1 2) 3) 4)
    (REDUCE #'LIST '(1 2 3 4) :FROM-END T) => (1 (2 (3 4)))
    (REDUCE #'LIST '(1 2 3 4) :INITIAL-VALUE 'FOO) => ((((FOO 1) 2) 3) 4)
    (REDUCE #'LIST '(1 2 3 4) :FROM-END T :INITIAL-VALUE 'FOO)
				 => (1 (2 (3 (4 FOO))))

--Guy


Date: 3-Sep-82 10:57:24-PDT (Fri)
From: ucbvax:<Kim:jkf> (John Foderaro)
Subject: Re: cases, re: kmp's and moon's mail
Message-Id: <60852.25601.Kim@Berkeley>
Received: from UCBKIM by UCBVAX (3.177 [8/27/82]) id a01465; 3-Sep-82 10:57:45-PDT (Fri)
Via: ucbkim.EtherNet (V3.147 [7/22/82]); 3-Sep-82 10:57:25-PDT (Fri)
To: Fahlman@Cmu-20c
Cc: common-lisp@SU-AI
In-Reply-To: Your message of Friday, 3 September 1982  13:20-EDT

  I've gotten 41 responses so far on my survey.  These responses were all to
the franz-friends poll and most were from the arpanet.   I think that many
Franz Lisp users are reachable only via uucp,  yet I haven't gotten any
responses from a uucp site.   I've pretty sure that our recent hardware
problems prevented the poll from reaching uucp land.  I will try sending the
poll again just to uucp sites.

  Our 'Mail' machine has been up for over a day now (a modern record) but
there still seem to be problems (I've received three copies of the last
letter I sent).  I apologize in advance for the number of copies of this
message you may receive.





Date: Friday, 3 September 1982  13:20-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To:   ucbvax:<Kim:jkf at CMU-20C
Cc:   common-lisp at SU-AI
Subject: cases, re: kmp's and moon's mail


John,

Before we try to reach a final decision, did anything ever come of your
polling of the Franz Lisp mailing list?  I would be most interested in
the results of this poll (or lack of results, which I would consider
very significant) before deciding for sure where I stand on this issue.
Right now, I still favor the case-insensitive status quo over the
"switch" proposal or the "modest" proposal, but the input from the unix
people could make a difference, especially for the Vax/Unix
implementation we are doing.

-- Scott


Date: 3-Sep-82 09:08:30-PDT (Fri)
From: ucbvax:<Kim:jkf> (John Foderaro)
Subject: cases, re: kmp's and moon's mail
Message-Id: <60852.23814.Kim@Berkeley>
Received: from UCBKIM by UCBVAX (3.177 [8/27/82]) id a28737; 3-Sep-82 09:08:51-PDT (Fri)
Via: ucbkim.EtherNet (V3.147 [7/22/82]); 3-Sep-82 09:08:32-PDT (Fri)
To: common-lisp@su-ai

    Let me once again ask that we not let our personal feelings about the
subject determine how Common Lisp should treat cases.

    Kent says that he has trouble remembering cases in words.  I can accept
that but Kent should not generalize and say that this is try of all people.
I know plenty of people who have no trouble remembering cases and can even
converse in a case-sensitive domain without any strain.  I haven't had a
chance to talk to most of you in person but I guess that you pronounce
'load-byte' as "load byte", not as "load hyphen byte".   How would you
pronounce 'loadbyte'?   The points are these:
 1) don't shackle others with your limitations
 2) The ability to imply a hyphen by just saying "load byte" is an example
    of how conventions are used to map a sequence of syllables into 
    a string of characters.  In another context the same people could use
    a convention whereby "load byte" meant "LoadByte".


Re:
    From: David A. Moon <Moon at SCRC-POINTER at MIT-MC>

    Masinter's "modest" proposal instead forces case-sensitivity on everyone,
    whether they like it or not.  There is the possibility of using two cases,
    however this is a fraud, because you are only allowed to use one case in
    portable programs.
    
	
I am not sure whether Moon's fingers slipped or if he really thinks that
Masinter's proposal refers to 'portable' programs.  In fact, Masinter's
proposal says that all 'public' programs must be in lower case:

   From: Masinter at PARC-MAXC
   b) All symbols in packages admitted into the Common Lisp white- and yellow-
      pages are REQUIRED to be lower case. 

Everyone wants their programs to be portable, so the set of portable
programs is (almost) equivalent to the set of all programs written in Common
Lisp.   However the set of all 'public' programs, that is those that are
documented in the white and yellow pages, will be a small subset of the set
of Common Lisp programs.   While Masinter's proposal requires the 'public'
programs to follow the convention of all lower case, it says nothing about
what my private programs have to look like.    However, I write a
piece of code which is useful enough to be added to the public code, then
that code will be translated to lower case before being added.


    I think that most people understand the arguments on both sides now and
I would like to see this resolved one way or the other.   Could the
implementors get together and come up with a policy decision?





Date: 3-Sep-82 09:08:30-PDT (Fri)
From: ucbvax:<Kim:jkf> (John Foderaro)
Subject: cases, re: kmp's and moon's mail
Message-Id: <60852.23814.Kim@Berkeley>
Received: from UCBKIM by UCBVAX (3.177 [8/27/82]) id a28737; 3-Sep-82 09:08:51-PDT (Fri)
Via: ucbkim.EtherNet (V3.147 [7/22/82]); 3-Sep-82 09:08:32-PDT (Fri)
To: common-lisp@su-ai

    Let me once again ask that we not let our personal feelings about the
subject determine how Common Lisp should treat cases.

    Kent says that he has trouble remembering cases in words.  I can accept
that but Kent should not generalize and say that this is try of all people.
I know plenty of people who have no trouble remembering cases and can even
converse in a case-sensitive domain without any strain.  I haven't had a
chance to talk to most of you in person but I guess that you pronounce
'load-byte' as "load byte", not as "load hyphen byte".   How would you
pronounce 'loadbyte'?   The points are these:
 1) don't shackle others with your limitations
 2) The ability to imply a hyphen by just saying "load byte" is an example
    of how conventions are used to map a sequence of syllables into 
    a string of characters.  In another context the same people could use
    a convention whereby "load byte" meant "LoadByte".


Re:
    From: David A. Moon <Moon at SCRC-POINTER at MIT-MC>

    Masinter's "modest" proposal instead forces case-sensitivity on everyone,
    whether they like it or not.  There is the possibility of using two cases,
    however this is a fraud, because you are only allowed to use one case in
    portable programs.
    
	
I am not sure whether Moon's fingers slipped or if he really thinks that
Masinter's proposal refers to 'portable' programs.  In fact, Masinter's
proposal says that all 'public' programs must be in lower case:

   From: Masinter at PARC-MAXC
   b) All symbols in packages admitted into the Common Lisp white- and yellow-
      pages are REQUIRED to be lower case. 

Everyone wants their programs to be portable, so the set of portable
programs is (almost) equivalent to the set of all programs written in Common
Lisp.   However the set of all 'public' programs, that is those that are
documented in the white and yellow pages, will be a small subset of the set
of Common Lisp programs.   While Masinter's proposal requires the 'public'
programs to follow the convention of all lower case, it says nothing about
what my private programs have to look like.    However, I write a
piece of code which is useful enough to be added to the public code, then
that code will be translated to lower case before being added.


    I think that most people understand the arguments on both sides now and
I would like to see this resolved one way or the other.   Could the
implementors get together and come up with a policy decision?





Date:  3 Sep 1982 1124-EDT
From: HEDRICK at RUTGERS (Mgr DEC-20s/Dir LCSR Comp Facility)
Subject: administrative request
To: common-lisp at SU-AI

Who do we ask to get people added to this list?  We have asked RPG,
but that didn't seem to have any effect.  We need to add JOSH and
FISCHER at Rutgers.  I have been forwarding things to them, but I
am about to go away for a week, so unless they can get added, they
will effectively be cut off during that time.
-------


Date: Friday, 3 September 1982, 05:03-EDT
From: David A. Moon <Moon at SCRC-POINTER at MIT-MC>
Subject: case-sensitivity: an immodest proposal
To: Common-Lisp at SU-AI

I guess I need to amplify on my previous message, even at the risk of
discussing this to death, since my previous brief flame left too much
to the imagination.

The case behavior in the current Common Lisp manual forces case-insensitivity
on everyone, whether they like it or not.  There is a possibility of a standard
mode that you can turn on to get case-sensitivity, with the details not
fully specified.  However, this is a fraud, because you aren't allowed to
use it in portable programs.

Masinter's "modest" proposal instead forces case-sensitivity on everyone,
whether they like it or not.  There is the possibility of using two cases,
however this is a fraud, because you are only allowed to use one case in
portable programs.

So what we end up with is a choice between being allowed to use either case,
but not having the cases distinguished, or only being allowed to use one
case (lower), in portable programs.  It seems to me that all the modest
proposal accomplishes (for portable programs) is not allowing them to
be written in upper case, hardly an improvement.


Date: 3 September 1982 01:52-EDT
From: Kent M. Pitman <KMP at MIT-MC>
To: common-lisp at SU-AI

I agree with Moon re case-sensitivity. I think any proposal involving case
sensitivity as a default is a very bad idea.

I have avoided sending mail to this list which enumerates by particular 
feelings on case because I imagine everyone has a lot to say about it and
I've tried not to contribute excessively without having something truly
novel to say. But since people are starting to draw conclusions by the lack
of mail opposing the idea of case-sensitivity, let me say that this lack
of mail doesn't mean that people don't object, it just means that no vote
has been taken (nor, as someone pointed out, is a vote necessarily the way
to decide such an issue) so I think people are just mostly listening to what
others have to say.

As long as you've got this message anyway, I might as well put out my views
so they'll be on record and I won't have to send another later...

* I think case sensitivity has no place in a language (formal or otherwise).
  WORDS are Words are words. People remember the auditory representation of
  words and since case is not pronounced, it is hard to remember. Languages
  should be designed such that you can comfortably talk in or about them 
  and having to say "Oh, you need the function capital KILL" or say 
  send mail to me as "Capital P Little I-T-M-A-N at Multics" is really 
  awkward.

* Any case sensitivity is prone to ideosyncracy. If I happen to *like* 
  upper case or even just uniform case (ThisDrivesMeUpAWall!), it's nice
  that I can write my code one way and you another and they'll still talk
  back and forth. Lack of case sensitivity gives a shield from peoples'
  odd casing styles which actually allows people more flexibility in their
  use of case, not less.

I spent my first few years (what I would have expected to be my "formative
years") on case sensitive systems (Multics, Unix) and was truly happy to 
find Maclisp's readtime character translation... Basically, it lets me write
code in whatever case I like and since I type to an editor and just load
code and run it and most anything that types out had "..." around it anyway,
so I get nice mixed case output.

Indeed, I wonder often if part of the push from the Interlisp crowd for mixed
case does not revolve around their heavier use of an in-core editting
which causes them to have to worry about "losing" the case information
in their source code where in the case of Maclisp/LispM since functions 
are almost always defined in an external editor (in the LispM case, a
well-integrated external editor) and the actual source is never touched
by anything which would propose to change its case...


Date: 3 September 1982 00:46-EDT
From: Kent M. Pitman <KMP at MIT-MC>
Subject:  It's not just "LOOP vs DO"...
To: COMMON-LISP at SU-AI

I might point out that Dick Waters (DICK@ML) is working on some macros
for iteration which looks like it may have much the same expressive
power as LOOP but in a far more natural notation. There is a small
community of users now experimenting with his package (called letS) and
he's working on a paper about it. It is not quite ready even for release
yet and I certainly wouldn't propose it be considered for a standard
anytime soon, but it does show a lot of promise ... On the other hand, I
think there's not a clear concensus that LOOP is the right thing. I'll
agree with LOOP people that more abstraction on LOOPs are needed than
just DO but I'm not sure that LOOP is the right answer (I'd certainly
never use it) ...  and I'd like to avoid people standardizing on
anything so controversial as LOOP while experimentation is still ongoing
with things that may prove as good. So in my mind, LOOP should
definitely not be in the white pages at this time and more importantly I
think people should keep their eyes open to other alternatives. It's not
like DO and LOOP are the only directions that things can go. Dave
Chapman (ZVONA@MC) had a very interesting macro called DO& which was yet
another alternative... I'm sure there are others.  From the point of
view of a standard, I think it's most reasonable to pick accepted
technology for the white pages and there I think DO and DO* are simple,
powerful (computationally adequate for writing any kind of loop), and
perhaps most importantly to the standard, have very well-understood and
well-accepted semantics.
-kmp


Date: 2-Sep-82 20:21:30-PDT (Thu)
From: ucbvax:<Kim:jkf> (John Foderaro)
Subject: scott's message about case sensitivity
Message-Id: <60852.14309.Kim@Berkeley>
Received: from UCBKIM by UCBVAX (3.177 [8/27/82]) id a10980; 2-Sep-82 20:21:49-PDT (Thu)
Via: ucbkim.EtherNet (V3.147 [7/22/82]); 2-Sep-82 20:21:31-PDT (Thu)
To: common-lisp@su-ai
In-Reply-To: Your message of Tuesday, 31 August 1982  10:56-EDT


    From: Scott E. Fahlman <Fahlman at Cmu-20c>
    I see two cutlures developing
    very quickly, one of which types in lower-case only and the other
    capitalizing assorted words, as in ThisIsaReallyUglySymbol.  It still
    looks like a recipe for chaos to me.
    
But such recipes already exist.  What if I decided to use the underscore
instead of the hyphen in compound word symbols?  What if I decide to
use an escaped space?
	load-byte    load_byte    load\ byte

The addition of one more convention, LoadByte, is not going to make much of
a difference.  If a person writes a package for general consumption he
should follow the conventions, if he chooses not to then he can break the
convention in a number of ways.






Date: 2 Sep 1982 19:50:40-PDT
From: Kim.fateman at Berkeley
To: common-lisp@su-ai
Subject: dlw's portability semantics

Of course portability has many dimensions.  I thought that CL
was supposed to refrain from gratuitous incompatibilities with
maclisp, interlisp, zetalisp, ... .  The purpose of this is presumably
to allow some previously working code to be moved to a CL system.

I would think that (regardless of the definition of LOOP in CL),
an interlisp LOOP  (or FOR, or whatever...)package would be useful.
Did you take umbrage at this notion, dlw?


Date: 2 Sep 1982 18:13 PDT
From: JonL at PARC-MAXC
Subject: Re: LOAD-BYTE and DEPOSIT-BYTE
In-reply-to: MOON's message of Tuesday, 31 August 1982  18:05-EDT
To: MOON at SCRC-TENEX
cc: JonL, common-lisp at SU-AI, Earl A. Killian <EAK at MIT-MC>,  Guy.Steele
 at CMU-10A

As per EAK's comments, some feel that LOAD-BYTE is preferable to LDB.
But in either case, I'd concurr that the combination of both is "redundant";
I wouldn't concur that one or the other is "superfluous".



Date: 2 Sep 1982 18:09 PDT
From: JonL at PARC-MAXC
Subject: Re: macro expansion
In-reply-to: Moon at SCRC-TENEX's message of Sunday, 29 August 1982,
 21:26-EDT
To: David A. Moon <Moon at SCRC-TENEX at MIT-MC>
cc: Common-Lisp at SU-AI

I think Scott may be mistaken when he says that Chapter 8 of the Colander
edition is the MacLisp style -- it's more the LispM style from some months
ago.  I and RWK introduced multiple-value returning MACROEXPAND into
MacLisp/NIL some years ago, and shortly thereafter added in an expander
hook;  I think those changes were documented in the usual LISP.RECENT
messages.   Since then, the NIL version has been supplanted by yet a third
(incompatible) scheme, but this brings up a couple of questions on your 
proposal as of this dateline:

  1) Why not have MACROEXPAND return the second value, as obtained
    from MACROEXPAND-1  ?  A typical usage merely wants to "do all and 
    any expansions" and also be informed as to whether or not anything really
    happened.   It might even be worthwhile for this second return value, when
    non-null, to distinguish between the case of having actually run the
    expansion function and having found the expansion in some "memoization"
    facililty.    (the file [MC]NILCOM;DEFMAX > shows the "...-1" function 
    spelled MACROEXPAND-1*M, but only to retail losing compatibility with 
    the Lispm on the name MACROEXPAND-1). 

  2) We saw the need for a function called FIND-MACRO-DEFINITION,
    which more-or-less fulfills the purpose of the "blank" in your
    definition labelled "---get expander function---";  thus there is one
    place responsible for things like:
      2a) autoloading if the macro is not resident but does have an 
        AUTOLOAD property, or 
      2b) looking on the the alist found in MACROLIST so that one may 
        lambda-bind a macro definition without disturbing the function
        definition cell (nor the propertylist).

  3) although MacLisp/NIL didn't call it a general macro-expander-hook 
    the variable MACRO-EXPANSION-USE supplied just that facility
    (in coordination with DEFMACRO); also, it "distributed" the fetching of
    memoized expansions on a per-macro basis, so that there could be some 
    variablilty;  after all, a uniform *default* is fine, but ocasionally there is 
    a macro which wants to say "don't memoize me at all".   I'd say that there
    is a lacuna in your proposal in that you don't exhibit code for the case of   
    traditional memoizing by hashtable -- that will show how the macroexpansion
    function is selectively called depending on the hashtable entry.  

  4) we often felt the need for an additional argument to the expansion
    function which tells *why* this macro call is being expanded -- e.g.,
    EVAL, or COMPILE, or  FOR-VALUE, or FOR-EFFECTS etc.  I can't
    characterise all such cases, but GSB, KMP, and RWK may have some
    good inputs here.


Point 3 brings up another possibililty -- maybe your current definition of
*MACROEXPAND-HOOK* is an over-generalization.  That is, why not
have two hooks, one for testing whether or not a "memoization" is present
for the macro call in question (and returning it if present), and another hook
of three arguments namely:
      i) a pointer to the original cell (macro call),
     ii) the already-computed expansion form, and
    iii) a symbol to indicate the reason why the macro call was "expanded"
I realise that iii) will require more discussion, so maybe now is not the time
to put it into CommonLisp; also the memoization hook would have to return
a second value to indicate whether a memo was present.

In any case, I'd rather see the default value for these macro hooks be NIL,
so that one didn't have to understand the complexities of expansions and
memoizations just to get the default case (that is, unless someone plans to
allow NIL as a valid function name and . . . )


     


Date: 2 Sep 1982 15:25 PDT
From: JonL at PARC-MAXC
Subject: Re: Circular structure printing
In-reply-to: dlw at SCRC-TENEX's message of Sunday, 29 August 1982,
 11:33-EDT
To: Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC>
cc: common-lisp at su-ai

InterLisp has had HPRINT for some time, which among other things prints out
circular structure in a "readable" fashion.  Having a separate function for this
purpose, rather than a Global variable flag which affects PRINT, may be a better
route as long as the PRIN1/PRINC dichotomy remains.  Unfortunately, this means
that every place where the PRIN1/PRINC dichotomy appears will not have to
become a PRIN1/PRINC/PRINH trichotomy (e.g., such as in EXPLODE and
PRIN?-TO-STRING). 

Efficiency in HPRINT is obtained by looking for circularities in a hash table,
and either 1) for randomly-accessible files doing the equivalent of a
FILE-POSITION to go back and insert a macro character in front of the
"first" occurrence, or 2) otherwise just printing to a "temporary, in-core"
file and then unloading the temproary file to the real output file.   This
code is, I think, in the public domain, so you could look at it if you still
want to;  printing to a "temporary" file is of course equivalent to SEF's 
suggestion to print first to a string.   [by the bye, HPRINT stands for 
"Horrible PRINT" since it handles all the horrible cases].

LISP/370 had a printer which did circularities right.   It was my subjective,
non-documented, feeling that there was no discernible time loss in this code; 
but then again it used 370 machine language and, depended upon having an
alternate "heap" to use as a hash table.   Might be nice to know what some
of the purely-Lisp written printers cost in time.

Beau Sheil noted an interesting comment about the reference-count GC
scheme of InterLisp-D:  since it's primarly structure-to-structure pointers
that are reference-counted (not local variables or stack slots), then a quick,
generally-useful, and fail-safe test for non-circularity is merely a bittest from
the GC table.  This is not how HPRINT is implemented, since it runs on the
PDP10 too, but is an interesting observation about the effects of GC strategy.



Date: 2-Sep-82 14:40:46-PDT (Thu)
From: ucbvax:<Kim:jkf> (John Foderaro)
Subject: Re: case-sensitivity: a modest proposal
Message-Id: <60852.6065.Kim@Berkeley>
Received: from UCBKIM by UCBVAX (3.177 [8/27/82]) id a03637; 2-Sep-82 14:41:10-PDT (Thu)
Via: ucbkim.EtherNet (V3.147 [7/22/82]); 2-Sep-82 14:40:51-PDT (Thu)
To: MOON@SCRC-TENEX
Cc: common-lisp@su-ai
In-Reply-To: Your message of Thursday, 2 September 1982  17:01-EDT

  I disagree with your remark that something is being rammed down everyone's
throat.  On the contrary, I think that all messages on the subject (with the
exception of yours) have been cautious and well thought out and I believe
that we are gradually approaching something most people can live with.





Date: Thursday, 2 September 1982  17:23-EDT
From: MOON at SCRC-TENEX
To: FEINBERG at CMU-20C
Cc: Common-Lisp at SU-AI
Subject: Loop vs Do

The issue is not that DO is terrible, but that DO only implements a small
subset of what LOOP does.  Specifically, DO only allows you to step variables
in parallel (sometimes you need the new value of one variable to depend on another,
and sometimes you don't), does not come with pre-packaged iterations through
various data structures, does not come with pre-packaged ways to create
return values in various ways, and does not allow you to control the order
of operations (variable-stepping vs end-test).

An example that works naturally in DO will not tell you anything about why
you need LOOP.  The problem is that writing many more complex iterations
with DO requires filling it up with SETQs and RETURNs (even GOs on rare
occasions).


Date: Thursday, 2 September 1982  17:01-EDT
From: MOON at SCRC-TENEX
to: common-lisp at SU-AI
Subject: case-sensitivity: a modest proposal

I don't think this proposal is modest at all.  It consists of ramming a
particular model down everyone's throat, which is no better than the status
quo (ramming a different particular model down everyone's throat).  I at least
would find case sensitivity by default to be totally unacceptable.


Date: Thursday, 2 September 1982  16:40-EDT
From: MOON at SCRC-TENEX
To: JonL at PARC-MAXC
Cc: Common-Lisp at SU-AI
Subject: Re: Access to documentation strings

    Date: 2 Sep 1982 12:46 PDT
    From: JonL at PARC-MAXC

    On the other hand, I'm not sure I see any value to the generalization of names
    from symbols to any lisp object -- can you provide any motivation for this?

The same reasons that you need it for function specs.


Date: Thursday, 2 September 1982  16:43-EDT
From: MOON at SCRC-TENEX
To: JonL at PARC-MAXC
Cc: Common-Lisp at SU-AI
Subject: Re: CHECK-ARG-TYPE [and CHECK-SUBSEQUENCE]

I don't care whether CHECK-ARG-TYPE is called that or CHECK-TYPE, as long
as it exists.  CHECK-SUBSEQUENCE seems to be a good idea.


Date: 2 September 1982  16:43-EDT (Thursday)
From: FEINBERG at CMU-20C
To:   Common-Lisp at SU-AI
Subject: Loop vs Do

	I have heard how terrible DO is, and how winning LOOP is.
Could some kind person supply examples of *typical* loops using both
DO and LOOP?


Date: 2 Sep 1982 13:32 PDT
From: JonL at PARC-MAXC
Subject: Re: 2nd generation LOOP macro
In-reply-to: Fahlman's message of Thursday, 26 August 1982  20:43-EDT
To: Scott E. Fahlman <Fahlman at Cmu-20c>
cc: BUG-LOOP at MIT-ML, Common-Lisp at SU-AI

Let me proffer a reason why LOOP should be even *white* pages.
Despite the best efforts of some functional programming people (especially
PROLOG?) iterative constructs won't go away; e.g. too often the translation of
a somewhat simple loop into functional equations leads to indecipherable
code.  Thus it would be well to standardize on some loop facility, if in
fact a standard can be found.

InterLisp's iterative statement facility *does not* share all the crocks of
CLISP (and was no doubt put there rather than being a macro due to
the primitive treatment of macros).  Furthermore, it's years of existence
as a standard within InterLisp, and its easy extensibility, speak well for it.
Both the past and current LOOP proposals are very very much like the
InterLisp iterative constructs, and should be viewed as having years of
support behind their basic ideas.

Another winning idea from the InterLisp iterative statement is that
the prettyprinter treats them specially, and tries to do a "good" job of
formatting so that the constituent parts stand out 2-dimensionally.  A real
defect of DO loops is that almost all minor exceptions to the simple case
have to appear in the code in some place that obscures their nature
(e.g., in the code body, or actually *before* the DO loop, or in the return
clause);  I realize that doing a "good" job will cause months of seemingly
endless discussion, but fruitage of this idea has got to be worth the effort.




Date: Thursday, 2 September 1982, 14:28-EDT
From: Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC>
Subject: string-out
To: common-lisp at su-ai

The STRING-OUT and LINE-OUT functions of the Swiss Cheese manual are
mysteriously missing from the Colander manual.  Is this intentional?  I
hope not.  These (particularly the former) are useful functions.


Date: 2 Sep 1982 12:46 PDT
From: JonL at PARC-MAXC
Subject: Re: Access to documentation strings
In-reply-to: Moon at SCRC-TENEX's message of Thursday, 26 August 1982,
 03:25-EDT
To: David A. Moon <Moon at SCRC-TENEX at MIT-MC>
cc: Common-Lisp at SU-AI

I think you've got your hand on something bigger than merely documentation
strings; the question of "object types", or "definition type" if you will, 
parallels the InterLisp "file package" facility.  Despite the name "file pkg", 
this facililty is really about a coordinated database for user code ("user"
can include the system, since most of it is written in Lisp now).  I wouldn't
want to see progress on documentation held up at all, but it might be wise
to consider DOCUMENTATION in the light of such a coordinated facility.

File Pkg allows user-extensions to the "types" in a uniform way;  it interfaces
not only to file manipulation commands, but also with MasterScope comands.
Only recently (sadly) did InterLisp correctly separate out the multiple
definitions, e.g. some name being both a Global variable (a VARS type) and
also a function name (a FNS type), but this is a must. 

On the other hand, I'm not sure I see any value to the generalization of names
from symbols to any lisp object -- can you provide any motivation for this?



Date: 2 Sep 1982 12:30 PDT
From: JonL at PARC-MAXC
Subject: Re: CHECK-ARG-TYPE [and CHECK-SUBSEQUENCE]
In-reply-to: Moon at SCRC-TENEX's message of Thursday, 26 August 1982,
 03:04-EDT
To: David A. Moon <Moon at SCRC-TENEX at MIT-MC>
cc: Common-Lisp at SU-AI

PDP10 MacLisp and VAX/NIL have had the name CHECK-TYPE for several 
years for essentially this functionality (unless someone has recently renamed
it).   Since it is used to certify the type of any variable's value,  it did not
include the "-ARG" part.  The motivation was to have a "checker" which was
more succinct than CHECK-ARGS, but which would generally open-code the
type test (and hence introduce no delay to the non-error case).  

I rather prefer the semantics you suggested, namely that the second argument 
to CHECK-TYPE be a type name (given the CommonLisp treatment of type
hierarchy).  At some level, I'd think a "promise" of fast type checking should
be guaranteed (in compiled code) so that persons will prefer to use this
standardized facililty;  without some indication of performance, one would
be tempted to write his own in order not to slow down the common case.


If the general sequence functions continue to thrive in CommonLisp, I'd
like to suggest that the corresponding CHECK-SUBSEQUENCE macro (or
whatever renaming of it should occur) be included in CommonLisp.  

  CHECK-SUBSEQUENCE (<var> <start-index> <count>) &optional <typename>  

provides a way to certify that <var> holds a sequence datum of the type
<typename>, or of any suitable sequence type (e.g., LIST, or STRING or 
VECTOR etc) if <typename> is null; and that the indicated subsequence
in it is within the size limits.
 


Date: 2 Sep 1982 11:46 PDT
From: JonL at PARC-MAXC
Subject: Re: a miscellany of your comments
In-reply-to: Killian's message of 25 August 1982 1452-pdt
To: Earl A. Killian <Killian at MIT-MULTICS>
cc: Fahlman at CMUc, Common-Lisp at SU-AI

Re Fixing of names now:
I certainly hope that Fahlman&Co can proceed without another meeting.
Even after initial stabilization, there will  likely be need for regular meetings
(say, after each Lisp Conference?)

Re case sensitivity:
As long as we agree in principle that the READer be user-tailorable for
case sensitivity, then it may not be necessary to specify just how such change
is effected;  I'd prefer the MacLisp way wherein each character can be
individually "translated", but that generality is seldom used.   On the other
hand, it would seem preferable to have the switch for case-sensitivity in
the ReadTable rather than somewhere else.  InterLisp puts it in the "terminal
table", so that conversion takes place as it were within the input stream
for the connected terminal;  the two lossages with this treatement are that
  1) translation takes place for non-READ operations too [such as INCH], 
  2) no translation takes place for READing from files.

Re InterLisp status on case sensivity:
You may be under a misconception in the comment about InterLisp:
    "Doing this would let you write code as in
         (SETQ MultiWordVarName NIL)
     as many Interlisp users do all the time (though possible in Maclisp, 
     it never caught on). "
InterLisp does not standardize to uppercase as MacLisp does, so the name
MultiWordVarName remains mixed-case.  As it happens, some of the
CMU MacLisp users have been using mixed-case names in their files
for some time (but of course they are upper-cased upon read-in).





Date: 2 Sep 1982 10:33 PDT
From: JonL at PARC-MAXC
Subject: Re: SETF and friends [and the "right" name problem]
In-reply-to: RWK's message of 25 August 1982 04:41-EDT
To: Robert W. Kerns <RWK at MIT-MC>
cc: common-lisp at SU-AI

Apologies for replying so late to this one -- have been travelling for a week
after AAAI, and *moving to a new house* -- but I want to add support to
your comments.

Two issues seem to be paramount here:

1) I too would not like to see this change, specifically because it would
   incompatibly destroy the name for the time-honored SET function, and
   this surely falls into the category of "gratuitous" incompatibilities which
   CommonLisp promised not to do [I don't particularly like the notion of
   "fixing up" oddball names, such as HAULONG, but at least in that one
   case the number of users who've ever used HAULONG is probably a drop
   in the bucket compared to those who've ever used SET].

2) It must be an inevitable consequence of standardization in a large community
   that undue proportions of time are spent arguing over the "right" name for
   some functionality -- according to reports, this happened in the PASCAL
   world, so at least in one dimension Lisp is beginning to look like Pascal.

   "Right" apparently means "English-based and functionally descriptive", and
   so often one man's mnemonic is another man's anathema.   I think it must be
   conceded that for frequently used primitive operators, a short name, even if
   nonsensical, is to be preferred to a "right" one.  E.g.,  CONS is better than
   ALLOCATE-NEW-LIST-CELL.  

   Couldn't we resist the urge to rationalize every name?



Date: Thursday, 2 September 1982, 12:07-EDT
From: Richard E. Zippel <RZ at MIT-MC>
Subject: case-sensitivity: a modest proposal
To: common-lisp at SU-AI

Except for the moderate pain in converting a bunch of code to lower
case, I think Masinter's proposal is pretty good.   


Date: 2 Sep 1982 11:21:43-EDT
From: jkf at mit-vax at mit-xx
To: common-lisp@su-ai
Subject: Masinter's modest proposal

  Due to hardware problems at Berkeley, we are days behind in receiving
arpanet mail.  Therefore some of these remarks may be dated:

  I fully support Masinter's proposal and I am a little surprised that others 
haven't criticized it.  As I see it, his proposal differs from mine in two
ways:
1) He wants the language to be case-sensitive always whereas I wanted a switch
   to allow it to be insensitive too.  The reason I suggested a switch
   was that I thought there were people out there who like to vary the
   capitalization of symbols: eg (DO ((x (CAR y) (CDR x))) () (PRINT x)).
   If people don't really care to have a case-insensitive mode, that is 
   fine with me.

2) He proposes that all public symbols be lower case.  This is really a style
   question and I favor such a proposal.  I think that it is important to
   be consistent in a language like lisp where there are so many symbols
   to remember.


					- John Foderaro


Date:     1 September 1982 1257-pdt
From:     Earl A. Killian            <Killian at MIT-MULTICS>
Subject:  lambda
To:       DLW at MIT-AI
Cc:       Common-Lisp at SAIL

Allowing (LAMBDA ...) to evaluate does not prevent you from having a
LIST funciton and a LIST variable.  What are you objecting to?  I never
suggested getting rid of FUNCITON, which is still necessary for symbols,
or the dual value cell concept.

Btw, I should have pointed out in my original message that the two
isssues are completely independent.  I.e. you can have A, B, or both.

Getting rid of '(LAMBDA ...) is removing an ugly blemish from the
language, but since no one is forcing me to write it, it doesn't really
effect me, though it might effect an implementor.

But I'd like to use (LAMBDA ...) in my own code, and I'd rather not have
to change it for it to go into the yellow pages...


Date: Wednesday, 1 September 1982  05:51-EDT
Sender: DLW at MIT-OZ
From: DLW at MIT-MC
To:   Earl A. Killian <EAK at MIT-MC>
Cc:   common-lisp at SU-AI
Subject: lambda

I presume the reason that (lambda () ...) does not evaluate is
because Common Lisp, unlike Scheme, has the dual notions of
"functional meaning" and "value meaning".  The former is used
for the first element of a non-special form list, and the
latter is used for the rest.  FUNCTION is provided to allow
"functional" meaning in "value" context.  This is all so that
we can have a LIST function and still let people have variables
named LIST.
-------


Date: 1 September 1982 03:42-EDT
From: Kent M. Pitman <KMP at MIT-MC>
Subject: '(LAMBDA ...)
To: COMMON-LISP at SU-AI

I might also note that there are users who think it's acceptable to type
'(LAMBDA ...) because it's supported as a compatibility thing.

In the past few months I spent a lot of time looking over a certain 
large system which had been written for Maclisp and transported to the LispM 
and which ran far slower than was considered reasonable. In poking around,
I noticed that 20% of the time was being lost to calls to EVAL in what I
thought was to be a compiled system. I later found that this was because 
someone was putting '(LAMBDA ...) instead of #'(LAMBDA ...) and was therefore
not getting compiled code in some places that desperately needed it. If the
evaluator had just been firm and disallowed quoted lambdas as funcallable
things, it'd have caused a minor amount of grief getting the system up, 
but everyone would have been much happier in the long run.

The convenience, it seems to me, should be disallowed to wake people up
to the fact that a quoted lambda is going to win only in just enough
cases to give the illusion of safety and in general is just going to
cause any number of unexplained slowdowns or mysterious binding problems
as suggested by EAK.

Asking implementors to disallow (LAMBDA ...) as a function is a bit extreme
for common-lisp, but making it undefined in the common-lisp spec and 
encouraging implementors to disallow it seems a reasonable approach.

I also agree with EAK that
 (defmacro lambda (bvl &body body) `#'(lambda ,bvl ,@body))
is a winning abbreviation. 


Date: 1 September 1982 02:38-EDT
From: Earl A. Killian <EAK at MIT-MC>
Subject: lambda
To: common-lisp at SU-AI

The 29 July manual claims

1. (LAMBDA ...) is not evaluable.

and

2. '(LAMBDA ...) is a valid function.

On 1, I see no reason for (LAMBDA ...) not to evaluate to a function
(i.e. as if it had (FUNCTION ...) wrapped around it).  So why not
allow it?  Scheme pioneered this, and I think it was quite
aesthetic.

On 2, isn't allowing this inviting users to screw themselves now
that we've got lexical scoping?  E.g.
	(LET ((A ...)) (SORT L '(LAMBDA (X Y) (< X (- Y A)))))
won't get the locally bound A.


Date: Tuesday, 31 August 1982  22:52-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To:   common-lisp at SU-AI
Subject: LOAD-BYTE and DEPOSIT-BYTE


I agree with Moon on the LOAD-BYTE business.  I think it's silly to have
two kinds of byte-hacking functions around when the conversion from
one form to the other is usually so trivial.

-- Scott


Date: 31-Aug-82 18:51:03 PDT (Tuesday)
From: Masinter at PARC-MAXC
Subject: Re: case-sensitivity and portability
In-reply-to: dlw at SCRC-TENEX's message of Tuesday, 31 August 1982, 11:37-EDT
To: common-lisp at SU-AI

I have on more than one occasion taken someone else's Interlisp program and (without very much pain) converted all of the MixedCaseIdentifiers to 
ALLUPPERCASE before including it in the Interlisp system (in which, although
mixed case is allowed, all standard functions are uppercase to avoid confusion.)

This has been acceptable. That is: "it tells the case-sensitive folks that 
it is OK for them to use mixed-case with sensitivity, but that if they do so, 
their package will have to be converted before it will be accepted into
CommonLisp."

Since it is often true that packages will have to be DEBUGGED before being
adopted, the changing of identifier names will pale in comparison....

Larry


Date: Tuesday, 31 August 1982  18:05-EDT
From: MOON at SCRC-TENEX
To: JonL at PARC-MAXC
Cc: common-lisp at SU-AI, Earl A. Killian <EAK at MIT-MC>, 
      Guy.Steele at CMU-10A
Subject: LOAD-BYTE and DEPOSIT-BYTE

I won't throw any bombs if we decide to put these in.  I vaguely remember
a meeting where we discussed compiler optimization such that
	(LDB (BYTE 1 I) W)
would be equivalent to
	(LOAD-BYTE 1 I W)
or whatever the arguments are.  This would make LOAD-BYTE fairly
superfluous.


Date: Tuesday, 31 August 1982  18:13-EDT
From: MOON at SCRC-TENEX
To: Common-Lisp at su-ai
Subject:Agenda item 61

Are we all agreed that the simple iterator proposed under the name CYCLE
will be renamed LOOP, even though the full LOOP will not be in the 1982
version of the "white pages"?

I suggest that the white pages contain a note that the meaning of a LOOP
expression with atoms in its body is explicitly undefined, and becomes
defined if you use the LOOP package in the yellow pages.  Note that only
lists are useful in the body of the proposed CYCLE special form.

I just don't want to have two names for the same thing.


Date: Tuesday, 31 August 1982  17:38-EDT
From: MOON at SCRC-TENEX
To: JonL at PARC-MAXC
Cc: common-lisp at SU-AI
Subject: Re: a protest

    Date: 30 Aug 1982 16:54 PDT
    From: JonL at PARC-MAXC
    Subject: Re: a protest
    In-reply-to: HEDRICK's message of 24 Aug 1982 1321-EDT
    To: HEDRICK at RUTGERS (Mgr DEC-20s/Dir LCSR Comp Facility)
    cc: common-lisp at SU-AI

    I thought CLOSUREs got discussed, but I'm not sure under which
    numbered item.  In particular, I thought we agreed upon having
    CLOSUREs "capture" local variables (as well as special variables), 
    and maybe we renamed this "locality" concept as "lexical".  

I think the word closure is being used for two things.  There is the
Lisp machine function CLOSURE, which closes over a named set of
special variables.  We seem to have agreed (through the mail) not to
put this into Common Lisp.

There is also the pseudo-mathematical concept of the closure of a function
over an environment.  I'm not sure but I think we have agreed to support
"full funarging" as part of the introduction of lexical scoping in
Common Lisp.  Thus (FUNCTION (LAMBDA ...)), or (FUNCTION FOO) where
FOO is defined with a LABELS, used as an argument passes a closure
(lower case) of that function as the argument.  The manual is silent
about the issue that this funarg is a different data type from the
function itself.


								But
    I don't remember any decision about allowing non-local GOs --
    what's the story?  (issue 68 isn't about non-local GO, since its
    concerned with the lexical scope around a CATCH-ALL).

This was agenda item #8.  We agreed that at least in principle there should
be no restrictions.  Item #49 (get rid of local scope, have only lexical
scope) is relevant, also.

Agenda item #68 is about PUSHNEW.


Date: Tuesday, 31 August 1982, 10:59-EDT
From: Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC>
Subject: LOOP and white pages.   
To: brooks at MIT-OZ at MIT-MC, common-lisp at SU-AI
In-reply-to: The message of 30 Aug 82 12:14-EDT from Rod Brooks <ROD at SU-AI>

    Date: 30 Aug 1982 0914-PDT
    From: Rod Brooks <ROD at SU-AI>
    ...here are some reasons that I am against it.

    In this example MULTIPLE-VALUE says where the variable names and the things
    that they will be bound to are (syntactically), but the scope of those
    bindings is determined by a context outside of the form with MULTIPLE-VALUE
    as its CAR....

As Alan pointed out, this is completely confused.  It has nothing to do
with LOOP.  The LOOP doesn't bind any variables or define any scopes in
this example; it could be replaced by a DO () (()) and the same things
would happen.

    While JLK is right that it is possible to write horrible code with DO, I don't
    agree that we have to jump in *now* with another mechanism, especially when that
    mechanism introduces radically new (and I believe bad) scoping rules. Lets leave
    LOOP in the yellow pages for now.

JLK's point is not taht it is possible to write horrible code with DO.
JLK's point is that it is NOT possible to write CLEAN code with DO in
many simple and common cases.

LOOP does not introduce any radical new scoping rules.  Please be more
careful before spreading stories like this around; the situation is
confused enough as it is.  Variables bound in a LOOP body are bound for
the duration of the body just as in DO and PROG and LET.


Date: Tuesday, 31 August 1982, 11:37-EDT
From: Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC>
Subject: case-sensitivity and portability
To: Fahlman at Cmu-20c, common-lisp at SU-AI
In-reply-to: The message of 29 Aug 82 13:07-EDT from Scott E. Fahlman <Fahlman at Cmu-20c>

I agree completely with your reasoning about why JKF's proposal does not
make it.  I feel the same way you do and have nothing to add.

Masinter's proposal is the only one I have ever heard that actually
meets all of the standard objections.  However, it is a strange
compromise; it tells the case-sensitive folks that it is OK for them to
use mixed-case with sensitivity, but that if they do so, their package
will never be accepted into the yellow pages (nor the white pages, of
course).  It might be an acceptable compromise.  The main problem from
the point of view of the case-insensitive people (us) is that we'd have
to convert every last drop of code to lower case.  Now, I have been
doing that in my own programming for the last few years because I like
the way it looks, but some of my friends who like the way upper case
looks might not be so happy; note that they are essentially required to
use only lower-case even in their own private code!

This proposal deserves serious consideration; I'd like to see more ideas
about it.  (Ideas, not flames, please...)


Date: Tuesday, 31 August 1982, 11:21-EDT
From: Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC>
Subject: function specs
To: Fahlman at Cmu-20c
Cc: Common-Lisp at SU-AI
In-reply-to: The message of 29 Aug 82 18:02-EDT from Scott E. Fahlman <Fahlman at Cmu-20c>

    Maybe all we disagree about is whether to call the location expression a
    name and whether to make up a whole new syntax for it, rather than using
    the SETF syntax.

That is exactly right.  A "function spec" is a Lisp object that
designates a cell that might hold a function object.  You suggest using
a retriever-form, instead of using the new syntax that we use.  Our new
syntax is no worse than the new syntax for Lisp data types provided by
Common Lisp; it's just another one of those kinds of thing.

The implication of your proposal is that we'd have to add a new function
to do the retrieval for any kind of funcion spec we put in.  For
example, there would have to be a function that took a function and a
number, and returned the Nth internal function of that function, so that
you could do (:INTERNAL FOO 2) (it could take a name, too, but that's
orthagonal).  I guess our feeling was that it was better to avoid
introducing a new function for each kind of function spec, and it was
better to just create a new object capable of representing general
function locations and have a set of functions (FDEFINITION and friends)
that interpret them.  But your suggestion has merit too.  I don't feel
strongly one way or the other right now; I'd like to hear other input
from people.


Date: Tuesday, 31 August 1982, 11:11-EDT
From: Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC>
To: Kim.fateman at UCB-C70, common-lisp at su-ai
In-reply-to: The message of 29 Aug 82 21:17-EDT from Kim.fateman at Berkeley

    Date: 29 Aug 1982 18:17:22-PDT
    From: Kim.fateman at Berkeley

    It might be appropriate to mention the way that Franz now accomodates
    various loop packages (simultaneously):
    ...This has enabled us to provide "portability" in a useful fashion.

    I hope that common lisp supports portability at least as well.

Let us not play semantic games.  "Portability" does not refer to the
ability to simultaneously support incompatible packages in the same Lisp
environement.  "Portability" means that a program can be moved from one
C.L. implementation on one machine to another on another machine and
still behave the same way.  Portability is one of the main goals of
Common Lisp; ability to support many LOOP packages with conflicting
names is no more a goal than is the ability to support user-defined
functions named CAR.  There's nothing about portability that says that
we may not define LOOP to be the name of a special form.


Date: Tuesday, 31 August 1982, 11:06-EDT
From: Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC>
Subject: 2nd generation LOOP macro
To: Fahlman at Cmu-20c, BUG-LOOP at MIT-ML, Common-Lisp at SU-AI
In-reply-to: The message of 27 Aug 82 21:11-EDT from Scott E. Fahlman <Fahlman at Cmu-20c>

    Date: Friday, 27 August 1982  21:11-EDT
    From: Scott E. Fahlman <Fahlman at Cmu-20c>

    Well, it is OK to write a portable package that explicitly requires
    something from the yellow pages, so we could still use your portable
    code and include the LOOP package with it.

The main problem with this is that it introduces a new phenomenon.  "I
thought that I'd use Moon's nifty new code-walker to improve my hairy
language extension, but unfortunately it uses the
Moon/Burke/Bawden/whomever LOOP package and so when I load it into my
environment it smashes my own LOOP package, so I can't use it." This is
a fundamental problem with the whole idea of the yellow pages; I don't
think there is any solution, so we should just live with it in general.

I think that it is important that LOOP go into the white pages, so that
our language has some reasonable way to get the same power in iteration
that other languages have, but obviously we need a real solid proposal
before this can be discussed.  If it is necessary to leave LOOP in the
yellow pages for a while before it is adopted, that is unfortunate but
acceptable.  

However, I'd like it to be made clear that LOOP is being seriously
proposed for eventual inclusion in the white pages even if it is only
going into the yellow pages for now, so that people will be encouraged
to try it, suggest improvements, and use it instead of ignoring it and
writing their own equivalent but gratuitously incompatible LOOP macros.
(Conceptually-different and non-gratuitously incompatible
keyword-oriented iterators are perfectly OK, of course.)


Date: Tuesday, 31 August 1982  10:56-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To:   common-lisp at SU-AI
Subject: Masinter's proposal on case


If we were to make Common Lisp case-sensitive, Masinter's proposal to
require every symbol in the white and yellow pages to be lower-case
would be essential to retaining everyone's sanity, but I oppose the
basic suggestion.  We might be able to defend the case-purity of the
white and yellow pages, but under this proposal there would still be a
lot of code written in mixed case, and users would still have the problem
of remembering the case of everything.  I see two cutlures developing
very quickly, one of which types in lower-case only and the other
capitalizing assorted words, as in ThisIsaReallyUglySymbol.  It still
looks like a recipe for chaos to me.

-- Scott


Date: 30 Aug 1982 16:54 PDT
From: JonL at PARC-MAXC
Subject: Re: a protest
In-reply-to: HEDRICK's message of 24 Aug 1982 1321-EDT
To: HEDRICK at RUTGERS (Mgr DEC-20s/Dir LCSR Comp Facility)
cc: common-lisp at SU-AI

I thought CLOSUREs got discussed, but I'm not sure under which
numbered item.  In particular, I thought we agreed upon having
CLOSUREs "capture" local variables (as well as special variables), 
and maybe we renamed this "locality" concept as "lexical".  But
I don't remember any decision about allowing non-local GOs --
what's the story?  (issue 68 isn't about non-local GO, since its
concerned with the lexical scope around a CATCH-ALL).



Date: 30 Aug 1982 16:42 PDT
From: JonL at PARC-MAXC
Subject: Re: byte specifiers
In-reply-to: Guy.Steele's message of 23 August 1982 2328-EDT (Monday)
To: Guy.Steele at CMU-10A
cc: Earl A. Killian <EAK at MIT-MC>, common-lisp at SU-AI

True, an integral "byte specifier" is useful, but last fall CommonLisp had
in it the very useful functions LOAD-BYTE and DEPOSIT-BYTE, which
took separate arguments for the "pp" and "ss" parts.

These two functions seem to have disappeared from the current CommonLisp
manual, without any discussion.  What happened?  I tried to bring this
matter up at Pgh last week, but it seems to have gotten lost in the wash.

Anyway, the value of separating them (if EAK's arguments weren't enough)
is that frequently the "ss" part is constant, but the "pp" part varying.  Just
for the record, the VAX has instructions which are like LOAD-BYTE, rather
than the PDP10ish LDB.



Date: 30 August 1982 13:43-EDT
From: Kent M. Pitman <KMP at MIT-MC>
Subject:  Access to documentation strings
To: Fahlman at CMU-20C
cc: Common-Lisp at SU-AI

The use of one-line documentation strings is not to provide complete 
documentation, it is to allow APROPOS-style primitives so that the user
can make a good guess about which functions to ask for full documentation on.

    Date: Monday, 30 August 1982  13:24-EDT
    From: Scott E. Fahlman <Fahlman at Cmu-20c>

    We already have a long-form documentation (the manual entry) and a short
    pocket-guide sort of entry (the documentation string) for each function...

I question the importance of this point. I think it's neat that you have so
much documentation of primitive functions, but you should definitely not think
of the primitive system as the only thing that's going to use this sort of 
documentation facility. You can expect other major systems (ZWEI, for example)
or imbedded languages (FRL, BrandX, etc.), all of which will be increasing the
size of the namespace considerably. When a user is searching for a primitive
he knows is there somewhere, the short-description facility is tremendously
useful. 


Date: Monday, 30 August 1982  13:17-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To:   Kent M. Pitman <KMP at MIT-MC>
Cc:   COMMON-LISP at SU-AI
Subject: No PRINT-time case conversion switch please!


KMP misunderstands the proposal for a switch to convert output to lower
case.  In the context of a Lisp that converts to upper case by default,
this switch would cause PRINT to do the following:

Figure out how the symbol would print normally, without the swtich being on.

If the symbol would print with |'s leave it alone.

Else, every character that is about to come out in upper case is
converted to lower-case and printed.  Lower-case chars, which would
normally be printed with slashes, are left untouched and the slash is
left in.

This is guaranteed to read in correctly with the upper-case-converting
reader.  If the user reads in such a file with conversion disabled, he
loses.

USER INPUT	OUTPUT (normal)		OUTPUT (with flag true)

FOO		FOO			foo
foo		FOO			foo
Foo		FOO			foo

|foo|		|foo|			|foo|
|X|		X			x
|x|		\x			\x

It is clear that, with or without the proposed switch, any printer has
to make some assumptions about what the reader is going to do.

-- Scott


Date: 30 August 1982 17:19-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject:  misinformation about LOOP
To: BROOKS at MIT-MC
cc: common-lisp at SU-AI

    Date: 30 Aug 1982 0914-PDT
    From: Rod Brooks <ROD at SU-AI>

    I haven't looked at the complete new proposal, but in MOON's MACRO example:

    (DEFUN MACROEXPAND (FORM &AUX CHANGED)
      "Keep expanding the form until it is not a macro-invocation"
      (LOOP (MULTIPLE-VALUE (FORM CHANGED) (MACROEXPAND-1 FORM))
	    (IF (NOT CHANGED) (RETURN FORM))))

    one sees a fundamentally new scoping system in action. In all other binding
    mechanisms (e.g. LET, DO, MULTIPLE-VALUE-BIND, DEFUN and even PROG with
    init values) the CAR of a form identifies the form type as one which will
    do binding which will remain in effect only within that form, and at the
    same time says where in the form one can find the variables and what they
    will be bound to. In this example MULTIPLE-VALUE says where the variable
    names and the things that they will be bound to are (syntactically), but
    the scope of those bindings is determined by a context outside of the form
    with MULTIPLE-VALUE as its CAR. On the other hand while the symbol LOOP
    determines the scope of the bindings (in the example at least) it doesn't
    determine the syntactic location of the variables and what they get bound
    to.

This is confused.  Moon could just as easily have written:

(DEFUN MACROEXPAND (FORM &AUX CHANGED)
  "Keep expanding the form until it is not a macro-invocation"
  (DO ()
      (NIL)
    (MULTIPLE-VALUE (FORM CHANGED) (MACROEXPAND-1 FORM))
    (IF (NOT CHANGED) (RETURN FORM))))

There is no problem I can see with determining the scope of any bindings made
by LOOP.  In Moon's code LOOP made NO bindings.


Date: Monday, 30 August 1982  13:24-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To:   Kent M. Pitman <KMP at MIT-MC>
Cc:   Common-Lisp at SU-AI
Subject: Access to documentation strings


We already have a long-form documentation (the manual entry) and a short
pocket-guide sort of entry (the documentation string) for each function.
In the long run, the manual will be available on-line, I am sure.  We
also have (in Spice Lisp, anyway) an on-line way of accessing the
argument-list of a function.  What I question is whether there is any
real use for a super-short one-line documentation string.  Having
attempted to write several of these, I find that it is almost impossible
to say something meaningful and not misleading about most functions in one
line or one short sentence.  That is why I would like to flush this idea
and just go with short and long.  I'm not sure that the Emacs experience
is relevant here.

If we do go with both short and super-short descriptions, I agree that
they should be separate strings hidden in separate places.

-- Scott


Date: Monday, 30 August 1982  13:24-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To:   Kent M. Pitman <KMP at MIT-MC>
Cc:   Common-Lisp at SU-AI
Subject: Access to documentation strings


We already have a long-form documentation (the manual entry) and a short
pocket-guide sort of entry (the documentation string) for each function.
In the long run, the manual will be available on-line, I am sure.  We
also have (in Spice Lisp, anyway) an on-line way of accessing the
argument-list of a function.  What I question is whether there is any
real use for a super-short one-line documentation string.  Having
attempted to write several of these, I find that it is almost impossible
to say something meaningful and not misleading about most functions in one
line or one short sentence.  That is why I would like to flush this idea
and just go with short and long.  I'm not sure that the Emacs experience
is relevant here.

If we do go with both short and super-short descriptions, I agree that
they should be separate strings hidden in separate places.

-- Scott


Date: Monday, 30 August 1982  13:24-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To:   Kent M. Pitman <KMP at MIT-MC>
Cc:   Common-Lisp at SU-AI
Subject: Access to documentation strings


We already have a long-form documentation (the manual entry) and a short
pocket-guide sort of entry (the documentation string) for each function.
In the long run, the manual will be available on-line, I am sure.  We
also have (in Spice Lisp, anyway) an on-line way of accessing the
argument-list of a function.  What I question is whether there is any
real use for a super-short one-line documentation string.  Having
attempted to write several of these, I find that it is almost impossible
to say something meaningful and not misleading about most functions in one
line or one short sentence.  That is why I would like to flush this idea
and just go with short and long.  I'm not sure that the Emacs experience
is relevant here.

If we do go with both short and super-short descriptions, I agree that
they should be separate strings hidden in separate places.

-- Scott


Date: 30 August 1982 13:43-EDT
From: Kent M. Pitman <KMP at MIT-MC>
Subject:  Access to documentation strings
To: Fahlman at CMU-20C
cc: Common-Lisp at SU-AI

The use of one-line documentation strings is not to provide complete 
documentation, it is to allow APROPOS-style primitives so that the user
can make a good guess about which functions to ask for full documentation on.

    Date: Monday, 30 August 1982  13:24-EDT
    From: Scott E. Fahlman <Fahlman at Cmu-20c>

    We already have a long-form documentation (the manual entry) and a short
    pocket-guide sort of entry (the documentation string) for each function...

I question the importance of this point. I think it's neat that you have so
much documentation of primitive functions, but you should definitely not think
of the primitive system as the only thing that's going to use this sort of 
documentation facility. You can expect other major systems (ZWEI, for example)
or imbedded languages (FRL, BrandX, etc.), all of which will be increasing the
size of the namespace considerably. When a user is searching for a primitive
he knows is there somewhere, the short-description facility is tremendously
useful. 


Date: Monday, 30 August 1982  13:24-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To:   Kent M. Pitman <KMP at MIT-MC>
Cc:   Common-Lisp at SU-AI
Subject: Access to documentation strings


We already have a long-form documentation (the manual entry) and a short
pocket-guide sort of entry (the documentation string) for each function.
In the long run, the manual will be available on-line, I am sure.  We
also have (in Spice Lisp, anyway) an on-line way of accessing the
argument-list of a function.  What I question is whether there is any
real use for a super-short one-line documentation string.  Having
attempted to write several of these, I find that it is almost impossible
to say something meaningful and not misleading about most functions in one
line or one short sentence.  That is why I would like to flush this idea
and just go with short and long.  I'm not sure that the Emacs experience
is relevant here.

If we do go with both short and super-short descriptions, I agree that
they should be separate strings hidden in separate places.

-- Scott


Date: Monday, 30 August 1982  13:17-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To:   Kent M. Pitman <KMP at MIT-MC>
Cc:   COMMON-LISP at SU-AI
Subject: No PRINT-time case conversion switch please!


KMP misunderstands the proposal for a switch to convert output to lower
case.  In the context of a Lisp that converts to upper case by default,
this switch would cause PRINT to do the following:

Figure out how the symbol would print normally, without the swtich being on.

If the symbol would print with |'s leave it alone.

Else, every character that is about to come out in upper case is
converted to lower-case and printed.  Lower-case chars, which would
normally be printed with slashes, are left untouched and the slash is
left in.

This is guaranteed to read in correctly with the upper-case-converting
reader.  If the user reads in such a file with conversion disabled, he
loses.

USER INPUT	OUTPUT (normal)		OUTPUT (with flag true)

FOO		FOO			foo
foo		FOO			foo
Foo		FOO			foo

|foo|		|foo|			|foo|
|X|		X			x
|x|		\x			\x

It is clear that, with or without the proposed switch, any printer has
to make some assumptions about what the reader is going to do.

-- Scott


Date: Monday, 30 August 1982  13:17-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To:   Kent M. Pitman <KMP at MIT-MC>
Cc:   COMMON-LISP at SU-AI
Subject: No PRINT-time case conversion switch please!


KMP misunderstands the proposal for a switch to convert output to lower
case.  In the context of a Lisp that converts to upper case by default,
this switch would cause PRINT to do the following:

Figure out how the symbol would print normally, without the swtich being on.

If the symbol would print with |'s leave it alone.

Else, every character that is about to come out in upper case is
converted to lower-case and printed.  Lower-case chars, which would
normally be printed with slashes, are left untouched and the slash is
left in.

This is guaranteed to read in correctly with the upper-case-converting
reader.  If the user reads in such a file with conversion disabled, he
loses.

USER INPUT	OUTPUT (normal)		OUTPUT (with flag true)

FOO		FOO			foo
foo		FOO			foo
Foo		FOO			foo

|foo|		|foo|			|foo|
|X|		X			x
|x|		\x			\x

It is clear that, with or without the proposed switch, any printer has
to make some assumptions about what the reader is going to do.

-- Scott


Date: Monday, 30 August 1982  13:24-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To:   Kent M. Pitman <KMP at MIT-MC>
Cc:   Common-Lisp at SU-AI
Subject: Access to documentation strings


We already have a long-form documentation (the manual entry) and a short
pocket-guide sort of entry (the documentation string) for each function.
In the long run, the manual will be available on-line, I am sure.  We
also have (in Spice Lisp, anyway) an on-line way of accessing the
argument-list of a function.  What I question is whether there is any
real use for a super-short one-line documentation string.  Having
attempted to write several of these, I find that it is almost impossible
to say something meaningful and not misleading about most functions in one
line or one short sentence.  That is why I would like to flush this idea
and just go with short and long.  I'm not sure that the Emacs experience
is relevant here.

If we do go with both short and super-short descriptions, I agree that
they should be separate strings hidden in separate places.

-- Scott


Date: 30 Aug 1982 0937-PDT
From: Dave Dyer       <DDYER at USC-ISIB>
Subject: Circular structure printing
To: common-lisp at SU-AI


 I believe the Interlisp "HORRIBLEPRINT" package works as you
describe.  Interlisp's solution to the "problem" of having to do
two passes is that it only uses horribleprint where the user
has declared it necessary.  The code is common to all Interlisp
implementations, and is public domain as far as I know.
-------


Date: 30-Aug-82  9:11:24 PDT (Monday)
From: Masinter at PARC-MAXC
Subject: Re: Circular structure printing
In-reply-to: dlw at SCRC-TENEX's message of Sunday, 29 August 1982, 11:33-EDT
To: Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC>
cc: common-lisp at su-ai

The HPRINT package in Interlisp prints circular structures in the desired fashion. The algorithm assumes that output is going to a random-acess device (e.g., disk file); if the output file is not RANDACCESSP, then output is first sent to a scratch file and when printing is complete, it is sent to the final destination. HPRINT keeps a hash-table of objects-printed->byte position so that on second reference it can go back and put in the forward reference before the first reference.

I believe you already have the source, but in any case, it can be found in [parc-maxc]<lisp>hprint.

Larry


Date: 30 Aug 1982 0914-PDT
From: Rod Brooks <ROD at SU-AI>
Subject: LOOP and white pages.   
To:   common-lisp at SU-AI  


(reply to "BROOKS@MIT-OZ"@MIT-MC)

Just so Scott doesn't get the feeling that he is the only one who doesn't want
LOOP in the white pages, here are some reasons that I am against it.

I haven't looked at the complete new proposal, but in MOON's MACRO example:

(DEFUN MACROEXPAND (FORM &AUX CHANGED)
  "Keep expanding the form until it is not a macro-invocation"
  (LOOP (MULTIPLE-VALUE (FORM CHANGED) (MACROEXPAND-1 FORM))
	(IF (NOT CHANGED) (RETURN FORM))))

one sees a fundamentally new scoping system in action. In all other binding
mechanisms (e.g. LET, DO, MULTIPLE-VALUE-BIND, DEFUN and even PROG with init values)
the CAR of a form identifies the form type as one which will do binding which
will remain in effect only within that form, and at the same time says where
in the form one can find the variables and what they will be bound to.
In this example MULTIPLE-VALUE says where the variable names and the things
that they will be bound to are (syntactically), but the scope of those
bindings is determined by a context outside of the form with MULTIPLE-VALUE
as its CAR. On the other hand while the symbol LOOP determines the scope of
the bindings (in the example at least) it doesn't determine the syntactic location
of the variables and what they get bound to.

While JLK is right that it is possible to write horrible code with DO, I don't
agree that we have to jump in *now* with another mechanism, especially when that
mechanism introduces radically new (and I believe bad) scoping rules. Lets leave
LOOP in the yellow pages for now.


Date: 30 Aug 1982 0904-PDT
From: Dave Dyer       <DDYER at USC-ISIB>
Subject: note on portability
To: common-lisp at SU-AI


 More than simple assertions of portability is necessary to make common
lisp common.  To paraphrase Larry Masinter, I don't believe in portability
in the absence of instances of porting.  As this applies to common lisp,
I don't believe common lisp code will really be portable unless substantial
amounts of code are actually shared among the implementations.  Such
shared code will allow minor quirks in the primitives to be discovered and
removed, and also assure that hairy higher level features are not subtly
different from one implementation to the next.

 The LOOPS implementation is an ideal candidate to be developed
and ported.  Symbolics will surely build and document it - and the
rest of the implementors can ignore it until the code drops from the sky.
-------


Date: 30-Aug-82  9:05:16 PDT (Monday)
From: Masinter at PARC-MAXC
Subject: case-sensitivity: a modest proposal
To: common-lisp at SU-AI

I propose the following solution to the current case dilemma:

a) Common Lisp is case sensitive: Foo is not eq to foo.

b) All symbols in packages admitted into the Common Lisp white- and yellow-
  pages are REQUIRED to be lower case. 

This has the following advantages:
a) everybody types and sees lower case
   (I guess this is an advantage, since most type-faces look better
    with all lower-case rather than all caps)
b) no confusion about what you have to remember if you are using
   shared packages: all of the symbols are lower case.

c) symbols used for documentation, parsing, file names in host operating
   system, etc. can be mixed case/upper case, etc.

d) users who like MixedCaseSymbolsToSeparateWordsInSymbols can do so
   and still have their print out the same way they were read in.


Date: 30-Aug-82  7:22:47 PDT (Monday)
From: Masinter at PARC-MAXC
Subject: Object type names
To: Common-Lisp at SU-AI

The Interlisp file package deals with objects via object type names FNS, VARS, MACROS, RECORDS, ... (I think there are about 15 built-in types.)

All of the functions in the file package which deal with object types (e.g.,
GETDEF, COMPAREDEFS, MOVEDEF, EDITDEF, etc.) will coerce non-standard synonyms,
e.g. FUNCTION, FUNCTIONS, VARIABLE, ...

The mechanism for doing the coersion, allowing users to add new synonyms, object
types, etc. is not very complex. 

I think it is much more user sensible to talk about FUNCTIONS than  DEFUN-objects
(or DEFINEQs, for that matter.) It did turn out to be more convenient to have FNS
and VARS rather than FUNCTIONS and VARIABLES, the brevity for common types as
important as the historical reasons.


Date: Monday, 30 August 1982, 02:59-EDT
From: David A. Moon <Moon at SCRC-TENEX at MIT-MC>
To: Kent M. Pitman <KMP at MIT-MC>
Cc: Common-Lisp at SU-AI
In-reply-to: The message of 30 Aug 82 00:37-EDT from Kent M. Pitman <KMP at MIT-MC>

    Date: 30 August 1982 00:37-EDT
    From: Kent M. Pitman <KMP at MIT-MC>

    I think it's worthwhile to provide two fields of the documentation for the
    following reasons: 

    * Abstraction. A documentation string should be just what it sounds like: a
      string which is not intrinsically interesting to the machine -- just
      something which can be typed at an intelligent entity (eg, a human) to
      provide insight into something.

      It should, as such, have no structure which is not explicit in its
      representation. If there's something magic about the first line and the
      remaining lines, that distinction should be apparent in the
      representation.

There is some sense to this.  We could make it be allowed to be either a
string or a list of two strings, if we don't feel that a carriage return is
enough structure.

    * Simplicity. It's a useful case which documentation code might want to do 
      frequently. The user should not be bothered with string-hacking if all he 
      wants to do is get documentation. Might as well make the common case easy.
This is absurd.

    * Efficiency. Not so much a concern on a large address space machine, but
      still worth considering: Consing should not be required to access a
      documentation string. Experience with Emacs has shown that in certain
      space-critical situations, it's a win to be able to access documentation
      when the rest of the world has ceased to run because of lack of free
      space so you can find the function you need in order to correct the
      problem.
This is more absurd.


    -----
	... The pre-defined object types are DEFUN for a function, special form, or
	macro; DEFVAR for a global variable, parameter, or constant; DEFSTRUCT
	for a structure....
    -----
    I would rather see the object types relate to the intended use of the
    definition rather than the form used to create the use. eg, MACRO and DEFMACRO
    both create the same type of object; indeed, if you do one and then the
    other the documentation should overwrite one another just as a (MACRO ...)
    and (DEFMACRO ...) form would overwrite each other in LispM lisp. Similarly
    for variables: I would feel uncomfortable about giving something a DEFVAR
    type documentation if I had not DEFVAR'd it. Suppose I had DEFCONST'd it or
    just SETQ'd it. Isn't that good enough? I'd rather see the names be something
    like :VARIABLE, :MACRO, :FUNCTION, :STRUCTURE, :SPECIAL-FORM, etc.
    rather than the name of the typical form that would create the documentation 
    type as currently proposed.

You didn't read my message carefully enough.  All functions are of type
DEFUN, it doesn't matter what macro you defined them with.  Common Lisp
allows the same name in the space of functions to be both a special form
and a macro; but surely if they didn't have the same documentation there
would be hell to pay!

The types can't be keywords because that interferes with user
extensibility, since all keywords are in the same package.  In the Lisp
machine we chose the name of the most prominent defining form for no
really strong reason, just because it seems senseless to make up a whole
new set of names for this when there are already reasonably mnemonic
names in existence.  Otherwise, especially when you have users defining
their own types, you find you are using the same names as the defining
forms but with the DEF prefix taken off, and you have the problem of
trying to guess whether DEFUN maps into FUN or FUNCTION or UN.


Date: 30 August 1982 02:33-EDT
From: Kent M. Pitman <KMP at MIT-MC>
Subject: No PRINT-time case conversion switch please!
To: EAK at MIT-MC, COMMON-LISP at SU-AI, Fahlman at CMU-20C

A switch that decides the case to use at PRINT time can never do the
right thing. it will work ok for expressions like:

USER INPUT	SYSTEM (normal)		SYSTEM (with funny flag)

  X			X			x
  x			X			x

but consider:

 |x|			|x|			x
 |X|			X			x

These can potentially be wrong. Presumably the `normal' column above
is to print out for re-read by a Maclisp style (uppercasing) reader so that

 User inputs |x|
 System outputs |x|
 System later re-reads |x| ;win

 User inputs |X|
 System outputs X
 System later re-reads |X| ;win

Where if you do translation to lowercase at print-time and later think your
output is re-readable acceptably by some implementation that downcases instead
of upcases, you'll find that

 User inputs |x| into uppercasing system
 System outputs |x|
 Lowercasing system later re-reads x ;win

 User inputs |X| into uppercasing system
 System outputs X
 Lowercasing system later re-reads x ;lose!

This is disappointing because the |...| clearly denote the user's intent that
the system not muck with the case of his input. This case actually comes up in
practice. Consider Maclisp programs like:

(defun get-input ()
  (terpri)
  (princ '|INPUT: |)
  (read))

(defun yes? ()
  (memq (readch) '(/y /Y)))

Say what you'd like to about the reasonableness of printing out symbols
instead of strings, or about using readch instead of in-char or whatever.
Those are clearly substandard coding styles, but people sometimes write
substandard code and I think it's very important that we guarantee that 
Lisp READ/PRINT for simple cases like these preserve a certain amount of
semantic content especially when the user has gone to the trouble to type
his symbols with /'s or |...|'s and I don't see any way a PRINT-time decision
can do anything but risk screwing the user.

Anyone who likes to see code in a certain case can write an editor package
(or borrow mine) which upcases or downcases code respecting things vbars,
doublequotes, semicolons, slashes, etc. But I don't think common lisp should
be cluttered with any dwimish notions of automatic case conversion that work
only most of the time ...


Date: 30 August 1982 00:45-EDT
From: Kent M. Pitman <KMP at MIT-MC>
Subject:  Access to documentation strings
To: Fahlman at CMU-20C
cc: Common-Lisp at SU-AI

    Date: Thursday, 26 August 1982  21:17-EDT
    From: Scott E. Fahlman <Fahlman at Cmu-20c>

    ... If we want anything of this sort, the convention should be that the 
    first SENTENCE (normal English syntax) is an overview.  My preference
    would be to forget this whole overview business -- I don't see much use 
    for it.
-----
Experience with Teco/Emacs shows that these two types of documentation are
tremendously useful to users. I have to say, though, that I've been bothered
on innumerable occasions by the restriction of its being a one-liner. 
Exceptions always come up. The same would happen with a one-sentence 
restriction only worse because finding the end of a sentence is a natural
language task in some cases. I really think having a mechanism that its 
structure is necessary to make the thing useful.


Date: 30 August 1982 00:37-EDT
From: Kent M. Pitman <KMP at MIT-MC>
To: Moon at SCRC-TENEX
cc: Common-Lisp at SU-AI

    Date: Thursday, 26 August 1982, 03:25-EDT
    From: David A. Moon <Moon at SCRC-TENEX>
    To:   Common-Lisp at SU-AI
    Re:   Access to documentation strings

    ... I don't think we need a separate function to get the brief
    documentation, it's just (SUBSEQ doc 0 (POSITION #\Return doc)).... 
-----
This same sort of argument is what brought us cute little idioms like
(APPEND X NIL), (SUBST NIL NIL X), (PROG2 NIL X ...), etc.

I think it's worthwhile to provide two fields of the documentation for the
following reasons: 

* Abstraction. A documentation string should be just what it sounds like: a
  string which is not intrinsically interesting to the machine -- just
  something which can be typed at an intelligent entity (eg, a human) to
  provide insight into something.

  It should, as such, have no structure which is not explicit in its
  representation. If there's something magic about the first line and the
  remaining lines, that distinction should be apparent in the
  representation.

* Simplicity. It's a useful case which documentation code might want to do 
  frequently. The user should not be bothered with string-hacking if all he 
  wants to do is get documentation. Might as well make the common case easy.

* Efficiency. Not so much a concern on a large address space machine, but
  still worth considering: Consing should not be required to access a
  documentation string. Experience with Emacs has shown that in certain
  space-critical situations, it's a win to be able to access documentation
  when the rest of the world has ceased to run because of lack of free
  space so you can find the function you need in order to correct the
  problem.
-----
    ... The pre-defined object types are DEFUN for a function, special form, or
    macro; DEFVAR for a global variable, parameter, or constant; DEFSTRUCT
    for a structure....
-----
I would rather see the object types relate to the intended use of the
definition rather than the form used to create the use. eg, MACRO and DEFMACRO
both create the same type of object; indeed, if you do one and then the
other the documentation should overwrite one another just as a (MACRO ...)
and (DEFMACRO ...) form would overwrite each other in LispM lisp. Similarly
for variables: I would feel uncomfortable about giving something a DEFVAR
type documentation if I had not DEFVAR'd it. Suppose I had DEFCONST'd it or
just SETQ'd it. Isn't that good enough? I'd rather see the names be something
like :VARIABLE, :MACRO, :FUNCTION, :STRUCTURE, :SPECIAL-FORM, etc.
rather than the name of the typical form that would create the documentation 
type as currently proposed.
-kmp


Date: Sunday, 29 August 1982  23:56-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To:   Common-Lisp at SU-AI
Subject: macro expansion


At the meeting it was decided that Moon and I would each try to come up
with an improved macro expansion paradigm.  I like what Moon proposes,
so I will not be producing a proposal of my own on this.  The new
proposal is clearly better than the system in the white pages now (which
I originally proposed as a minor improvement over the current Maclisp
system).

The only quibble I have is whether we want to spell *MACROEXPAND-HOOK*
with the stars.  We should only do this if we decide to spell all (or
almost all) built-in global hooks this way.  I am neutral on this issue.

-- Scott


Date: Sunday, 29 August 1982  23:33-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To:   Kim.fateman at UCB-C70
Cc:   common-lisp at SU-AI


I don't think we want to restrict the yellow pages quite as much as
Fateman suggests.  In particular, we will want to include packages that
depend on other yellow pages packages and not just on the Common Lisp
kernel.  The only criteria should be (1) that everything that you need
in order to run a yellow-pages package should be available in Common
Lisp itself or somewhere in the yellow pages and (2) that all
inter-package dependencies are very clearly documented.  Maybe we need a
few more colors of pages to separate universally portable stuff, stuff
that depends on other packages, stuff that depends on
implementation-specific hacks, etc., but this color business is getting
out of hand.  The important thing is to make it clear exactly what the
game is for any given package and to try to keep things as coherently
organized as possible.

I agree with Fateman that things should not be described in the yellow
pages document unless the source code is available and can be freely
distributed with the yellow pages library.  We don't want to this
document to be an advertising service for proprietary packages, though
such advertising might form a useful document in its own right.

At present, a few of the planned yellow-pages packages are being written
or exist in earlier incarnations, but there is not as yet anything worth
calling a library.  Obviously, the yellow pages cannot exist until the
white pages have been stable for awhile and some correct Common Lisp
implementations are running.  We will want to be very careful with the
documentation of the first yellow pages release so as to get all of this
off on the right foot.

-- Scott


Date: Sunday, 29 August 1982, 21:26-EDT
From: David A. Moon <Moon at SCRC-TENEX at MIT-MC>
Subject: macro expansion
To: Common-Lisp at SU-AI

Here is my promised proposal, with some help from Alan.

MACRO-P becomes a predicate rather than a pseudo-predicate.
Everything on pages 92-93 (29July82) is flushed.

Everything, including the compiler, expands macros by calling MACROEXPAND
or MACROEXPAND-1.  A variable, *MACROEXPAND-HOOK*, is provided to allow
implementation of displacing, memoization, etc.

The easiest way to show the details of the proposal is as code.  I'll try to
make it exemplary.

(DEFVAR *MACROEXPAND-HOOK* 'FUNCALL)

(DEFUN MACROEXPAND (FORM &AUX CHANGED)
  "Keep expanding the form until it is not a macro-invocation"
  (LOOP (MULTIPLE-VALUE (FORM CHANGED) (MACROEXPAND-1 FORM))
	(IF (NOT CHANGED) (RETURN FORM))))

(DEFUN MACROEXPAND-1 (FORM)
  "If the form is a macro-invocation, return the expanded form and T.
  This is the only function that is allowed to call macro expander functions.
  *MACROEXPAND-HOOK* is used to allow memoization."
  (DECLARE (VALUES FORM CHANGED-FLAG))

  (COND ((AND (PAIRP FORM) (SYMBOLP (CAR FORM)) (MACRO-P (CAR FORM)))
	 (LET ((EXPANDER (---get expander function--- (CAR FORM))))
	   ---check for wrong number of arguments---
	   (VALUES (FUNCALL *MACROEXPAND-HOOK* EXPANDER FORM) T)))
	(T FORM)))

;You can set *MACROEXPAND-HOOK* to this to get traditional displacing
(DEFUN DISPLACING-MACROEXPAND-HOOK (EXPANDER FORM)
  (LET ((NEW-FORM (FUNCALL EXPANDER FORM)))
    (IF (ATOM NEW-FORM)
	(SETQ NEW-FORM `(PROGN ,NEW-FORM)))
    (RPLACA FORM (CAR NEW-FORM))
    (RPLACD FORM (CDR NEW-FORM))
    FORM))

The above definition of MACROEXPAND-1 is oversimplified, since it can
also expand other things, including lambda-macros (the subject of a separate
proposal that has not been sent yet) and possibly implementation-dependent
things (substs in the Lisp machine, for example).

The important point here is the division of labor.  MACROEXPAND-1 takes care
of checking the length of the macro-invocation to make sure it has the right
number of arguments [actually, the implementation is free to choose how much
of this is done by MACROEXPAND-1 and how much is done by code inserted into
the expander function by DEFMACRO].  The hook takes care of memoization.  The
macro expander function is only concerned with translating one form into
another, not with bookkeeping.  It is reasonable for certain kinds of
program-manipulation programs to bind the hook variable.

I introduced a second value from MACROEXPAND-1 instead of making MACROEXPAND
use the traditional EQ test.  Otherwise a subtle change would have been
required to DISPLACING-MACROEXPAND-HOOK, and some writers of hooks might get
it wrong occasionally, and their code would still work 90% of the time.


Other issues:

On page 93 it says that MACROEXPAND ignores local macros established by
MACROLET.  This is clearly incorrect; MACROEXPAND has to get called with an
appropriate lexical context available to it in the same way that EVAL does.
They are both parts of the interpreter.  I don't have anything to propose
about this now; I just want to point out that there is an issue.  I don't
think we need to deal with the issue immediately.

A related issue that must be brought up is whether the Common Lisp subset
should include primitives for accessing and storing macro-expansion
functions.  Currently there is only a special form (MACRO) to set a
macro-expander, and no corresponding function.  The Lisp machine expedient of
using the normal function-definition primitive (FDEFINE) with an argument of
(MACRO . expander) doesn't work in Common Lisp.  Currently there is a gross
way to get the macro expander function, but no reasonable way.  I don't have
a clear feeling whether there are programs that would otherwise be portable
except that they need these operations.


Date: 29 Aug 1982 18:17:22-PDT
From: Kim.fateman at Berkeley
To: common-lisp@su-ai

Subject: loop, case, consensus

It might be appropriate to mention the way that Franz now accomodates
various loop packages (simultaneously): there are compile-time packages
that allow (at least) 3 different, and sometimes conflicting loop packages
(from maclisp, UCI lisp, interlisp) to be used in the same run-time
environment. This has enabled us to provide "portability"
in a useful fashion.
Using different packages simultaneously, interpreted, is not supported.

I hope that common lisp supports portability at least as well.
.......
My vote on case-sensitivity is with jkf, for reasons that I have previously
expressed.  For the record, I used case-insensitive Lisps exclusively
from 1967 to 1978.  People who use MultiPLe CaSes Expecting THem to be
Mapped to a SinGle CASe should be asked to map them to a single case
(I prefer lower) before providing them as portable packages.
I also think that Roman, Italics, Greek, Boldface, etc if available
should also be distinct from each other. 
Mathematicians have found this useful even before the TTY33.

.......
I am concerned about consensus on availability of packages.

1. It seems to me that any "package" which is not made 
freely available in at least one correct and complete implementation
in a form based only on the CL kernel (the white pages?) should not
be described in the extended manual (the yellow ?).

2. Stuff which runs under only on one current
environment because of OS hooks not in CL should be allowed in
the yellow pages only if the code to make it run is freely available
(in case someone else has a similar OS).

Do we have code for all the yellow pages now?

Do people agree with view 1?  Perhaps my own experience with software
licensing has made me suspicious on some aspects of software sharing.


Date: Sunday, 29 August 1982  18:02-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To:   MOON at SCRC-TENEX at MIT-AI
Cc:   Common-Lisp at SU-AI
Subject: function specs


Dave,

I do find FOO-INTERNAL-G0067 to be ridiculous.  My problem is that I
find (:INTERNAL 67 FOO) or whatever to be equally ridiculous, and
perhaps worse since it requires a whole new family of functions to
access these pseudo-names.

There is no problem in manipulating functions, since they are perfectly
good Lisp objects that can be passed around at will.  The problem with
TRACE and friends is that they cannot do their magic directly to a
function object (well, they could, but it would take an invisible pointer).
Instead, they need to interpose something between a function and
everyone who wants to get at it, and that requires knowing where other
code expects a function to be found.  To me, that still doesn't mean
that the place where a function conventionally lives is in any sense its
"name", except where that place happens to be the definition cell of a
symbol.

One possible approach is to recognize that TRACE does not hack a function,
but rather a place where a function normally lives.  If we give TRACE a
symbol, it just hacks the definition cell.  Otherwise, the argument to
TRACE is a SETF-like expression that points to a place: property list,
entry in an array, or whatever.  That place must contain a function
object, and the encapsulated form is left there in place of the
original.  So (TRACE place) => (SETF place (TRACE-ENCAPSULATE place)).
To me, this seems much more natural than creating this new series of
"names" and a new family of function name hacking forms.

Similarly, if the "name" argument to DEFUN is not a symbol, it would
also be a SETF location:

(defun (get 'foo 'testing-function) ...)

In this case, the definition is an anonymous LAMBDA or the compiled form
thereof, and the DEFUN does the obvious SETF.  If the compiled
function-object wants to remember that it was being sent to some
particular location at the time of its DEFUN, so much the better; that
is useful info for the debugger, but it is not a name.

Maybe all we disagree about is whether to call the location expression a
name and whether to make up a whole new syntax for it, rather than using
the SETF syntax.

-- Scott


Date: 29 August 1982 15:18-EDT
From: Earl A. Killian <EAK at MIT-MC>
Subject:  SET
To: RMS at MIT-OZ
cc: common-lisp at SU-AI

Alright, reusing the name SET may be a bad idea for backward
compatibility, so the question becomes whether new functions
should have "F" appended to their names.  I say no.  There is
already the precedent of PUSH/POP which would have to be renamed
to be consistent.  It is easier (and more aesthetic I think) to
instead remove the "F" from the new functions, such as EXCHF,
SWAPF, GETF, INCF, etc.


Date: Sunday, 29 August 1982, 15:00-EDT
From: Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC>
Subject: Circular structure printing
To: Fahlman at Cmu-20c
Cc: common-lisp at SU-AI
In-reply-to: The message of 29 Aug 82 11:54-EDT from Scott E. Fahlman <Fahlman at Cmu-20c>

I realize that it's optional.  I guess it doesn't really matter if it is
extremely inefficient.  I'd still feel better if I could see an
implementation and try it out.


Date: Sunday, 29 August 1982  14:41-EDT
From: MOON at SCRC-TENEX
To: David.Dill at CMU-10A (L170DD60)
Cc: common-lisp at SU-AI
Subject: keyword args to load

    Date: 29 August 1982 1256-EDT (Sunday)
    From: David.Dill at CMU-10A (L170DD60)

    The :package and :verbose keywords make assumptions about the package
    system, which is inappropriate given that we haven't standardized on
    a package system.

The :verbose keyword doesn't.  The :package keyword does, so it might be
left out for now or marked as "will exist when packages do" as the colon
character is.


Date: 29 August 1982 1256-EDT (Sunday)
From: David.Dill at CMU-10A (L170DD60)
To: common-lisp at SU-AI
Subject:  keyword args to load
Message-Id: <29Aug82 125648 DD60@CMU-10A>

The :package and :verbose keywords make assumptions about the package
system, which is inappropriate given that we haven't standardized on
a package system.

	-Dave


Date: Sunday, 29 August 1982  13:07-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To:   common-lisp at SU-AI
Subject: case-sensitivity and portability


Since JKF is aksing people to form an opinion on his "compromise" plan
and vote on it, I would like to put the following arguments on the
record.  (Originally, I sent these to him alone.)  They explain why I
don't view his plan as a minor compromise, and why I oppose it.

-- Scott

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

John,

Yes, I understand what you are proposing.  My objection is approximately
(but not quite) your case 2: I am afraid that if we make it both easy
and legal for portable Common Lisp code to be case-sensitive, then a few
people will start writing case-sensitive packages.

It is not that I object to having to type in an occasional backslash or
capital letter, but rather that I object (strenuously) to having to
remember the case of every symbol around.  As long as case-insensitivity
is the universal rule at the interfaces to all packages, then I can go
on living by the simple rule that case is just ignored, and I can type
things in however I like.  But if I load 100 packages and 3 of them have
case-sensitive symbols in them, then I am perforce living in a
case-sensitive Lisp and I have to remember which symbols have to have
slashified upper-case in them and where.  This is what I object to.
Like pregnancy, you can't be a little bit case-sensitive -- either you
are or you aren't.

You say that I shouldn't impose my biases onto the people who like
case-sensitivity.  Well, under the scheme you propose, they are imposing
their biases on me.  Someone has to be imposed upon here, and better you
than me.

You say that I should be grateful for any case-sensitive code that is
written in Common Lisp and therefore should put up with the hassle.  I
guess this comes down to our differing estimates of how attached people
are to case-sensitivity.  If Common Lisp is officially case-insensitive,
would the case-sensitive people refuse to use it?  I don't think so.  It
has been my experience that people who hate case-sensitivity hate it
passionately, and that the people who like it think it's sort of cute
but not a life-or-death matter.  (This issue is distinct from the issue
of whether users ever have to type or see upper-case -- lots of people
ARE passionate about that.)  So I think that if case-insensitivity is
made the law, people will easily adapt and we will avoid creating two
sub-cultures with a case-sensitive interface between them.  Then I can
be grateful for the same code and not have to curse it for bringing case
into an otherwise beautiful universe.  Of course, all of this is only
based on my discussions with CMU Unix types; the Berkeley species may be
more rabid about all this.

I should emphasize that there is a reason for the asymmetry noted above
-- if it were just that the case-insensitive crowd was being arbitrary
and unreasonable, we would not want to reward that.  If you are used to
case-insensitive systems, as most non-Unix people are, then when you go
to a case-sensitive system you make errors with almost everything you
type.  That's one reason why it is so hard to use Unix only occasionally
-- either you use Unix a lot or the case-sensitivity drives you nuts.
But if you are used to case-sensitive systems and move to one that
ignores case, there's no problem referring to things.  The only problem
is that when you want to do some cute naming hack like the one you
mentioned in your mail, you have to think of some way other than case to
distinguish between "Car" and "car".  As they say, that seems like a small
price to pay for portability.

So that's why I'm opposed to letting each file select whether case
sensitivity is on or off and why I want to impose my own biases on
everyone when it comes to the standard for portable Common Lisp code.

-- Scott


Date: Sunday, 29 August 1982  12:57-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To:   common-lisp at SU-AI
Subject: cases. reader poll


Since JKF asks about our voting procedures, and since there seem to be
some new folks on the list, we should review the decision procedures
under which we have been working.

Basically, the decisions have been made by attempting to find consensus
among those working on actual Common Lisp implementations.  Such people
obviously have a sort of veto power -- if some feature is truly
unacceptable to them, they have the ability to walk out and take their
implementation with them.  We have also actively sought advice and
suggestions from selected people whom we believe to have good ideas or
who represent important constituencies whose concerns we want to be
aware of, including the Franz/Unix folks.

On trivial issues, for example whether a function should be named
CONCATENATE or CATENATE, we have voted, since it is clear that nobody is
going to walk out over such a thing; on more important issues, we have
so far been able to reach consensus among the implementors, though we
have each had to compromise on a few things for the sake of the overall
effort.  It these more important debates, it definitley has not been the
case that majority rules.  In the end, it comes down to what Guy decises
to put into the manual and who walks out as a result of that decision;
so far, this power has only been used once, to resolve the impasse over
the symbolness of NIL, and nobody walked out.  That's an amazingly good
record, I think.

This is all sort of like the U.N. -- the General Assembly debates, but
the Security Council is the only body that can send in the troops, and a
few major members have veto power.  This may seem undemocratic, but it
is the most democratic thing I know of that is still likely to produce a
Common Lisp.

So a vote is not the way to decide this, but some additional input from
the unix people would be welcome.  In particular, I would be
interested in whether JKF really is properly characterizing the unix
community, a group that we do want to keep aboard.  It is my suspicion
that, while unix people do not want to type anything in upper case or
see upper case output (we already can handle that), only a few of them
would find Common Lisp unacceptable because "Foo" and "foo" map into the
same symbol.  Some unix people -- not all of them, I bet -- might prefer
case-sensitivity, but that is different from the issue of whether Common
Lisp is "usable by people who favor case-sensitive systems".  That
strikes me a clear over-statement of the case, though I could be wrong
about this.

-- Scott


Date: Sunday, 29 August 1982  11:54-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To:   Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC>
Cc:   common-lisp at SU-AI
Subject: Circular structure printing


The inefficiency that you point to is precisely the reason we hung
circular printing under the PRINCIRCLE switch.  If you turn that on,
printing becomes an expensive process, but if you need it, it's worth
the price.

Actually, the right move when this switch is on is probably to just go
ahead and print the stuff normally, looking for circularities as you go,
but into a string rather than out to the screen.  If you make it
through, just dump the string; if you hit a circularity, go back and do
it over.  Then, when the switch is on, it only costs you maybe a factor
of two unless you do in fact hit a circularity.

-- Scott


Date: Sunday, 29 August 1982, 11:33-EDT
From: Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC>
Subject: Circular structure printing
To: common-lisp at su-ai

I have become a bit concerned about the Common Lisp feature that
says that the printer should be able to deal with circular list
structure in the manner specified.  One thing that is particularly
worrisome is that the first occurence of a shared cons cell has
to be prefixed with a marker, which means that you have to do
complete lookahead at the entire Lisp object you are printing before
you can output the first character.  Is this really intentional?
Does anybody have a printer that does this?  May I examine the
code, please?  Are the requirements in runtime and storage
really acceptable?  It's quite possible that there's nothing
to worry about and somebody has a great solution, but I'd like
to see it.  Thanks.


Date: 28-Aug-82 14:44:21-PDT (Sat)
From: ucbvax:<Kim:jkf> (John Foderaro)
Subject: cases. reader poll
Message-Id: <60852.23129.Kim@Berkeley>
Received: from UCBKIM by UCB-UCBVAX (3.177 [8/27/82]) id a00594; 28-Aug-82 16:08:10-PDT (Sat)
Via: ucbkim.EtherNet (V3.147 [7/22/82]); 28-Aug-82 16:08:18-PDT (Sat)
To: common-lisp@su-ai

Re:
    From: MOON at SCRC-TENEX
    I don't think we can satisfy everybody on this one.  Let's leave things
    the way they are unless someone comes up with a concrete, fully
    specified, practical proposal for a set of modes that collectively
    satisfy everyone and are not incompatible.


 Clearly the ball is in your court. Because you favor the status quo you can
 sit and wait forever for the proposal that 'satisfies everyone'.  You know
 as well as I that it will never come.  What I am proposing is a compromise,
 that is something which will require everyone to make a bit of a sacrifice
 so that no one group has to make a huge sacrifice.  I thought that this was
 the 'spirit' of common lisp, if I am wrong please let me know.  I look upon
 Lisp as a tool.  The one small change I've proposed will make it useable by
 a much larger communiity without affecting the current community very much.
   In case you've forgotten, this is what I propose:
   	1) the reader's case-sensitivity is alterable via a switch
	2) when it case-insensitive mode, upper case characters are
	   converted to lower case.
 While this may not be a 'fully specified, concrete proposal', it is the
 minimum required for common lisp to be usable to a case-sensitive user.
 Unless this is agreed upon, I see no reason to go into any greater detail.

 Does the common lisp committee have a formal way of polling its members
 about an issue? (I can't believe that decisions are made based on who flames
 the most on this mailing list).  If so I would like to find out the answer
 to these questions:
 1) Do you think that common lisp should be useable by the people who favor
    case-sensitive systems?

 2) Do you think that converting all characters to lower case is too great a
    sacrifice to be expected of case-insensitive users just to satisify
    case-sensitive users?

Just in case there is no formal way to poll the members, please send your
answers to me.  Be sure to indicate whether you consider yourself to be on
the official committee or whether you are just on this mailing list for fun.
If I get an overwhelming NO vote I will never bring up this subject again on
this mailing list.






Date: Saturday, 28 August 1982  23:48-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To:   common-lisp at SU-AI
Subject: Closures


I've played a little more with the lexical-closure stuff, and am now
pretty confident that they can do everything I might ever want closures
for.  So unless someone comes up with an example of something useful
that cannot be done with the lexical varaible mechanism, I would vote to
flush dynamic closures from the white pages.  As Moon points out, Lispm
and friends are free to retain this feature if they like.

-- Scott


Date: 28 August 1982  21:21-EDT (Saturday)
From: FEINBERG at CMU-20C
To:   Scott E. Fahlman <Fahlman at CMU-20C>
Cc:   BUG-LOOP at MIT-ML, Common-Lisp at SU-AI
Subject: 2nd generation LOOP macro

	I suspect many people have not seen the complete proposal for
the Common Lisp loop macro yet, and therefore it is premature to
include it in the White Pages until everyone has a chance to examine
the proposal in depth.  I too wonder whether adding additional
syntax to Common Lisp is a good idea for Common Lisp, but would like
to at least see what is being proposed.  


Date: Saturday, 28 August 1982, 16:09-EDT
From: David A. Moon <Moon at SCRC-TENEX at MIT-MC>
Subject: COMPILE-FILE
To: Common-Lisp at SU-AI

COMPILE-FILE (known as COMFILE until last week) needs some of the same keywords
as LOAD, specifically :PACKAGE, :VERBOSE, :PRINT, and :SET-DEFAULT-PATHNAME.
I suggest that the optional argument be changed to an :OUTPUT-FILE keyword as well.
There are likely to be additional implementation-dependent keywords such as :OPTIMIZE.

COMPILE-FILE input-file &KEY :OUTPUT-FILE :PACKAGE :PRINT :SET-DEFAULT-PATHNAME :VERBOSE


Date: Saturday, 28 August 1982  11:50-EDT
From: MOON at SCRC-TENEX
Subject: Order of arguments to ARRAY-DIMENSION
to: common-lisp at SU-AI

I agree with Stallman.


Date: Saturday, 28 August 1982  13:30-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To:   Common-Lisp at SU-AI
Subject: Yellow pages


Well, as I have always envisioned it, many yellow pages things (LOOP,
Flavors, CGOL, bigfloats with precision hacking) will be portable Common
Lisp packages that will work in any Common Lisp.  Others (a "universal"
menu system, for example) will provide a common Lispy interface, but
will exist in different versions for different implementations: one
might do menus (as well as is possible) on a 24x80 ASCII screen, another
might do menus on a 3600 with mouse selection, another might use audio
I/O, etc.  Finally, the yellow pages would contain some stuff that is
only for one implementation: a communication package for VAX Unix, for
example.  The documentation would clearly incidate which sort of thing
each package is, and things would be organized so that the universal
packages (that we want people to play with) are not hidden among the
system-dependent hacks.

In this way, I think we retain many of the best features of the
traditional route by which things find their way into Lisp, without as
much chaos as we see currently.  First, someone writes a package for his
own use, then shares it privately with some friends, then cleans it up
and documents it and submits it to the yellow pages, and then, if it
catches on with almost everyone, it goes into the language proper.  The
only novel item here is that we exert some quality control at the point
of entry to the yellow pages.

The yellow pages librarian cannot reject a package because he doesn't
like what it does, but only on the grounds that it is not adequately
documented or that the code is buggy or unmaintainable.  The code in the
yellow pages library must either be public domain or there must be
explicit permission to distribute it together with the rest of the
library.  I would guess that Symbolics, DEC, 3RCC, and others would
also have their own proprietary libraries, modelled after the yellow
pages, of things that they want only thier own customers to have;
hopefully this won't get out of hand and all vendors will realize the
benefits of commonality within the common Lisp community for
utility-like things.

-- Scott


Date: Saturday, 28 August 1982  11:50-EDT
From: MOON at SCRC-TENEX
Subject: Order of arguments to ARRAY-DIMENSION
to: common-lisp at SU-AI

I agree with Stallman.


Date: Saturday, 28 August 1982  11:50-EDT
From: MOON at SCRC-TENEX
Subject: Order of arguments to ARRAY-DIMENSION
to: common-lisp at SU-AI

I agree with Stallman.


Date: Saturday, 28 August 1982  11:44-EDT
From: MOON at SCRC-TENEX
To: Scott E. Fahlman <Fahlman at Cmu-20c>
Cc: BUG-LOOP at MIT-ML, Common-Lisp at SU-AI
Subject: Yellow pages

I guess I misunderstood the philosophy then.  If the "yellow pages"
things work in every implementation, just like the "white pages" things,
then I'm happy with LOOP being in the yellow pages.  I don't mind LOOP
not being in the part that we say we will never (well, hardly ever)
change, as long as writers of portable code are not discouraged from
learning about it and using it.


Date: Friday, 27 August 1982  21:11-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To:   BUG-LOOP at MIT-ML, Common-Lisp at SU-AI
Subject: 2nd generation LOOP macro


    One reason (for putting LOOP in the white pages) is that it is
    unlikely that any portable code I write will do its iteration
    with PROG or DO. -- Moon

Well, it is OK to write a portable package that explicitly requires
something from the yellow pages, so we could still use your portable
code and include the LOOP package with it.  If the white pages are to
include everything that any individual wants to use in his code then we
would have to include CGOL, Interlisp Compatibility Package, Flavors,
three kinds of Smalltalk, Actors, Dick Waters' pseudo-Fortran macros,
etc.

My philosophy on this, such as it is, is that when a package is not
essential and when there is a substantial portion of the community that
has some doubts about the package's merits, it should go into the yellow
pages.  There it can compete in the marketplace of ideas.  Perhaps it
will come to be used by most of us, and we can promote it to the white
pages at that time.  Perhaps something better will come along to fill
the same niche, and in that case we will not be burdened with the
original package forever.  Perhaps users will decide that it is easier
just to do whatever the package does by hand than to remember its
complexities, and in that case we will have spared the readers of the
white pages from dealing with a lot of needless complexity.

I could be wrong, but I think that the proposed LOOP package only
appeals to a few of us.  If so, I think a probationary period in the
yellow pages is appropriate.  If I'm wrong and I'm the last holdout for
the old Lispy syntax, then LOOP should go directly into the white pages;
in that case, I hope it can be documented very clearly, since new users
are going to have to absorb it all.

-- Scott


Date: Friday, 27 August 1982  21:25-EDT
From: JLK at SCRC-TENEX
To: MOON at SCRC-TENEX
Cc: BUG-LOOP at MIT-ML, Common-Lisp at SU-AI, 
      Scott E. Fahlman <Fahlman at Cmu-20c>
Subject: 2nd generation LOOP macro

I don't feel like arguing yet again why DO is fundamentally inadequate
and causes you to write unmodular, unreadable code when you use it for
advanced parallel/serial binding and flexibly-sequenced initial, end-test,
and exit clauses, but maybe someone who is more energetic should undertake
this.  I believe it is worth the cost of the keyword syntax.


Date: 27 August 1982 19:47-EDT
From: Richard M. Stallman <RMS at MIT-ML>
To: common-lisp at SU-AI

Wouldn't it be more uniform for the arguments to ARRAY-DIMENSION to put
the array before the dimension number?
Since this function is new, it is no loss to change it.


Date: 27 Aug 1982 1754-EDT
From: Richard M. Stallman <RMS at MIT-OZ at MIT-AI>
Subject: SET
To: common-lisp at SU-AI

I am happy to have SET eliminated from the definition of common lisp,
but that doesn't mean I'm willing to stop supporting it, with its
present meaning, on the Lisp machine.  I don't want to find every
SET in the Lisp machine system, or make the users do so.
-------


Date: Friday, 27 August 1982  15:00-EDT
From: MOON at SCRC-TENEX
To: Scott E. Fahlman <Fahlman at Cmu-20c>
Cc: Common-Lisp at SU-AI
Subject: function specs

The points are these:

1. To have the names be understood by programs, so that you can manipulate
functions that are stored in odd places the same way you manipulate functions
that are stored in the normal place.  This is why the name of a function and
the name of where it is stored want to be the same.

2. To avoid having to cons up ridiculous symbols, like FOO-INTERNAL-GO0067,
by not requiring the names of all functions to be symbols.

Is it that you disagree that symbols like that are ridiculous, or is that
you don't see what use it is to be able to manipulate (TRACE, for example)
all functions in a uniform way?


Date: Friday, 27 August 1982  15:00-EDT
From: MOON at SCRC-TENEX
To: Scott E. Fahlman <Fahlman at Cmu-20c>
Cc: Common-Lisp at SU-AI
Subject: function specs

The points are these:

1. To have the names be understood by programs, so that you can manipulate
functions that are stored in odd places the same way you manipulate functions
that are stored in the normal place.  This is why the name of a function and
the name of where it is stored want to be the same.

2. To avoid having to cons up ridiculous symbols, like FOO-INTERNAL-GO0067,
by not requiring the names of all functions to be symbols.

Is it that you disagree that symbols like that are ridiculous, or is that
you don't see what use it is to be able to manipulate (TRACE, for example)
all functions in a uniform way?


Date: Friday, 27 August 1982  14:39-EDT
From: MOON at SCRC-TENEX
to: common-lisp at su-ai
Subject: case sensitivity

Just in case there are people who think that case insensitivity is
wanted by a bunch of old fogeys with model 33 teletypes who haven't yet
experienced the joyous revelation of case sensitivity, let me point out
that when I switched from a case-sensitive system and Lisp to a case-
insensitive one, I found it to be a big improvement.  I think this is
because I don't pronounce the upper-case letters when I speak.

So I'm not willing to believe that case-sensitivity is the wave of the
future.  Nor am I willing to believe that having a monocase system
where the case is always lower case is better (or worse) than having
a monocase system where the case is always upper case.

I don't think we can satisfy everybody on this one.  Let's leave things
the way they are unless someone comes up with a concrete, fully
specified, practical proposal for a set of modes that collectively
satisfy everyone and are not incompatible.


Date: Friday, 27 August 1982  14:23-EDT
From: MOON at SCRC-TENEX
To: Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC>
Cc: common-lisp at SU-AI, EAK at MIT-MC
Subject: assert

    Date: Thursday, 26 August 1982, 12:32-EDT
    From: Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC>

    I would have sworn I saw an ASSERT form in the Colander Edition at one
    point, but for some reason I can't find it now.  It's not in the index.

It's in the addendum that was passed out at the Lisp conference.


Date: Friday, 27 August 1982  14:16-EDT
From: MOON at SCRC-TENEX
To: common-lisp at sail
Subject:dynamic closures

Let me point out that it is trivial to implement dynamic closures in a
shallow-bound system with no extra cost for special-variable accessing and
storing, as long as you are willing to make BOTH entering a closure and
leaving a closure expensive.  The only reason the Lisp machine did it the
way it did was to enable the normal special-variable unbinding mechanism to
be used to leave the environment of a closure.  Thus only entering a
closure is expensive.  If you're willing to copy values in and out, even
when you throw through the application of a closure, and to search the
binding stack if a closure is called recursively, you don't need invisible
pointers.

In a deep-bound system, you have already paid the cost of closures and
adding them costs nothing, of course.

Certainly many of the uses of dynamic closures are better done with
lexical closures, when you have a full upward-funarging lexical Lisp.
I doubt that no uses for dynamic closures remain (unless you are a
purist like Rees and believe that no uses for dynamic variables
remain).  However, I have not yet thought out the issues.

I have no opinion one way or the other as to whether dynamic closures
belong in the Common Lisp kernel language.  Certainly the Lisp machine
will not get rid of them.


Date: Friday, 27 August 1982  14:19-EDT
From: MOON at SCRC-TENEX
To: common-lisp at sail
Subject: splicing reader macros

I should point out explicitly that if you don't document what
"read-internal-token" returns, but only say that READ understands
it, then it can just as well do no I/O and simply return constant
values: whatever READ cares to use as a "no values macro" flag!


Date: Friday, 27 August 1982  13:28-EDT
From: MOON at SCRC-TENEX
To: Scott E. Fahlman <Fahlman at Cmu-20c>
Cc: BUG-LOOP at MIT-ML, Common-Lisp at SU-AI
Subject: 2nd generation LOOP macro

    Date: Thursday, 26 August 1982  20:43-EDT
    From: Scott E. Fahlman <Fahlman at Cmu-20c>

    Is there any reason why LOOP should not be a yellow-pages package for
    those who like this sort of syntax?
One reason is that it is unlikely that any portable code I write will
do its iteration with PROG or DO.


Date: Friday, 27 August 1982, 10:56-EDT
From: Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC>
Subject: ASSERT
To: EAK at MIT-MC
Cc: Common-Lisp at SU-AI
In-reply-to: The message of 26 Aug 82 18:48-EDT from Earl A. Killian <EAK at MIT-MC>

The Lisp Machine does not already have ASSERT.


Date: Thursday, 26 August 1982  23:01-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To: Common-Lisp at SU-AI
Subject: function specs


I have read Moon's description of the function spec business, and then
went back and read the Gray edition of the Chine Nual, and the whole
thing still looks totally bogus to me.  I just don't see why you want to
confound the notion of where a function-object gets stashed with the
notion of what its name is.  If you want your function to have a name, I
see no reason for the name not to be a symbol -- then you can give it
properties, apply it, and so on.  If you don't want to name the thing,
just use lambda and pass around the function object itself.  If you
stash function objects in funny places, why not just put them there
without all the sound and fury?  What could be more extensible than
that?  I admit that we need something clean to replace the ugly old
Maclisp (DEFUN (symbol property) ...) business, but this proposal seems
like massive overkill and is extremely confusing, to me at least.

-- Scott


Date: Thursday, 26 August 1982  21:17-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To: Common-Lisp at SU-AI
Subject: Access to documentation strings


Moon's proposal for DOCUMENTATION looks good to me.

By the way, I think the "convention" that the first line of the
documentation should be an overview sentence is bad news.  If we want
anything of this sort, the convention should be that the first SENTENCE
(normal English syntax) is an overview.  Those of us stuck on narrow
terminals can't get much onto a "line" and I hate to leave out the CR
and let the line wrap.  My preference would be to forget this whole
overview business -- I don't see much use for it.

-- Scott


Date: 26 Aug 1982 17:38:18-PDT
From: Kim.fateman at Berkeley
To: common-lisp@su-ai

As attested to by the common lisp manual itself, it seems lower case
code looks better;  anyone who deliberately writes code that
includes Foo and foo and FoO with the intention that those items
be the same should get his/her keyboard fixed;  there is a 1 line
UNIX command to map all these to (for example) lower case:

tr A-Z a-z <input > output.

It seems like a rather small burden to portability to insist that
functions be spelled the same way each time, just in case someone
reads a package in to a case-sensitive implementation.

But the point I wanted to make is rather different.  Sometimes
case is rather useful.  In mathematical notation, where most people
refer to items by single symbols (hence the use of Greek, Hebrew, and
rather arcane fonts), the absense of distinction between x, X,  and
to continue...  bold x, bold X, italic x, italic X,  .. would not
be considered seriously, I think.  The default in PDP-10 Macsyma
(upper-caseifies) is quite wrong, but there is a switch to change
it (bothcases:true$)


Date: Thursday, 26 Aug 1982 18:38-PDT
To: common-lisp at SU-AI
Subject: Re: CASE SENSITIVITY, REPLY TO COMMENTS
In-reply-to: Your message of Thursday, 26 August 1982  19:31-EDT.
From: mike at RAND-UNIX

(Apologies to those on the list who have heard this and are sick
of the issue).

Scott,

In fact I HAD misunderstood the issue, so thank you for correcting
me.  I was not intending to propose that atoms and functions be
case sensitive, although I could certainly live with that.  I was
proposing that, at least, CommonLisp be case insensitive so that
I would not have to write CAR in all upper case or have the 
interpreter barf at me.  Clearly you have dealt with this issue to
some degree.

As for who I am: I am a computer graphicist at Robert Abel and
Associates, a special effects and film production company in 
Hollywood. 

Regards,
Michael Wahrman



Date: Thursday, 26 August 1982  20:43-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To: BUG-LOOP at MIT-ML
Cc: Common-Lisp at SU-AI
Subject: 2nd generation LOOP macro


Moon's description of LOOP is reasonably clear.  To me, LOOP looks like
a lot of hairy syntax for no reason.  The equivalent DO constructs look
simpler and clearer to me in almost all cases, but then I'm a
conservative -- I don't like CLISP or CGOL either.  People keep coming
up with these things, so there must be a need felt in some quarters to
which I am insensitive.  I would have said that this sort of thing is a
training/transition aid for those not comfortable with Lisp, but
considering the source of this proposal that can't be the true story.

Is there any reason why LOOP should not be a yellow-pages package for
those who like this sort of syntax?

-- Scott


Date: Thursday, 26 August 1982  20:56-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To: David A. Moon <Moon at SCRC-TENEX at MIT-MC>
Cc: Common-Lisp at SU-AI
Subject: Splicing reader macros


Moon's suggestion for READ-TOKEN sounds good to me, even though (as Dill
points out) it is not just a matter of documenting something that
already exists in the case of Spice Lisp.  I can imagine a number of
uses for this function in implementing non-standard parsers.

-- Scott


Date: 26 Aug 1982 17:38:18-PDT
From: Kim.fateman at Berkeley
To: common-lisp@su-ai

As attested to by the common lisp manual itself, it seems lower case
code looks better;  anyone who deliberately writes code that
includes Foo and foo and FoO with the intention that those items
be the same should get his/her keyboard fixed;  there is a 1 line
UNIX command to map all these to (for example) lower case:

tr A-Z a-z <input > output.

It seems like a rather small burden to portability to insist that
functions be spelled the same way each time, just in case someone
reads a package in to a case-sensitive implementation.

But the point I wanted to make is rather different.  Sometimes
case is rather useful.  In mathematical notation, where most people
refer to items by single symbols (hence the use of Greek, Hebrew, and
rather arcane fonts), the absense of distinction between x, X,  and
to continue...  bold x, bold X, italic x, italic X,  .. would not
be considered seriously, I think.  The default in PDP-10 Macsyma
(upper-caseifies) is quite wrong, but there is a switch to change
it (bothcases:true$)


Date: Thursday, 26 August 1982  19:31-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To: COMMON-LISP AT SU-AI, KIM.JKF AT UCB-C70
Cc: mike at RAND-UNIX
Subject: CASE SENSITIVITY, REPLY TO COMMENTS


I am trying hard to follow JKF's suggestion that we not degenerate to a
lot of name-calling about case-sensitivity and all the other
brain-damage that Unix inflicts on its users, but such restraint is hard
to maintain given messages like the previous one from Michael Wahrman
(whoever he is).

To respond to JKF's earlier message:

It is probably true that the earlier decision about case sensitivity was
made with little input from the Franz/Unix people, who at the time were
not much interested in Common Lisp, so I suppose it is not entirely out
of order to reopen the issue.

I find JKF's proposed "compromise" incoherent.  For their own private
hacking, users can translate everything into EBCDIC, for all I care, but
what we are talking about here is a standard for portable Common Lisp
code.  I see no coherent way to let some users decide that "FOO" and
"Foo" are distinct symbols in their code and to have other users ignore
the difference.  It has to be uniformly one way or the other at the
interfaces.  Making the language case sensitive, in the sense that
the difference between "FOO" and "Foo" matters, is absolutely
unacceptable to me and, I think, to most of the other Common Lisp
implementors.

I think that what we are proposing is being misunderstood, at least by
some people out there.  We certainly are not requiring that Common Lisp
users ever type in things in upper case -- they can use any mixture of
case characters that they want.  If we add the proposed switch to PRINT,
then people never have to see upper-case on typeout.  The Unix people I
have talked to here at CMU are happy with that much: as long as they
don't have to read or write upper-case, then it is not important to them
to have "FOO" not eq to "Foo".  But if you folks really insist on true
case-sensitivity in portable code, then we've got a serious
disagreement.

-- Scott


Date: 26 August 1982 18:51-EDT
From: David A. Moon <MOON at MIT-MC>
Subject: 2nd generation LOOP macro
To: Common-Lisp at SU-AI
Reply-to: BUG-LOOP at MIT-ML

Here is an extremely brief summary of the proposed new LOOP design, which
has not yet been finalized.  Consult the writeup on LOOP in the Lisp
Machine manual or MIT LCS TM-169 for background information.  Constructive
comments are very welcome, but please reply to BUG-LOOP at MIT-ML, not to
me personally.

(LOOP form form...) repeatedly evaluates the forms.

In general the body of a loop consists of a series of clauses.  Each
clause is either: a series of one or more lists, which are forms to be
evaluated for effect, delimited by a symbol or the end of the loop; or
a clause-introducing symbol followed by idiosyncratic syntax for that
kind of clause.  Symbols are compared with SAMEPNAMEP.  Atoms other than
symbols are in error, except where a clause's idiosyncratic syntax permits.

1. Primary clauses

1.1 Iteration driving clauses

These clauses run a local variable through a series of values and/or
generate a test for when the iteration is complete.

REPEAT <count>
FOR/AS <var> ...
CYCLE <var> ...

  I won't go into the full syntax here.  Features include: setting
  to values before starting/on the first iteration/on iterations after
  the first; iterating through list elements/conses; iterating through
  sequence elements, forwards or backwards, with or without sequence-type
  declaration; iterating through arithmetic progressions.  CYCLE reverts
  to the beginning of the series when it runs out instead of terminating
  the iteration.

  It is also possible to control whether or not an end-test is generated
  and whether there is a special epilogue only evaluated when an individual
  end-test is triggered.

1.2 Prologue and Epilogue

INITIALLY form form...		forms to be evaluated before starting, but
				after binding local variables.
FINALLY form form...		forms to be evaluated after finishing.

1.3 Delimiter

DO	a sort of semicolon needed in odd situations to terminate a clause,
	for example between an INITIALLY clause and body forms when no named
	clause (e.g. an iteration-driving clause) intervenes.
	We prefer this over parenthesization of clauses because of the
	general philosophy that it is more important to make the simple cases
	as readable as possible than to make micro-improvements in the
	complicated cases.

1.4 Blockname

NAMED name		Gives the block generated by LOOP a name so that
			RETURN-FROM may be used.

This will be changed to conform with whatever is put into Common Lisp
for named PROGs and DOs, if necessary.

2. Relevant special forms

The following special forms are useful inside the body of a LOOP.  Note
that they need not appear at top level, but may be nested inside other
Lisp forms, most usefully bindings and conditionals.

(COLLECT <value> [USING <collection-mode>] [INTO <var>] [BACKWARDS]
		[FROM <initial-value>] [IF-NONE <expr>] [[TYPE] <type>])
This special form signals an error if not used lexically inside a LOOP.
Each time it is evaluated, <value> is evaluated and accumulated in a way
controlled by <collection-mode>; the default is to form an ordered list.
The accumulated values are returned from the LOOP if it is finished
normally, unless INTO is used to put them into a variable (which gets
bound locally to the LOOP).  Certain accumulation modes (boolean AND and
OR) cause immediate termination of the LOOP as soon as the result is known,
when not collecting into a variable.

Collection modes are extensible by the user.  A brief summary of predefined
ones includes aggregated boolean tests; lists (both element-by-element and
segment-by-segment); commutative/associative arithmetic operators (plus,
times, max, min, gcd, lcm, count); sets (union, intersection, adjoin);
forming a sequence (array, string).

Multiple COLLECT forms may appear in a single loop; they are checked for
compatibility (the return value cannot both be a list of values and a
sum of numbers, for example).

(RETURN value) returns immediately from a LOOP, as from any other block.
RETURN-FROM works too, of course.

(LOOP-FINISH) terminates the LOOP, executing the epilogue and returning
any value defined by a COLLECT special form.

[Should RESTART be interfaced to LOOP, or only be legal for plain blocks?]

3. Secondary clauses

These clauses are useful abbreviations for things that can also be done
using the primary clauses and Lisp special forms.  They exist to make
simple cases more readable.  As a matter of style, their use is strongly
discouraged in complex cases, especially those involving complex or
nested conditionals.

3.1 End tests

WHILE <expr>		(IF (NOT <expr>) (LOOP-FINISH))
UNTIL <expr>		(IF <expr> (LOOP-FINISH))

3.2 Conditionals

WHEN <expr> <clause>	The clause is performed conditionally.
IF <expr> <clause>	synonymous with WHEN
UNLESS <expr> <clause>	opposite of WHEN

AND <clause>		May be suffixed to a conditional.  These two
ELSE <clause>		might be flushed as over-complex.

3.3 Bindings

WITH <var> ...		Equivalent to wrapping LET around the LOOP.
			This exists to promote readability by decreasing
			indentation.

3.4 Return values

RETURN <expr>		synonymous with (RETURN <expr>)

COLLECT ...		synonymous with (COLLECT ...)
NCONC ...		synonymous with (COLLECT ... USING NCONC)
APPEND, SUM, COUNT, MINIMIZE, etc. are analogous
ALWAYS, NEVER, THEREIS	abbreviations for boolean collection

4. Extensibility

There are ways for users to define new iteration driving clauses which
I will not go into here.  The syntax is more flexible than the existing
path mechanism.

There are also ways to define new kinds of collection.

5. Compatibility

The second generation LOOP will accept most first-generation LOOP forms
and execute them in the same way, although this was not a primary goal.
Some complex (and unreadable!) forms will not execute the same way or
will be errors.

6. Documentation

We intend to come up with much better examples.  Examples are very
important for developing a sense of style, which is really what LOOP
is all about.


Date: 26 August 1982 18:48-EDT
From: Earl A. Killian <EAK at MIT-MC>
Subject: ASSERT
To: DLW at SCRC-TENEX
cc: Common-Lisp at SU-AI

I don't remember whether ASSERT was in the manual before.  Does
the LISPM already have one?  If not, as a more concrete proposal
I suggest

ASSERT test &optional formatstring &rest formatargs


Date: Thursday, 26 August 1982  16:34-EDT
From: Jonathan Rees <Rees at YALE>
To: Fahlman at CMU-20C
Cc: Common-Lisp at SU-AI
Subject: Closures

						... Can the Scheme
    hackers out there explain to us which uses of dynamic closure are
    subsumed under lexical closure and which uses really need the dynamic
    closures?

I've been using Scheme-style closures heavily for a couple of years now and
can attest to their wonderfulness.  I am tempted to say that they are
sufficient to handle the applications to which Lisp Machine-style
closures are put, but I say this from a position of weakness since I've
never actually used the other kind of closure.  I suspect that it is the
case that there's no hacker out there who has extensive experience with
both beasts; such a person would be the one to consult.  All I can say
is that I've never felt the need to close over special variables.  Name
the application - I believe Scheme closures work as well if not better
than other kinds.

As many of you know, I'm quite biased on this matter.  But as
implementor and user I strongly advise against the inclusion of Lisp
Machine-style closures in the language.

				Jonathan Rees
				Scheme Hacker


Date: Thursday, 26 Aug 1982 14:10-PDT
TO: KIM.JKF AT UCB-C70
CC: COMMON-LISP AT SU-AI
SUBJECT: RE: CASE SENSITIVITY, REPLY TO COMMENTS
IN-REPLY-TO: YOUR MESSAGE OF 25 AUG 1982 23:15:45-PDT
 25-AUG-82 23:22:56-PDT (WED).
             <60852.29572.KIM@BERKELEY>
From: mike at RAND-UNIX


I'M GLAD THAT THE ISSUE OF CASE SENSITIVITY WAS REOPENED AS I THINK
THAT THERE IS A REALITY ISSUE HERE THAT IS BEING MISSED.

IF THE STANDARD DOES NOT MAKE PROVISION FOR UPPER/LOWER CASE 
THEN YOU WILL HAVE GUARANTEED THAT FROM DAY ONE THERE WILL BE IMPLEMENTATIONS
OF "COMMONLISP" THAT DO NOT MEET THE STANDARD.  THIS BECAUSE THERE IS A
LARGE COMMUNITY OF COMPUTER AND LISP USERS WHO BELIEVE THAT MOVING
TO UPPER/LOWER CASE IS ONE OF THOSE LITTLE IMPROVEMENTS IN THE LAST TEN YEARS
THAT HAVE MADE WORKING WITH COMPUTERS MORE SWELL.

JOHN HAS OFFERED A VERY REASONABLE IMPLEMENTATION
THAT ALLOWS UPPER-CASE ONLY SYSTEMS TO EXIST AS WELL ALLOWING OTHERS
TO MOVE INTO A MORE FULL-ASCII REALITY. 

MICHAEL WAHRMAN
(LISP USER, NOT IMPLEMENTOR)


Date: Thursday, 26 August 1982  16:34-EDT
From: Jonathan Rees <Rees at YALE>
To: Fahlman at CMU-20C
Cc: Common-Lisp at SU-AI
Subject: Closures

						... Can the Scheme
    hackers out there explain to us which uses of dynamic closure are
    subsumed under lexical closure and which uses really need the dynamic
    closures?

I've been using Scheme-style closures heavily for a couple of years now and
can attest to their wonderfulness.  I am tempted to say that they are
sufficient to handle the applications to which Lisp Machine-style
closures are put, but I say this from a position of weakness since I've
never actually used the other kind of closure.  I suspect that it is the
case that there's no hacker out there who has extensive experience with
both beasts; such a person would be the one to consult.  All I can say
is that I've never felt the need to close over special variables.  Name
the application - I believe Scheme closures work as well if not better
than other kinds.

As many of you know, I'm quite biased on this matter.  But as
implementor and user I strongly advise against the inclusion of Lisp
Machine-style closures in the language.

				Jonathan Rees
				Scheme Hacker


Date: Thursday, 26 August 1982  15:08-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To: Scott E. Fahlman <Fahlman at CMU-20C>
Cc: common-lisp at SU-AI, Guy.Steele at CMU-10A
Subject: Closures (addendum)


By the way, on the Vax, at least, it is not necessarily the case that
dynamic closures cost you an extra cycle on every special variable
reference.  When you pick up a special value, you have to check for the
unbound marker anyway, and if things are arranged properly this same
check can pick off the case of an EVC-pointer or whatever.  So the only
extra cost is on function entry or when you actually do have a ref to a
closed-over or unbound special.  If there were no checking at all of the
special value before returning it, then the EVC-forward check would
indeed cost you a cycle.  Perhaps Hedrick is picking off unbound
specials some other way (or not at all?) and the closure cost is
therefore real to him.  Evan if it cost a whole cycle per special ref,
I'm not sure that that would slow the language down noticeably, since
specials are somewhere down below 10% of all variable refs in the
assorted statistics I've seen.  We can't let them become aribitrarily
bad, but maybe an extra cycle or two is tolerable.

As I said, if we can get the same effect with lexical vars, we should do
it that way.

-- Scott


Date: Thursday, 26 August 1982  15:08-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To: Scott E. Fahlman <Fahlman at CMU-20C>
Cc: common-lisp at SU-AI, Guy.Steele at CMU-10A
Subject: Closures (addendum)


By the way, on the Vax, at least, it is not necessarily the case that
dynamic closures cost you an extra cycle on every special variable
reference.  When you pick up a special value, you have to check for the
unbound marker anyway, and if things are arranged properly this same
check can pick off the case of an EVC-pointer or whatever.  So the only
extra cost is on function entry or when you actually do have a ref to a
closed-over or unbound special.  If there were no checking at all of the
special value before returning it, then the EVC-forward check would
indeed cost you a cycle.  Perhaps Hedrick is picking off unbound
specials some other way (or not at all?) and the closure cost is
therefore real to him.  Evan if it cost a whole cycle per special ref,
I'm not sure that that would slow the language down noticeably, since
specials are somewhere down below 10% of all variable refs in the
assorted statistics I've seen.  We can't let them become aribitrarily
bad, but maybe an extra cycle or two is tolerable.

As I said, if we can get the same effect with lexical vars, we should do
it that way.

-- Scott


Date: Thursday, 26 August 1982  14:22-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To: Guy.Steele at CMU-10A
Cc: common-lisp at SU-AI
Subject: Closures


I'm willing to waste a cycle or two per call even in compiled code to
have the functionality of closures around.  I think that I would use
closures a lot, once they were available, and wonder how we ever lived
without them.  In fact, I meant to raise the question of whether we need
another function to evaluate an arbitrary form in the environment of a
closure.

Having said that, let me also say that I have not yet thought through
the issue of whether the presence of lexical-scope/indefinite-extent
varaibles in the language makes dynamic closures unneccessary.  If the
lexical mechanism does most of the useful things that we would otherwise
have to do with closures (generators, families of active objects with
some shared but non-global state...?), then I would favor dropping the
dynamic closures from the language.  The lexical "closures" would
compile better and, in some sense, be more elegant, since dynamically
closing over only a few specific variables is a crock.  Can the Scheme
hackers out there explain to us which uses of dynamic closure are
subsumed under lexical closure and which uses really need the dynamic
closures?

-- Scott


Date: 26 August 1982 1358-EDT (Thursday)
From: David.Dill at CMU-10A (L170DD60)
To: common-lisp at su-ai
Subject:  splicing macros
Message-Id: <26Aug82 135845 DD60@CMU-10A>

You can always do a multiple-value-list and see if it's nil.  Maybe we
need a non-consing way to count return values, as suggested earlier.

The reader for Spice Lisp doesn't have a read-internal-token routine.
	-Dave


Date: 26 August 1982 1315-EDT (Thursday)
From: Guy.Steele at CMU-10A
To: common-lisp at SU-AI
Subject:  Closures

I must apologize for failing to raise at the Saturday meeting
the one issue Hedrick had asked me to mention.  He noted that
the requirement for closures over special variables has an impact
on the performance of stock hardware for all special variables,
whether closed over or not, and proposed removing this feature
from the white pages.  How do people feel about this?
--Guy


Date: Thursday, 26 August 1982, 12:34-EDT
From: Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC>
Subject: a protest
To: HEDRICK at RUTGERS, common-lisp at SU-AI
In-reply-to: The message of 24 Aug 82 13:21-EDT from Mgr DEC-20s/Dir LCSR Comp Facility <HEDRICK at RUTGERS>

Jonathan Rees is right.  Since GO is lexical, the compiler can easily
determine at compile-time whether any of the GOs are non-local, and
decide on that basis whether to generate a catch-frame-like-thing for
the PROG or not.


Date: Thursday, 26 August 1982, 12:32-EDT
From: Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC>
Subject: assert
To: EAK at MIT-MC, common-lisp at SU-AI
In-reply-to: The message of 24 Aug 82 20:53-EDT from Earl A. Killian <EAK at MIT-MC>

I would have sworn I saw an ASSERT form in the Colander Edition at one
point, but for some reason I can't find it now.  It's not in the index.
Am I confused?


Date: Thursday, 26 August 1982, 03:53-EDT
From: David A. Moon <Moon at SCRC-TENEX at MIT-MC>
Subject: function specs
To: Common-Lisp at SU-AI

Here is some brief background information on function specs in the Lisp machine.
See page 136 in the gray (or blue, depending on whether you are from the North
or the South) Lisp Machine manual for further information.

The basic idea is that it is useful to store functions in more places than
the definition cell of a symbol, and it is dumb to have to make up generated
symbols when doing this.  The most immediate examples are internal functions
lexically nested inside other functions, methods in class/flavor systems, and
unnamed dispatch functions stored on property lists.  It is very useful to
have a name for such functions so that you can edit them, trace them, get
told their name in the debugger, etc.  It's also very useful to make the whole
thing extensible so users can add their own places to stash functions.

The convention is that the name of any function whose name isn't a symbol
is a list whose first element is a keyword identifying the kind of function,
and whose remaining elements are "arguments" to that keyword.  The first element
doesn't have to be an actual keyword; if it makes sense for a function spec
type to be confined to some particular package, the first element can be
a symbol in that package.

The operations on a function spec are defined by the following functions.
The names are fairly self-evident, so check a Lisp machine manual for details.

(FDEFINE function-spec definition &OPTIONAL carefully-flag no-query-flag)
(FDEFINEDP function-spec) => T or NIL
(FDEFINITION function-spec) => a function
(FDEFINITION-LOCATION function-spec) => a locative pointer to a definition cell
(FUNDEFINE function-spec)
(FUNCTION-PARENT function-spec) => NIL or (VALUES name type) of a top-level
  defining form which generated this function, perhaps along with other things.
  It might be a DEFSTRUCT, for example.
(COMPILER-FDEFINEDP function-spec) => returns T if will be fdefinedp at run time
(FUNCTION-SPEC-GET functions-spec indicator) => NIL or property
(FUNCTION-SPEC-PUTPROP function-spec value indicator)

One defines a new function spec type by putting a property on its keyword
symbol.  The property is a function which follows a protocol (which I won't
elaborate here) to implement the functions described above.  There is a default
handler to ease implementation of new function spec types.

The function spec types defined in the Lisp environment from which I am sending
this message are as follows.  I'll list and describe them all just to give you an
idea of how this might be used.  Certainly most of these do not belong in
Common Lisp--the point is that they are extensions implementable through a
predefined general mechanism.  The order is alphabetical, not rational.

(:DEFUN-METHOD name) -- an internal function used by the flavor system in
the implementation of a function named <name>; the internal function is called
directly when certain error checking is known to be unnecessary.

(:HANDLER flavor message) -- the function invoked when a certain message
is sent to an object of a certain flavor.  This is different from :METHOD
because of method inheritance and method combination.  This function spec
mainly exists so you can trace it.

(:INTERNAL function-spec index [name]) -- a function nested inside another
function, named function-spec.  index is a number to keep them unique and
name is an optional name (it exists if LABELS rather than a plain LAMBDA
was used to define the function.)

(:LAMBDA-MACRO symbol) -- the function which expands forms like ((symbol ...)...)

(:LOCATION locative) -- a function stored in a particular cell

(:METHOD flavor [modifiers...] message) -- a method which supplies part of
the behavior for a certain message to objects built out of a certain flavor.

(:PROPERTY symbol property) -- a function stored on a property list

(:SELECT-METHOD function-spec message) -- an internal function generated
by DEFSELECT, nested inside a select-function named function-spec.

(:WITHIN within-function renamed-function) -- a function which masquerades
as another function within a third function.  TRACE uses this.


Date: Thursday, 26 August 1982, 03:25-EDT
From: David A. Moon <Moon at SCRC-TENEX at MIT-MC>
Subject: Access to documentation strings
To: Common-Lisp at SU-AI

I think I was supposed to make a proposal about this.

Rather than using some specific property, documentation strings should
be stored in an implementation-dependent way and there should be a
function to access them.  There are many reasons for this, including
multiple documented objects with the same name, documented objects whose
name is not a symbol, and implementations where the documentation is not
a Lisp string until you ask for it (it might reside in the compiled code
in a special machine-dependent format, or it might be retrieved from a
separate documentation file, hopefully in a speedy fashion.)

I don't think we need a separate function to get the brief
documentation, it's just (SUBSEQ doc 0 (POSITION #\Return doc)).  I
suggest the present Lisp machine function DOCUMENTATION, extended to be
similar to GET-SOURCE-FILE-NAME.  The latter function could exist in
Common Lisp as well, although perhaps not all implementations want to
remember source files for each function.

Details:
DOCUMENTATION name &OPTIONAL type
  (VALUES string type)

Accesses the documentation string for a named object.  name is the name
of an object, usually a symbol.  type is a symbol for the type of object
(see below), or NIL meaning take any type that is there, preferring a
function if there is one.  There can be multiple objects of different
types with the same name.

The first value returned is the documentation string, and the second value
is the type of object; this is only useful when the type argument was
NIL or unspecified.  If there is no documentation recorded, or no object
known with this name and type, both values are NIL.  This is not an error.

[Here I do not use "object" in the Smalltalk sense.  Would "definition"
be a better word, or does it imply "function" too strongly?]

Names of objects are usually symbols, although any Lisp object (compared
with EQUAL) is allowed.  Function names can be lists when function specs
exist.  User-defined objects could have almost anything as their name.

By special dispensation, the first argument may be a function (interpreted
or compiled) which is equivalent to supplying the name of the function.

The pre-defined object types are DEFUN for a function, special form, or
macro; DEFVAR for a global variable, parameter, or constant; DEFSTRUCT
for a structure.  There are other implementation-dependent types, and
user programs may freely add their own types.  As you can see the naming
convention is to use the name of the principle defining special form,
if there is one.  Object type symbols are deliberately not keywords,
since user-defined types may need to be protected from each other by the
package mechanism.

There is a companion function:
RECORD-DOCUMENTATION name type string

string can be NIL, which means to forget the documentation.  In some
implementations documentation for some types (especially DEFUN) is
not recorded by calling this function, but is stored some other way,
however the user can always call RECORD-DOCUMENTATION.

If people prefer, (SETF (DOCUMENTATION name type) string) would be
acceptable for this.  Note that type should not be optional when setting.


Date: Thursday, 26 August 1982, 03:25-EDT
From: David A. Moon <Moon at SCRC-TENEX at MIT-MC>
Subject: Access to documentation strings
To: Common-Lisp at SU-AI

I think I was supposed to make a proposal about this.

Rather than using some specific property, documentation strings should
be stored in an implementation-dependent way and there should be a
function to access them.  There are many reasons for this, including
multiple documented objects with the same name, documented objects whose
name is not a symbol, and implementations where the documentation is not
a Lisp string until you ask for it (it might reside in the compiled code
in a special machine-dependent format, or it might be retrieved from a
separate documentation file, hopefully in a speedy fashion.)

I don't think we need a separate function to get the brief
documentation, it's just (SUBSEQ doc 0 (POSITION #\Return doc)).  I
suggest the present Lisp machine function DOCUMENTATION, extended to be
similar to GET-SOURCE-FILE-NAME.  The latter function could exist in
Common Lisp as well, although perhaps not all implementations want to
remember source files for each function.

Details:
DOCUMENTATION name &OPTIONAL type
  (VALUES string type)

Accesses the documentation string for a named object.  name is the name
of an object, usually a symbol.  type is a symbol for the type of object
(see below), or NIL meaning take any type that is there, preferring a
function if there is one.  There can be multiple objects of different
types with the same name.

The first value returned is the documentation string, and the second value
is the type of object; this is only useful when the type argument was
NIL or unspecified.  If there is no documentation recorded, or no object
known with this name and type, both values are NIL.  This is not an error.

[Here I do not use "object" in the Smalltalk sense.  Would "definition"
be a better word, or does it imply "function" too strongly?]

Names of objects are usually symbols, although any Lisp object (compared
with EQUAL) is allowed.  Function names can be lists when function specs
exist.  User-defined objects could have almost anything as their name.

By special dispensation, the first argument may be a function (interpreted
or compiled) which is equivalent to supplying the name of the function.

The pre-defined object types are DEFUN for a function, special form, or
macro; DEFVAR for a global variable, parameter, or constant; DEFSTRUCT
for a structure.  There are other implementation-dependent types, and
user programs may freely add their own types.  As you can see the naming
convention is to use the name of the principle defining special form,
if there is one.  Object type symbols are deliberately not keywords,
since user-defined types may need to be protected from each other by the
package mechanism.

There is a companion function:
RECORD-DOCUMENTATION name type string

string can be NIL, which means to forget the documentation.  In some
implementations documentation for some types (especially DEFUN) is
not recorded by calling this function, but is stored some other way,
however the user can always call RECORD-DOCUMENTATION.

If people prefer, (SETF (DOCUMENTATION name type) string) would be
acceptable for this.  Note that type should not be optional when setting.


Date: Thursday, 26 August 1982, 03:04-EDT
From: David A. Moon <Moon at SCRC-TENEX at MIT-MC>
Subject: CHECK-ARG-TYPE
To: Common-Lisp at SU-AI

See p.275 of the 29 July Common Lisp manual and p.275 of the revision
handed out at the Lisp conference.

I suggest that we include CHECK-ARG-TYPE in the language.  Although
CHECK-ARG, CHECK-ARG-TYPE, and ASSERT have partially-overlapping
functionality, each has its own valuable uses and I think all three
ought to be in the language.

Note that CHECK-ARG and CHECK-ARG-TYPE are used when you want explicit
run-time checking, including but not limited to writing the interpreter
(which of course is written in Lisp, not machine language!).

The details:
CHECK-ARG-TYPE arg-name type &OPTIONAL type-string	[macro]

If (TYPEP arg-name 'type) is false, signal an error.  The error message
includes arg-name and a "pretty" English-language form of type, which
can be overridden by specifying type-string (this override is rarely
used).  Proceeding from the error sets arg-name to a new value and
makes the test again.

Currently arg-name must be a variable, but it should be generalized to
any SETF'able place.

type and type-string are not evaluated.

This isn't always used for checking arguments, since the value of any
variable can be checked, but it is usually used for arguments and there
isn't an alternate name that more clearly describes what it does.


Date: Thursday, 26 August 1982, 02:54-EDT
From: David A. Moon <Moon at SCRC-TENEX at MIT-MC>
Subject: Splicing reader macros
To: Common-Lisp at SU-AI

I think I forgot to bring this up at the meeting last Saturday.

The cute kludge by which splicing reader macros (reduced to just
reader macros that don't read anything, e.g. comments and unsatisfied
conditionals) identify themselves, namely returning (VALUES), doesn't
work so nicely now that the multiple-value-taking forms with &OPTIONAL
and &REST have been removed from the language.

Someone (Eric Benson?) suggested that such macros call READ tail recursively.
Of course this doesn't work, since you can have situations like
	(COND ((FOO-P A)
	       (BLATZ B)
	       ;Okay, that takes care of B
	       ))
where the macro is followed by a special token, not by an S-expressions.
However, clearly there is a function inside the reader which such macros
could call tail recursively if they could only get at it.  For instance,
in the Lisp machine this is called SI:XR-READ-THING.

I suggest that we come up with a reasonable name for this function, perhaps
something like READ-INTERNAL-TOKEN, document it, and allow reader macros
to call it.  We could document the two values it returns (an object and what
kind of token it is), or we could say that all you can do with the values
is return them to the reader and they are its internal business.


Date: 25 Aug 1982 23:15:45-PDT
From: Kim.jkf at Berkeley
Mail-From: UCBKIM received by UCBVAX at 25-Aug-82 23:23:57-PDT (Wed)
Date: 25-Aug-82 23:22:56-PDT (Wed)
From: Kim:jkf (John Foderaro)
Subject: case sensitivity, reply to comments
Message-Id: <60852.29572.Kim@Berkeley>
Via: ucbkim.EtherNet (V3.147 [7/22/82]); 25-Aug-82 23:22:58-PDT (Wed)
Via: ucbvax.EtherNet (V3.147 [7/22/82]); 25-Aug-82 23:23:57-PDT (Wed)
To: common-lisp@su-ai

  I don't think that it is too late to discuss this issue.  Surely no
implementation or planned implementation depends so much on conversion to
upper case that it would require more than a few minutes to alter it to
convert to lower case and have case sensitivity as an option.

  Scott mentioned that this issue was decided nine month ago and that
      ... the overwhelming majority of people wanted to avoid making
      Common Lisp case-sensitive.
  This brings up two questions:
  1) how many people did you have to argue the side of case sensitive lisps?
  and more importantly:
  2) did anyone suggest the compromise I've proposed which requires both case
  sensitive and case insensitive readers?  If the committee members felt
  that they had to choose between a case sensitive and a case insensitive
  reader, then, based on the committee's composition, it is no surprise that
  they chose a case insensitive one.  


Regarding portability:
    Like Scott, I consider this to be very important.  This is, in fact, the
primary reason why Common Lisp must make the option to be case-sensitive
part of the standard.  If I write a file of case-sensitive code, I need only
put the appropriate eval-when's at the beginning of the code to tell the
loader/compiler to switch to case-sensitive mode when reading the rest of
this file.  That will insure the portability of my code no matter what the
environment is when it is read in.

    If case-sensitivity is not part of the Common Lisp standard, then some
sites will add it as an extension and it will just about guarantee that
their code is non-portable.

Conversion to upper or lower case:
    I agree that it is important to always convert to either lower or to
upper case when in case insensitive mode.  The arguments for each case
(according to Scott) are:

upper: 'tradition of past Lisps'.
    What is is this tradition based on?  Is it based on the brilliant
insight of a Lisp pioneer?  No, of course not.  It is based on the crummy
upper case only teletypes that existed in the old days.  Shall Common Lisp
become a shrine for the memory of the Teletype Model 33?

lower: 'tradition of Unix'
    What is important is not Unix itself, but the fact that as a result of
using Unix many people now enjoy (and expect) case-sensitivity in systems
they use.  If case-sensitivity is put into Common Lisp as an option, then it
is imperative that system symbols be in lower case or else Common Lisp would
be unreasonable to use when case sensitivity is turned on.
If case sensitivity is not put in then the only thing gained by converting
to lower case is readability.


Those are the arguments for upper or lower case.  Since converting to
upper case harms the case sensitive crowd, and  converting to lower
case harms no one but helps the case sensitive crowd, the choice seems
obvious.

    The biggest problem here is inertia.  Just ask yourself whether adding a
case sensitive switch will harm you if you never use it.  Consider that it
will make the Common Lisp a lot more palatable to a large group of users.
And consider that without conversion to lower case in case-insensitive mode,
the case-sensitive mode would be almost useless.

    It seems that too much time has been spent trying to find a middle ground
between case sensitivity and insensitivity, that is one which assumes case
insensitivity and then trys to add features of case sensitive languages
(such as 'what you type in is what gets printed out').  I don't think this
kind of thing is worth the effort. It certainly won't satisfy the
case-sensitive person who feels that Foo and foo are distinct things.

					John Foderaro
					



Date: Wednesday, 25 August 1982  23:12-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To: common-lisp at SU-AI
Subject: SET


By the way, I completely forgot about SET (in its traditional meaning)
when enumerating the things I would like to spare from the SETF wrecking
ball.  (That's the danger of saying "we should get rid of everything
except... ")  I'd like to keep old-style SET around.  I find
(SETF (SYMEVAL x) value) to be confusing.  This should be legal, but not
the one and only way to do this.

Keeping SET would have the beneficial side-effect of terminating debate
about whether to turn SETF into SET, though I suppose we could swap
them... (or is it swapf them?)

-- Scott


Date: Wednesday, 25 August 1982  20:56-EDT
From: Jim Large <LARGE at CMU-20C>
To: Earl A. Killian <Killian at MIT-MULTICS>
Cc: Common-Lisp at SU-AI
Subject: SETF, case, etc.

  Of course, your source code is allowed to be lowercase.  The manual
doesn't forbid (SETQ MultiWordVarName NIL) in a program.
								Jim Large


Date:     25 August 1982 1452-pdt
From:     Earl A. Killian            <Killian at MIT-MULTICS>
Subject:  SETF, case, etc.
To:       Fahlman at CMUc
cc:       Common-Lisp at SU-AI

The manual still seems obviously incomplete to me (just look at the
compiler and evaluator chapters), and so I assume there will still be at
least one more meeting, etc. and so some of these ideas are still worth
bringing up.  If that is not the case, then someone should say so.

However, I agree with you on the subject of case sensitivity.  There
were many serious attempts to find a way to preserve case that failed.
Not uppercasing on READ should be easy enough as is so that a special
option shouldn't be necessary, though I'm at a loss as to how to do it
from the description in the current manual (I hope this is a failure in
the documentation and not the language).  Doing this would let you write
code as in

(SETQ MultiWordVarName NIL)

as many Interlisp users do all the time (though possible in Maclisp, it
never caught on).  This is probably not quite what the lowercasers want,
but given the strong feelings of uppercasers, I don't see how any more
can be done.  An option to print in lowercase seems pretty reasonable.

Also, for passing things to the os, which someone was worrying about, I
expect that people will use strings, which are not touched, case-wise.


P.S. to GLS: the manual mentions nonterminating macro chars several
times, but doesn't really say what their real semantics are.  This needs
to be fixed.


Date: 25 August 1982 17:46-EDT
From: Howard I. Cannon <HIC at MIT-MC>
Subject:  Issue #106
To: Moon at SCRC-TENEX
cc: common-lisp at SU-AI, STEELE at CMU-20C

    Date: Monday, 23 August 1982, 20:45-EDT
    From: David A. Moon <Moon at SCRC-TENEX>
    To:   STEELE at CMU-20C
    cc:   common-lisp at SU-AI
    Re:   Issue #106

    According to my notes of the meeting, we agreed on CATENATE rather than
    CONCATENATE.  I was sitting at the opposite end of the table from GLS.
    Opinions/facts?


We absolutly agreed on CONCATENATE.  I remember you didn't like it.


Date: Wednesday, 25 August 1982  17:41-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To: common-lisp at SU-AI
Subject: SETF, case, etc.


There must come a time when finalizing the manual takes precedence over
endless twiddling of the names of various functions.  Last Saturday's
meeting was that time, in my opinion.  We should now go ahead with the
names we have decided upon, and suggestions for name changes on the
basis of someone's idea of good taste or elegance should be considered
out of order.  Only those changes that make some real difference
(avoiding a conflict that we failed to notice before, etc.) should be
considered at this point.

In a similar vein, we considered the issue of case-sensitivity about
nine months ago and settled on the current scheme.  I don't think that
there is much to be gained by reopening the issue now.  Case-sensitivity
is not something that we can leave to individual choice if code is to be
portable, and the overwhelming majority of people wanted to avoid making
Common Lisp case-sensitive.  Several attempts were made to come up with
a coherent scheme to match symbols in a case-insensitive way but to type
them out in whatever case they were first seen in; all of these attempts
failed.

As it stands, intern IS case-sensitive, but the reader upper-casifies
things by default.  It is easy for users to turn off the upper-case
conversion in the reader, and then they have a case-sensitive Lisp.
However, the built-in symbols are all upper-case, so these users have to
type them in that way.  Code that is intended to be portable should
assume the default environment, which does not preserve case.  It is
somewhat arbitrary that upper-case was chosen over lower-case as the
default, but for portability there has to be an internal default and the
tradition of past Lisps won out over the tradition of Unix.

At one point we discussed the possibility of adding a switch to print
symbols preferentially in lower-case.  I can't find this in the current
manual, but it would be easy to add as an implementation-dependent
extension.  This causes no problems, as long as the resulting output is
read back in through the upper-casifying reader.  

-- Scott


Date:     25 August 1982 1357-pdt
From:     Earl A. Killian            <Killian at MIT-MULTICS>
Subject:  SET vs. SETF
To:       Common-Lisp at SU-AI

    Date: 25 August 1982 15:31-EDT
    From: Alan Bawden <ALAN at MIT-MC>

    Changing SETF to SET at this point seems like the height of gratuity.  If we
    are going to get involved in general name changes like this I can generate a
    list of about 100 (reasonable) name changes that can keep us busy for months
    arguing about their various merits.

Back when the number of objectionable names (to me) in the language was
around 100, I was reluctant to suggest changes (though I have certainly
been guilty of it several times).  I have been pleasantly surprized to
find that most of those names have been fixed in some way or another
(there were 35 or so renamings at the last meeting alone!), to the point
where only nconc (nappend), nreconc (nrevappend), and [f]makunbound
(make-unbound?) really seem objectionable to me.  I decided to suggest
changing SETF now because, 1) SET was no longer around, 2) SETF is going
to be very common (more than it is now) and a shorter, easier to
pronounce name would be nice for writing new code (no reason to go back
and changes all the existing SETF's since there can be a simple synonym),
and 3) Common Lisp is already making a lot of changes in this general
area (e.g. eliminating aset, vset, setplist, etc. etc.).


Date:     25 August 1982 1321-pdt
From:     Earl A. Killian            <Killian at MIT-MULTICS>
Subject:  set vs. setf
To:       Common-Lisp at SU-AI

    Date: 25 August 1982 04:41-EDT
    From: Robert W. Kerns <RWK at MIT-MC>

    Rather than trying to eliminate the letter 'F' from the language,
    why not consider that this letter 'F' helps clasify all these
    special forms as being related?  I always think of 'F' as standing
    for 'FORM', as in SET-FORM.

I don't think that this is necessary at all.  They are related merely in
that they store, which their names already imply.  Since the function
that stores without taking a "place" is an endangered species, there is
really no need for the "F".  But if you're serious about this, or just
believe in consistency, then I assume you must be in favor of appending
an "F" to PUSH, PUSHNEW, and POP (and whatever other functions I didn't
notice).  If you don't care about consistency, but don't want to change
the status quo much, then you should at least remove the "F" from
comparitively new functions such as SWAPF, EXCHF, INCF, DECF, etc.
having both PUSH and EXCHF as names seems just plain weird to me.

Moon's complaint is that removing the "F" doesn't work for GETF (there
are no other cases that I can find in the language -- REM has been
renamed REMAINDER, and so is not a problem).  Thus the problem is to
find a good name for the function that gets from a property list (as
opposed to a symbol) (I don't think eliminating the function is the
right way to deal with this either!).  So how about GETPR for this?
REMF would become REMPR for consistency, of course.


P.S. to GLS: the concept index should probably include "place" and cross
reference the functions that use it.


Date: Wednesday, 25 Aug 1982 12:37-PDT
cc: UCBKIM.jkf at UCB-C70, lseward at RAND-RELAY
Subject: case sensitivity
To: common-lisp at SU-AI
From: lseward at RAND-RELAY

I agree with Foderaro about case sensitivity, i.e. it should be allowed, but
come to a slightly different conclusion.  Given a case sensitive os, I would
like the following to happen.  If I say 'foo' and foo is a reference to a
lisp object, e.g. a function, I want it to match Foo, fOO or FoO. Id's should
not be sensitive to case. However if 'foo' is being passed to the os,
e.g. a file name, case translation should not occur.

Separating these two situation is non-trivial, and probably not completely
possibly.  If such a differentiated approach is not feasible then the user
should have 2 options:
  1) case sensitive or not
  2) if not case sensitive then a choice of folding to either upper or
     lower

Lower case definitely improves readability.  If it is not in the standard
then general acceptance will suffer.

larry seward


Date: 25 August 1982 15:31-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject:  SET vs. SETF
To: EAK at MIT-MC
cc: Common-Lisp at SU-AI

Changing SETF to SET at this point seems like the height of gratuity.  If we
are going to get involved in general name changes like this I can generate a
list of about 100 (reasonable) name changes that can keep us busy for months
arguing about their various merits.


Date: 25 Aug 1982 11:11:29-PDT
From: Kim.jkf at Berkeley
Mail-From: UCBKIM received by UCBVAX at 25-Aug-82 11:21:43-PDT (Wed)
Date: 25-Aug-82 11:20:43-PDT (Wed)
From: Kim:jkf (John Foderaro)
Subject: case sensitivity
Message-Id: <60852.16851.Kim@Berkeley>
Via: ucbkim.EtherNet (V3.147 [7/22/82]); 25-Aug-82 11:20:45-PDT (Wed)
Via: ucbvax.EtherNet (V3.147 [7/22/82]); 25-Aug-82 11:21:43-PDT (Wed)
To: common-lisp@su-ai

  I would like to bring up the issue of case sensitivity one last time.  The
lastest version of the Common Lisp manual states that unescaped characters
in symbols will be converted to upper case, and I saw no mention of any way
of turning off this case conversion 'feature'.   From past discussions, I
know that any effort to determine whether case sensitivity is good or bad is
futile.  Thus I would like to take a look at the problem in a different way
and convince you that Common Lisp must be able to be both case sensitive and
case insensitive if it is to be widely accepted and used.

    I believe that a person's feelings about case sensitivity in Lisp is a
function of the operating system he is most at home with.  If your operating
system is case insensitive (by that I mean that file names and most
utilities are case insensitive), then you prefer your Lisp to be case
insensitive.  Most (if not all) pdp-10 os's are case insensitive and since
much lisp work has been done on 10's, it is no surprise that most Lisps are
case insensitive.  Although I don't know everyone on the Common Lisp
committee, my guess is that most of them favor case insensitivity due to
their use of case insensitive Lisps on case insensitive operating systems.

    What about the future?  I'm sure you realize that Vax'es and personal
workstations are going to be everywhere, and that many of them will run Unix
or some descendant.  Unix is case sensitive and if you want Common Lisp to
fit in on a Unix system you have to take that into account.  The fact that
Common Lisp is case insensitive would make it uncomfortable for the Unix
programmer to use.  The fact that everything is converted to UPPER CASE
would make it even worse.  The first thing Unix people would do with Common
Lisp is to hack it to make it case sensitive and convert all the code to
lower case.

    In order to prevent divergence of Unix Common Lisp from other
implementations, I propose this change:

 1) there is a 'switch' which selects whether the reader is case sensitive
   or insensitive.

 2) when the reader is case insensitive, it converts everything to lower
   case.


 I've already mentioned why (1) is important.  The reason that (2) is
important is that it permits someone who has selected case sensitivity to
write 'car' and have it match the correct system function.  Without
everything converted to upper case, the case sensitive programmer would have
to write CAR.  [The first thing most people do around here when they get a
new terminal is to disable the caps-lock key, so typing lots of capital
letters would be a real burden].  The only people hurt by (2) are those case
sensitive systems which favor upper case.  I know of no such systems.

If you disagree with my proposal, please do no disagree for such irrelevant
reasons as:

  (a) your personal dislike for case sensitive systems.  There are people
      out in the world who prefer them and you must think of them.

  (b) your personal dislike for Unix.  It exists and many, many people use
      it.  It is probably the largest 'market' for Common Lisp so you should
      take it seriously.

You may disagree with converting everything to lower case because it will
have a visable affect on what you see on your terminal. Based on what I see
in the Common Lisp Manual and Lisp Machine Manual, I get the feeling that
some people feel that lower case is more readable than upper case.
If people really don't want to see lisp in lower case, then they would have
forced the manual writers to switch to upper case.



					John Foderaro
					



Date: Wednesday, 25 August 1982, 14:01-EDT
From: David A. Moon <Moon at SCRC-TENEX at MIT-MC>
Subject: Keyword arguments to LOAD
To: Common-Lisp at SU-AI

Here is a revised proposal:

Keyword		Default		Meaning

:PACKAGE	NIL		NIL means use file's native package, non-NIL
				is a package or name of package to load into.

:VERBOSE	*LOAD-VERBOSE*	T means print a message saying what file is
				being loaded into which package.

:PRINT-FORMS	NIL		T means print forms as they are evaluated.
				[Do we want this?  It disappeared from the
				latest Common Lisp manual.]

:ERROR		T		T means handle errors normally; NIL means that
				a file-not-found error should return NIL
				rather than signalling an error.  LOAD returns
				the pathname (or truename??) of the file it
				loaded otherwise.

:SET-DEFAULT-PATHNAME	*LOAD-SET-DEFAULT-PATHNAME*
				T means update the pathname default
				for LOAD from the argument, NIL means don't.

:STREAM		NIL		Non-NIL means this is an open stream to be
				loaded from.  (In the Lisp machine, the
				:CHARACTERS message to the stream is used to
				determine whether it contains text or binary.)
				The pathname argument is presumed to be associated
				with the stream, in systems where that information
				is needed.

The global variables' default values are implementation dependent, according
to local conventions, and may be set by particular users according to their
personal taste.

I left out keywords to allow using a different set of defaults from the normal
one and to allow explicit control over whether a text file or a binary file
is being loaded, since these don't really seem necessary.  If we put them in,
the consistent names would be :DEFAULT-PATHNAME, :CHARACTERS, and :BINARY.


Date: Wednesday, 25 August 1982, 12:53-EDT
From: David A. Moon <Moon at SCRC-TENEX at MIT-MC>
Subject: SET vs. SETF
To: FEINBERG at CMU-20C
Cc: Common-Lisp at SU-AI, EAK at MIT-MC, Kent M. Pitman <KMP at MIT-MC>
In-reply-to: The message of 24 Aug 82 16:10-EDT from FEINBERG at CMU-20C

    Date: 24 August 1982  16:10-EDT (Tuesday)
    From: FEINBERG at CMU-20C

	    Sorry, I slipped.  Anyway REMF, PUTF and GETF could be flushed
    in favor of allowing lists to be passed to GETPR, PUTPR and REMPR.  
Read your manual more carefully.

									I
    agree with EAK that we should call SETF SET.
This is not acceptable to me, for reasons given in my previous message.


Date: 25 August 1982 04:41-EDT
From: Robert W. Kerns <RWK at MIT-MC>
Subject: SETF and friends
To: common-lisp at SU-AI

Rather than trying to eliminate the letter 'F' from the language,
why not consider that this letter 'F' helps clasify all these
special forms as being related?  I always think of 'F' as standing
for 'FORM', as in SET-FORM.  Now, admittedly, 'F' isn't very
obvious, various other sundry functions happen to end in 'F', but
deleting the 'F' seems to be a step in the wrong direction.  If
you have to have change, why not go to SET-FORM rather than
SET?  But personally I'd rather not make this kind of change at
all.


Date: 24 August 1982 20:53-EDT
From: Earl A. Killian <EAK at MIT-MC>
Subject: assert
To: common-lisp at SU-AI

How about defining
	(ASSERT test)
to be a form that asserts that test is true.  The compiler can

1) compile code to check this
2) depend on it
3) ignore it
4) verify it at compile time (ha ha)


Date: 24 August 1982 17:31-EDT
From: Earl A. Killian <EAK at MIT-MC>
Subject: point 122
To: common-lisp at SU-AI

Another possibility, instead of using MEMBER or ONEOF, is to
allow (QUOTE <A>) to be a legal type specifier that means exactly
the object <A>.  Exasmple 1: (MEMBER A B C) would be (OR 'A 'B 'C).
Example 2: type LIST could be defined as (OR CONS '()).


Date: Tuesday, 24 August 1982  17:32-EDT
From: Scott E. Fahlman <Fahlman at Cmu-20c>
To: David A. Moon <Moon at SCRC-TENEX at MIT-MC>
Cc: common-lisp at SU-AI, STEELE at CMU-20C
Subject: Issue #106


My notes show CONCATENATE as the winner.  I prefer that to CATENATE,
though with very low weight on the whole issue.


Date: 24 August 1982  16:10-EDT (Tuesday)
From: FEINBERG at CMU-20C
To: David A. Moon <Moon at SCRC-TENEX at MIT-MC>
Cc: Common-Lisp at SU-AI, EAK at MIT-MC,  Kent M. Pitman <KMP at MIT-MC>
Subject: SET vs. SETF

Howdy!
	Sorry, I slipped.  Anyway REMF, PUTF and GETF could be flushed
in favor of allowing lists to be passed to GETPR, PUTPR and REMPR.  I
agree with EAK that we should call SETF SET.


Date: 24 August 1982  16:04-EDT (Tuesday)
From: FEINBERG at CMU-20C
To: David A. Moon <Moon at SCRC-TENEX at MIT-MC>
Cc: Common-Lisp at SU-AI, EAK at MIT-MC,  Kent M. Pitman <KMP at MIT-MC>
Subject: SET vs. SETF

Howdy!

    Date: Tuesday, 24 August 1982, 03:29-EDT
    From: David A. Moon <Moon at SCRC-TENEX at MIT-MC>
    To:   Kent M. Pitman <KMP at MIT-MC>, EAK at MIT-MC
    cc:   Common-Lisp at SU-AI
    Re:   SET vs. SETF

    Renaming SETF to SET would be a bad idea, because there is a whole
    family of xxxF functions.  Some of them are modified versions of
    functions without the F, so you can't just take the F off of all
    of them.

Looking over my copy of the Colander Edition I find the following xxxF
functions:

SWAPF, EXCHF       -- These are being removed from the language.  Better
		      names are being found.

INCF, DECF	   -- These can be changed to INC and DEC with no name
		      conflict.

PUTF, GETF, REMF   -- These functions seem useless to me.  Why not
		      just 
    Back in about 1973 when SETF was part of DEFSTRUCT, its name meant
    "set field".  It doesn't exactly mean that any more, of course.


Date: 24 August 1982  15:32-EDT (Tuesday)
From: FEINBERG at CMU-20C
To: Jonathan Rees <Rees at YALE>
Cc: Common-Lisp at SU-AI, Hedrick at RUTGERS
Subject: Non-local GO's

Howdy!
	I think the Common Lisp programmer could easily live with just
a local GO, and CATCH and THROW.  I see no justification for non-local
GOs at all.  It would seem to me that we would want to discourage the
use of GO in favor of more understandable looping constructs instead
of giving it the  capability to make truly unreadable programs.
Some claim that PROG and GO are sometimes the clearest way to express
a loop, perhaps this is so.  However, I have never seen a piece of
code that would be much clearer by using non-local GOs than some other
control construct.


Date: 24 Aug 1982 1508-EDT
From: HEDRICK at RUTGERS (Mgr DEC-20s/Dir LCSR Comp Facility)
Subject: Re: Non-local GO's
To: Rees at YALE
cc: Common-Lisp at SU-AI
In-Reply-To: Your message of 24-Aug-82 1423-EDT

My understanding is that they were referring to a dynamic GO.  It
sounds like you are talking about a static one.  If you want to
GO into a lexically enclosing PROG, I have no problem with that at
all (indeed I agree tht it is a good idea).  I read the proposal
as meaning that one could GO to any label in any currently active
PROG.
-------


Date: Tuesday, 24 August 1982  13:59-EDT
From: Jonathan Rees <Rees at YALE>
To: Hedrick at RUTGERS
Cc: Common-Lisp at SU-AI
Subject: Non-local GO's

I think that non-local GO's can be implemented at no cost to
non-users, given an appropriate compilation strategy.

Yale's Scheme implementation (also known as T) supports a lexical
catch/throw almost identical to Common Lisp's BLOCK/RETURN-FROM
facility.  The compiler translates lexical throws into direct jumps
(with possible stack adjustment) where this is possible, and uses a more
general CATCH/THROW mechanism where necessary.  I believe that
determining which compilation strategy to use for PROG is the same
problem as that for BLOCK.

If you believe that non-local GO's should be abolished, then you should
also argue against general BLOCK/RETURN-FROM, which I believe will be used
as much if not more than PROG/GO, and so should also allow "efficient"
compilation strategy where its full generality isn't used.

This is perhaps not the place to go into the details of how our compiler
works.  Suffice it to say it can be done (on conventional machines), and
is not particularly hairy.  The key point is that the scope of the GO
tags is lexical, so one can find all the GO's belonging to a particular
PROG.  If no such GO's are from within "uncontrolled" closures then
the compiler needn't use the completely general strategy.

Please let me know if I've misunderstood something about the Common Lisp
spec.


Date: Tuesday, 24 August 1982  13:59-EDT
From: Jonathan Rees <Rees at YALE>
To: Hedrick at RUTGERS
Cc: Common-Lisp at SU-AI
Subject: Non-local GO's

I think that non-local GO's can be implemented at no cost to
non-users, given an appropriate compilation strategy.

Yale's Scheme implementation (also known as T) supports a lexical
catch/throw almost identical to Common Lisp's BLOCK/RETURN-FROM
facility.  The compiler translates lexical throws into direct jumps
(with possible stack adjustment) where this is possible, and uses a more
general CATCH/THROW mechanism where necessary.  I believe that
determining which compilation strategy to use for PROG is the same
problem as that for BLOCK.

If you believe that non-local GO's should be abolished, then you should
also argue against general BLOCK/RETURN-FROM, which I believe will be used
as much if not more than PROG/GO, and so should also allow "efficient"
compilation strategy where its full generality isn't used.

This is perhaps not the place to go into the details of how our compiler
works.  Suffice it to say it can be done (on conventional machines), and
is not particularly hairy.  The key point is that the scope of the GO
tags is lexical, so one can find all the GO's belonging to a particular
PROG.  If no such GO's are from within "uncontrolled" closures then
the compiler needn't use the completely general strategy.

Please let me know if I've misunderstood something about the Common Lisp
spec.


Date: 24 Aug 1982 1321-EDT
From: HEDRICK at RUTGERS (Mgr DEC-20s/Dir LCSR Comp Facility)
Subject: a protest
To: common-lisp at SU-AI

I would like to protest the decision to allow non-local GO's.  We are
doing our best to make a Common Lisp implementation on the 20 that will
produce code comparable in efficiency to Maclisp.  We are trying to
come up with ways to implement all of the hairy constructs that 
penalize only people who use them.  We have found a way to do this for
multiple values, optional arguments, &REST, etc.  I do not see any way
to implement non-local GO's without effectively turning every PROG
into a CATCH.  I realize that microcoded implementations will have
frames around for everything, and thus that they will have no problem.
But I believe that non-local GO's are not reasonable on conventional
machines.  I thought one constraint on the language design was that it
should not have features that would require conventional implementations
to put in things such as stack frames.  I believe that CATCH and THROW
should accomplish what is intended by a non-local GO, and that it is
more in the spirit of existing Lisp's to do that.  I would also be
willing to settle for a separate kind of PROG that allows that feature.
(If necessary, we will implement it that way, and provide a way to
set things so that this CATCH-PROG is used in place of the normal
PROG for users who really need to do non-local GO's.)

Also, I did not see any decision on closures.  We feel very strongly
that lexical closures are enough, and that the general CLOSE-OVER is
unnecessary.  I believe that I have a way to implement a general
CLOSE-OVER without causing overhead to non-users, but it is so hideous
that no sane person would want to do it.
-------


Date: Tuesday, 24 August 1982, 13:03-EDT
From: Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC>
Subject: Results
To: common-lisp at su-ai

I painstakingly checked your "Results" with my notes; they are nearly
identical.  Here are some comments.

It looks like the concept of "local scope" is no longer used by Common Lisp.
If so, it should be removed from the manual.

On point 38, we did not agree to define (LET (B) ...) to make B unbound;
at least, I didn't hear about it if we did.

On point 110, you forgot to mention explicitly that EQL is the default
for all these functions.

Other than that it looks great.  I've started typing in the new
error system documentation and will send it out as soon as I
can.


Date: Tuesday, 24 August 1982, 11:58-EDT
From: Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC>
Subject: typep
To: EAK at MIT-MC, common-lisp at SU-AI
In-reply-to: The message of 23 Aug 82 20:43-EDT from Earl A. Killian <EAK at MIT-MC>

I don't think these arguments are strong enough to justify making an
incompatible change in the order of the arguments.  As I discussed at
the meeting, there is still an important criterion of "brain
compatibility" that affects whether a change should be made or not; I
don't want to have to relearn this and change all my code for such weak
reasons.


Date: Tuesday, 24 August 1982, 03:40-EDT
From: David A. Moon <Moon at SCRC-TENEX at MIT-MC>
Subject: lowercase in print
To: Earl A. Killian <EAK at MIT-MC>
Cc: Common-Lisp at SU-AI
In-reply-to: The message of 23 Aug 82 20:06-EDT from Earl A. Killian <EAK at MIT-MC>

    Date: 23 August 1982 20:06-EDT
    From: Earl A. Killian <EAK at MIT-MC>

    How about the exponent specifier too, as in 1e6 instead of 1E6?  It makes it
    clear to the user that it isn't a symbol since the language uppercases
    symbols.
You are absolutely right.


Date: Tuesday, 24 August 1982, 03:29-EDT
From: David A. Moon <Moon at SCRC-TENEX at MIT-MC>
Subject: SET vs. SETF
To: Kent M. Pitman <KMP at MIT-MC>, EAK at MIT-MC
Cc: Common-Lisp at SU-AI
In-reply-to: The message of 24 Aug 82 00:33-EDT from Kent M. Pitman <KMP at MIT-MC>

Renaming SETF to SET would be a bad idea, because there is a whole
family of xxxF functions.  Some of them are modified versions of
functions without the F, so you can't just take the F off of all
of them.

Back in about 1973 when SETF was part of DEFSTRUCT, its name meant
"set field".  It doesn't exactly mean that any more, of course.



****  See more in MC:NIL;CL OSTUF*  ****