perm filename MSG.MSG[FTL,LSP] blob sn#826887 filedate 1986-10-27 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00122 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00011 00002
C00012 00003	∂03-Dec-84  0800	JK
C00013 00004	∂18-Dec-84  1142	SCHERLIS@CMU-CS-C.ARPA 	kermit for Perq
C00014 00005	What to do next ----
C00016 00006	∂16-Jan-85  1453	GOTELLI@SU-SCORE.ARPA 	Lucid users
C00017 00007	∂17-Jan-85  1226	@MIT-MC:BROOKS@MIT-OZ
C00019 00008	∂20-Jan-85  2011	SCHERLIS@CMU-CS-C.ARPA 	reader testing
C00023 00009	∂26-Jan-85  1535	JK
C00025 00010	∂30-Jan-85  1507	FTL   	Reader files delivered
C00028 00011	Bill---
C00032 00012	How is the compiler doing?
C00035 00013	∂02-Feb-85  0836	JK
C00036 00014	∂02-Feb-85  1149	@MIT-MC:BROOKS@MIT-OZ
C00039 00015	∂02-Feb-85  1206	@MIT-MC:BROOKS@MIT-OZ
C00040 00016	Bill ---
C00045 00017	∂04-Feb-85  0832	JK   	compiler status
C00048 00018
C00050 00019	∂08-Feb-85  0841	@MIT-MC:BROOKS@MIT-OZ 	End march trip
C00051 00020	∂08-Feb-85  2231	ROD  	for EB
C00055 00021	∂10-Feb-85  0825	ROD  	losing let value bug
C00057 00022	∂10-Feb-85  2151	ROD  	compiler status
C00065 00023	∂11-Feb-85  1816	ROD  	(if (progn... bug
C00066 00024	∂10-Feb-85  1302	JK   	New reader
C00078 00025	∂12-Feb-85  2128	@MIT-MC:BROOKS@MIT-OZ 	Re: compiler and macros
C00080 00026	∂13-Feb-85  2030	@MIT-MC:BROOKS@MIT-OZ 	defmacro in the same file bug.
C00085 00027	∂15-Feb-85  0814	JK   	Re: jobs
C00087 00028	Rod ---
C00090 00029	∂17-Feb-85  0425	@MIT-MC:BROOKS@MIT-OZ
C00092 00030	Rod ----
C00093 00031	Bill ---
C00094 00032	∂17-Feb-85  2113	ROD  	adjust-stack bug
C00095 00033	∂18-Feb-85  0823	JK   	tape
C00098 00034	∂18-Feb-85  2133	EB
C00100 00035	∂18-Feb-85  2031	SCHERLIS@CMU-CS-C.ARPA 	travel
C00103 00036	∂19-Feb-85  0853	JK
C00105 00037	∂20-Feb-85  0739	JK   	tape
C00107 00038	∂20-Feb-85  0757	SCHERLIS@CMU-CS-C.ARPA 	Re: travel
C00109 00039	∂21-Feb-85  0733	JK   	["Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>: Kyoto Common Lisp]
C00114 00040	∂22-Feb-85  1819	JK   	trip to Lucid
C00116 00041	∂26-Feb-85  1027	FTL
C00117 00042	∂26-Feb-85  2015	@MIT-MC:BROOKS@MIT-OZ
C00119 00043	∂02-Mar-85  1754	JK   	Reader
C00121 00044	∂03-Mar-85  0936	JK   	compiler
C00122 00045	∂04-Mar-85  1107	JK   	status, hint and query.
C00126 00046	How's closures? RPG tells me he told you all that you ever need to
C00127 00047	∂06-Mar-85  1915	@MIT-MC:BROOKS@MIT-OZ
C00131 00048	∂10-Mar-85  0755	JK
C00133 00049	∂11-Mar-85  0841	JK   	68020
C00135 00050	∂11-Mar-85  0843	JK   	tape
C00138 00051	∂13-Mar-85  0758	JK   	status
C00141 00052	∂18-Mar-85  0716	JK   	tape
C00146 00053	∂23-Mar-85  1144	JK
C00148 00054	∂26-Mar-85  0843	JK   	For your info...
C00151 00055	∂02-Apr-85  0800	JK   	flavor ?s
C00155 00056	∂02-Apr-85  0801	JK   	this is a test
C00157 00057	∂03-Apr-85  2026	JK
C00159 00058	∂08-Apr-85  0822	JK   	tape
C00161 00059	∂12-Apr-85  0743	JK   	Announcement
C00163 00060	∂15-Apr-85  0721	JK
C00164 00061	∂16-Apr-85  0844	JK   	misc questions
C00167 00062	∂22-Apr-85  0749	JK
C00169 00063	∂23-Apr-85  0810	JK   	closures
C00171 00064	∂23-Apr-85  0811	JK
C00172 00065	∂23-Apr-85  1938	JK
C00174 00066	∂24-Apr-85  0743	JK
C00175 00067	∂26-Apr-85  0738	JK   	370 common lisp
C00177 00068	∂29-Apr-85  0759	JK
C00178 00069	∂29-Apr-85  0759	JK
C00181 00070	∂29-Apr-85  0801	JK
C00183 00071	∂29-Apr-85  0801	JK   	Re: Well
C00185 00072	∂29-Apr-85  0803	JK
C00188 00073	∂30-Apr-85  0818	JK
C00190 00074	∂30-Apr-85  1646	JK
C00191 00075	∂30-Apr-85  1653	JK   	Lucid and LISP programming
C00193 00076	∂30-Apr-85  1654	JK   	Lucid & Lisp
C00201 00077	∂30-Apr-85  1659	JK   	Lucid & Lisp
C00203 00078	∂01-May-85  0754	JK   	Re: analyze-primop
C00205 00079	∂03-May-85  0831	JK   	370 CL
C00209 00080	∂03-May-85  0831	JK   	gold hill
C00210 00081	∂03-May-85  0832	JK   	generic arithmetic
C00215 00082	∂03-May-85  0833	JK   	More arithmetic
C00220 00083	∂03-May-85  0835	JK   	GCs
C00222 00084	∂06-May-85  1028	JK   	tape
C00225 00085	∂06-May-85  1032	JK   	Re: some to be done's
C00227 00086	∂06-May-85  1033	JK
C00228 00087	∂06-May-85  1040	JK   	Re: some to be done's
C00231 00088	∂06-May-85  1040	JK   	CL bogosity
C00237 00089	∂07-May-85  1437	JK
C00238 00090	∂07-May-85  1438	JK
C00241 00091	∂07-May-85  1900	JK
C00242 00092	∂07-May-85  1900	JK   	trip
C00243 00093	∂07-May-85  2002	JK   	Re: compiler bug
C00245 00094	∂08-May-85  0749	JK   	Re: compiler bugs
C00247 00095	∂09-May-85  0656	JK   	[Guy Steele <gls%AQUINAS@THINK.ARPA>: Macros -> declarations]
C00251 00096	∂16-May-86  0807	JK   	olin shivers
C00256 00097	∂23-May-85  1612	JK
C00258 00098	∂23-May-85  1613	JK
C00259 00099	∂23-May-85  1619	JK  	compiler
C00260 00100	∂07-Jun-85  1515	JK   	summer jobs
C00271 00101	∂11-Jun-85  1758	JK
C00273 00102	∂13-Jun-85  0746	JK
C00276 00103	∂13-Jun-85  0750	JK   	declaration pervasiveness.
C00281 00104	∂13-Jun-85  0751	JK
C00282 00105	∂17-Jun-85  0807	JK
C00284 00106	∂21-Jun-85  0951	JK  	tape
C00286 00107	∂23-Jun-85  0912	JK
C00288 00108	∂27-Jun-85  0802	JK
C00291 00109	∂30-Jun-85  0940	JK
C00294 00110	∂07-Jul-85  1232	JK
C00296 00111	∂15-Jul-85  0746	JK   	flavors
C00301 00112	∂16-Jul-85  1303	F.DUFFIE@SU-GSB-WHY.ARPA 	Re: TeX index macros
C00303 00113	∂17-Jul-85  1639	F.DUFFIE@SU-GSB-WHY.ARPA 	TeXmacros to Virginia Kean
C00308 00114	∂17-Jul-85  1754	F.DUFFIE@SU-GSB-WHY.ARPA 	Re: index macros
C00309 00115	∂25-Jul-85  0849	F.DUFFIE@SU-GSB-WHY.ARPA 	doublecolumns macro
C00312 00116	∂25-Jul-85  0851	F.DUFFIE@SU-GSB-WHY.ARPA 	the files
C00321 00117	∂26-Jul-85  1025	F.DUFFIE@SU-GSB-WHY.ARPA 	Re: index
C00323 00118	∂26-Jul-85  1111	SCHERLIS@CMU-CS-C.ARPA 	Re: Lucid manual
C00325 00119	∂02-Aug-85  0702	SCHERLIS@CMU-CS-C.ARPA 	documentation notes
C00326 00120	∂03-Aug-85  1538	SCHERLIS@CMU-CS-C.ARPA 	First installment of COMMENTS
C00342 00121	∂07-Aug-85  0848	F.DUFFIE@SU-GSB-WHY.ARPA 	Fonts to Virginia Kean
C00350 00122	∂24-Oct-86  1619	edsel!bhopal!lgd@navajo.stanford.edu 	concepts.tex
C00389 ENDMK
C⊗;

∂03-Dec-84  0800	JK
∂02-Dec-84  2004	ROD  	lap spec
To:   EJG, JK
New RODIMP.TXT[1,FTL] has the LAP specification chapter included.

∂18-Dec-84  1142	SCHERLIS@CMU-CS-C.ARPA 	kermit for Perq
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 18 Dec 84  11:41:48 PST
Received: ID <SCHERLIS@CMU-CS-C.ARPA>; Tue 18 Dec 84 14:42:17-EST
Date: Tue 18 Dec 84 14:42:16-EST
From: Bill.Scherlis@CMU-CS-C.ARPA
Subject: kermit for Perq
To: ftl@SU-AI.ARPA

I don't know if there is interest, but here is how to get Kermit for
the Perq:  FTP (user anonymous) from CU20B (Columbia) the files
KER:PQ*.PAS
The Kermit "coordinator" there is SY.FDC@CU20B
Bill
-------

What to do next ----
Discussed the issue this morning with RPG, EJG and EB.
It seems that the prioritized list of tasks for you to do are:

Ongoing: Bugfixes and maintenance of the compiler.

(1) Fixing correct handling of tail recursion with an intervening let.
(2) Handling of lambda keywords.
(3) Extended functionality. Closures, multiple value handling etc.
(4) Correctness: Writing enough test cases to ensure that each part of the
code has been exercised. The test cases should be runnable
automatically so as to ensure easy re-testing.
Our current policy is to add a test case every time
we see a bug. There are directories like bug-report and test
under the current compiler.
(5) Performance tuning.

JK
∂16-Jan-85  1453	GOTELLI@SU-SCORE.ARPA 	Lucid users
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 16 Jan 85  14:53:10 PST
Date: Wed 16 Jan 85 14:49:53-PST
From: Lynn Gotelli <GOTELLI@SU-SCORE.ARPA>
Subject: Lucid users
To: FTL@SU-AI.ARPA
cc: ME@SU-AI.ARPA, gotelli@SU-SCORE.ARPA

Dick, Marty has asked me to charge <EB> Eric Benson and
<JLW> Jon White to Lucid. I have made these changes effective
1/1/85.
Lynn
-------

∂17-Jan-85  1226	@MIT-MC:BROOKS@MIT-OZ
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 17 Jan 85  12:26:15 PST
Date: Thu 17 Jan 85 15:19:05-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
To: FTL@SU-AI.ARPA
In-Reply-To: Message from "Lucid <FTL@SU-AI.ARPA>" of Tue 15 Jan 85 11:18:00-EST

Can you give me some feedback on the following:

(defun foo (a b) (print a) (bar b a)) can re-use the current frame
of foo for bar. (If bar were foo then we'd say this was tail recursion.)
If its a straightforward extension of correct tail recursion analysis
(which I'm sure it is) then should I make the compiler do this? The
disadvantage is in debugging an intervening frame has disappeared,
but it saves a lot of useless stack unwinding.

Rod
-------

Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Jan 85  20:10:59 PST
Received: ID <SCHERLIS@CMU-CS-C.ARPA>; Sun 20 Jan 85 23:03:34-EST
Date: Sun 20 Jan 85 23:03:32-EST
From: Bill.Scherlis@CMU-CS-C.ARPA
To: jk@SU-AI.ARPA

Jussi --
I am about to start testing some parts of the reader, but I
need some code from you guys.  Eric Benson, I think, has a definition
somewhere of a SELECT macro that works just like case except it
attempts expansion-time evaluation of the case branch tests.  Thus,
if I have
(defconstant foo 1)
(defconstant bar 2)
(defconstant quux 3)
I could write something like
(select mumble
(foo  ...)
((bar quux)  ...)
(t  ...))
and it will expand into something reasonable.  (The CL case will not
allow this kind of use of constants.)
Of course, if nobody has a definition I could write one, but
it would be more sensible for us to standardize the few auxiliary
macros we use.

By the way, the tokenizer needs fast versions of the following
functions:
upcase-char	(a fast version that assumes a char is given)
In all cases, I do EOF testing by calling

I hope all is well with the Lucid folks.
Bill
-------

Can you send your code and spec to ftl asap? We would like to review it.
As for testing, as much of it as possible should be in runnable
automatically: We have special forms test and etest that do the
following:
(test <form> <name -- this is a string>)
does nothing if forms evaluates to t. Otherwise; if an error occurs or
form evaluates to nil, it prints a message to *error-output* mentioning
that the test with the given name failed.
(etest <form> <name>)
does the precisely the reverse --- it complains if no error occurred.
I have asked benson to send you the select macro.
∂26-Jan-85  1535	JK
∂26-Jan-85  1324	ROD  	keywords
To:   RPG, JK
Well, I'm still hacking on getting keywords all done right. There's
an awful lot of code to get all the cases optimal--e.g. alpha is

There's a lot of weird checking that could be done at runtime
because of &allow-other-keys and :allow-other-keys. I'm doing all the
checking possible at compile time on that stuff, but sometimes
you just can't tell until runtime. Rather than slow down the
runtime I'm leaving out that error checking--that falls within the
Common Lisp definition, because the manual just says it is an error''.
However I want to check with you guys that runtime speed over runtime error
checks is the correct policy--I believe it will be a significant
slowdown for almost never errors the other way. The interpreter should
do all the checking however.

(I knew leaving keywords out of TAIL was a good idea....)
--------------
Rod ---- I have written and debugged a lambda list parser that returns
a horrid data structure handling all the wierd cases: May be that might
help --- I will send it to you monday.
JK

∂30-Jan-85  1507	FTL   	Reader files delivered
∂29-Jan-85  2139	SCHERLIS@CMU-CS-C.ARPA 	Reader files delivered
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 29 Jan 85  21:38:56 PST
Received: ID <SCHERLIS@CMU-CS-C.ARPA>; Wed 30 Jan 85 00:40:18-EST
Date: Wed 30 Jan 85 00:40:13-EST
From: Bill.Scherlis@CMU-CS-C.ARPA
To: jk@SU-AI.ARPA

Jussi --
There are now a bunch of READER files in [1,ftl].  Here is
the list (totaling about 80 pages):

RSPEC.TXT	The specification document.  (33pp)
RINIT.LSP	A small file to load the reader stuff (for Perqs).  (1p)
RDECL.LSP	Declarations and DEFCONSTANTs.  (5pp)
R.LSP		The main reader body (only an init routine right now).  (3pp)
R3.LSP		Character classification.  (3pp)
R4.LSP		The moby FSM.  (21pp)
R5.LSP		Dummy object constructors.  (1p)
RTEST.LSP	A function to help test read-token.  (1p)

Notes:

(0) This includes the buffering, readtable management, character
the reader, but is without question the most difficult part of the code.
The really hairy part -- READ-TOKEN -- is done and survives my random
testing.  See RSPEC for details concerning what's there and what's
not.  Don't try to read the FSM without having a go first at RPSEC!
(I also use Eric Benson's SELECT, which I didn't send.)
Bill---
Thanks for the files --- I have made a preliminary pass thru it; looks
good. I expect to get the other stuff you mentioned below in the
time schedule you mentioned:
------
-- real object constructors (integer, flonum, rational, symbol)
-- reader tails (for lists, quote, etc.)
-- sharpm.
-- backq.
I'll have the first three of these in a week -- they're all quite
simple.  Backq will then follow, with Sharpm coming last.
------
All in all, I would like everything done by the time you get here so that
you can start running it through the compiler. So far as I know, you will
be here in the middle of february.
I will read the stuff more thoroughly over the weekend . I will probably

(2) A formal test set will arrive shortly.  How do you trap errors for
etest?  Also, could you send me exact syntax for the test forms....
******
We have a with-error-trapping primitive in our system.
In spice, it maps into errset.
Syntax: (test <form> <name-string>)
complains if form causes an error or returns nil
(etest <form> <name-string>)
complains if form causes no errors.

(4) I haven't yet tried to compile the thing yet.  Could you send me
some advice on Lucid conventions organizing declarations, etc...
Right now, they are all in a separate file, but separate compilation
isn't feasible due to the multitude of INLINE functions.
*******
Let's do this one when you get here.

and (alas) READER-INTERNAL-ERROR on R4.LSP/2P.  I will write better
messages when I see some standards.  (The "LUCID: " prefix is there
to distinguish my messages from Spice messages!)
*******
I doubt that we will ever have a error message standard ---- the variety
of error situations is enormous.
However, we have agreed that all error messages should be listed in the spec.
You should do this.

(By the way, could we create a sub directory of FTL for the purpose of
buffering files on the way to and from Lucid?  There are zillions
of files in [1,ftl] and it is easy to lose things.)
*******
I have deleted almost all of the files in ftl --- there is only 3 left.
How is the compiler doing?

We are currently finishing up on stage 2, which means that we have most of the
macro and error handling stuff done. Plus, Mcdonald has a very nice interrupt
handler and RPG is getting the GC to work.

We expect to do a lot of compiling the coming week --- if there is a new version
of the compiler, would appreciate getting it.

Next stage contains EVAL and redone LAP, among other things. We are currently
entertaining the proposal of really hacking our brains out and trying to
finish ahead of schedule. This way, we could control a larger share of the
company and really win big in the market place. It seems that a lot of the
stuff to be done in later stages has already been done in some form.

Which brings me back to the compiler: I sent you a list of goals that I am
including below.

Ongoing: Bugfixes and maintenance of the compiler.

(1) Fixing correct handling of tail recursion with an intervening let.
(2) Handling of lambda keywords.
(3) Extended functionality. Closures, multiple value handling etc.
(4) Correctness: Writing enough test cases to ensure that each part of the
code has been exercised. The test cases should be runnable
automatically so as to ensure easy re-testing.
Our current policy is to add a test case every time
we see a bug. There are directories like bug-report and test
under the current compiler.
(5) Performance tuning.

I would like to add another one: Nativizing the compiler to the Lucid
environment.

I would like to get a general idea what your schedule looks like vis-a-vis
these goals and possible visits to Lucid. I think it would be extremely
important to schedule significantly long visits to Lucid during the next
few months. Of course, Lucid would pay.

JK
∂02-Feb-85  0836	JK
∂02-Feb-85  0018	RPG  	GC progress
The low-level primitives seem to be pretty much under control - I got a
variant of the main loop of the GC to scan a segment and parse all of the
objects linearly, printing them out along with information about the
headers and all that. This tool, by the way, looks like it will be useful
for helping analyze memory usage. I saw all sorts of interesting layout
patterns when I scanned the static segment.
-rpg-

∂02-Feb-85  1149	@MIT-MC:BROOKS@MIT-OZ
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 2 Feb 85  11:49:24 PST
Date: Sat 2 Feb 85 14:52:06-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
To: FTL@SU-AI.ARPA
In-Reply-To: Message from "Lucid <FTL@SU-AI.ARPA>" of Sat 2 Feb 85 09:29:00-EST

I have completed (1) Fixing correct handling of tail recursion (it turned out
there were lots of other cases it dodn't do the right thing, like when
there are optional args--that's all fixed), and as a side effect I also
cleaned up the let optimizer and made it significantly better.
I am finishing (2) keywords today and tomorrow--it was much longer than
I expected. I will send you a tape Monday with about 1000 new lines of
code.

By nativizing the compiler, do you mean getting it to run in Lucille?

I could perhaps manage a week long visit at the end of March under the
following arrangement: I pay for my airfare out of research money--it
will be at the tail end of research related visits, while Lucid pays
for Nui's airfare--since it will include a Saturday night, and the
way the fare wars are going that would probably be quite cheap. We
would stay at chez RPG I presume.

I will start on closures the coming week (item (3) in your list).

Rod
-------

∂02-Feb-85  1206	@MIT-MC:BROOKS@MIT-OZ
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 2 Feb 85  12:06:26 PST
Date: Sat 2 Feb 85 15:08:56-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
To: FTL@SU-AI.ARPA
In-Reply-To: Message from "Lucid <FTL@SU-AI.ARPA>" of Sat 2 Feb 85 09:29:00-EST

That may be actually only 5 days I can be there in late March. I'll check
my calender on Monday and let you know for sure

From late may I will not have any teaching commitments and will be much
freer.
-------

Bill ---
Here are the error macros. They may be a little strange since our file
transfer mechanism to sail did not work out too well in this case and I had
to patch them up by hand.

looks good. I wrote my comments up; Jan will send them tomorrow.
I thought some more about the next job for you --- EB tells me that
the printer interacts in all kinds of interesting ways with the rest
of the system. If you are not going to be physically around Lucid that
much, it might be more advisable to do a more independent module, like
the rest of TYPES module (subtypep and coerce).
acquainted with the wonders of the Common Lisp type system.
JK

;;;; TEST -*- Mode:Lisp -*-

;;; ***************************************************************************
;;;
;;; (c) Copyright 1984 by Lucid, Inc.
;;;
;;; ***************************************************************************

(defmacro with-error-trapping (form)
(let ((,value ,form)) (values ,value t "" nil)))

(setq *inform* t)

;;; The test macro takes a form and a test name as a string.
;;; It prints an error message to *error-output* if an error
;;; is encountered or if the form returned nil.

(setq *inform* t)

(defmacro test (form test-name)
(let ((value (gensym))
(flag (gensym))
(message (gensym))
(funame (gensym)))
(errset
(progn
(when *inform* (format *query-io* "%running ~s" ,test-name))
(multiple-value-bind
(,value ,flag ,message ,funame)
(with-error-trapping ,form)
(cond ((null ,flag)
(format *error-output*
"~%error occurred during evaluation of ~S with message:~%~S~%"
,test-name
,message))
((null ,value)
(format *error-output*
"~%error occurred during evaluation of ~s: ~% the form ~s returned nil"
,test-name
,form)) )) )))))

;;; The etest macro takes a form and a test name as a string.

(defmacro etest (form test-name)
(let ((value (gensym))
(flag (gensym))
(message (gensym))
(funame (gensym)))
(progn
(and *inform* (format *query-io* "~%running ~s~%" ,test-name))
(multiple-value-bind
(,value ,flag ,message ,funame)
(with-error-trapping (errset ,form ,t))
(cond ( ,value
(format *error-output*
"~%no error occurred during evaluation of ~S~%,or it returned t --- gasp~%"
,test-name))
(t (when *inform* (format *query-io*
"successfully produced error: ~S~%"
,message))))))))
∂04-Feb-85  0832	JK   	compiler status
∂03-Feb-85  2200	@MIT-MC:BROOKS@MIT-OZ 	compiler status
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 3 Feb 85  21:59:47 PST
Date: Mon 4 Feb 85 00:53:25-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: compiler status
To: jk@SU-AI.ARPA, rpg@SU-AI.ARPA

I have been hacking the compiler constantly this weekend but didn't get
it to where I wanted it. I won't have a chance to hack on it again
until next Friday evening.

If you need it this week I can generate a tape tomorrow night so
you will receieve it Wednesday am. Let me know what you want.

Here is the current status:

tail recursion has been completely redone so it works with intervening
lets and anywhere else it ought to. also it now works when there
are &optional and &rest args around. it will currently break if
there are &key args--estimate 2 to 4 hours to fix.

let optimizations have been significantly improved.

keywords work in all cases in embedded lambdas.

keywords in a defun work only when neither &optional nor &rest are
present. those cases currently break through a combination
of compiler bugs and runtime fastcall routine bugs
--estimate 2 to 3 hours to fix, but I'm always optimisitic.

I have not yet put any supplied-p code in--I suspect it will
take a lot of hacking to get everything optimal. Is this
a high priority?

Rod
-------

Jan tells me you will be joining us in a few weeks!

I have tentatively scheduled you to start hacking on the APOLLO
project with Dick; I am imagining Dick doing the coldload and gc
and you handling IO and interrupts. I would like it if you could
take this project on as a project leader; that is, be responsible
for co-ordinating, overseeing and scheduling the effort. And keep
in touch with the APOLLO technical folks.

Another thing: Would it be possible for you to get hold of a public
domain EMACS for the APOLLO from Yale? I am told such a thing exists.

JK

∂08-Feb-85  0841	@MIT-MC:BROOKS@MIT-OZ 	End march trip
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 8 Feb 85  08:39:00 PST
Date: Fri 8 Feb 85 09:10:51-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: End march trip
To: ftl@SU-AI.ARPA

Jussi,
Further to my note last wekeend. I could arrive in Palo Alto about 3pm Thursday
March 28 and leave the evening of Tuesday April 2nd.
Rod
-------

∂08-Feb-85  2231	ROD  	for EB
Well its one of those cases of how did this code ever work?''.
My test cases were not too adequate in retrospect.

Here are the minimal changes to make it correct semantically.
In my next tape I'll have a much cleaned up version which
achieves the same result but less screwily. Also I'll handle
the setq's better. If you look at the code generated for your
example now you'll see it is quite horrid. The setq stuff will
clean it up a lot, but it also has made me realize
that now that the alpha phase uniquifies  names I can be
musch more aggressive in the if optimizer doing things like
(if (let (...) <body>) <then> <else>)
==>
(let (...) (if <body> <then> <else>))
This was not possible before because of shadowing possibilities.
Anyway I'll include such an aggressive if optimizer (in
your example case it would get rid of most of the horridness
by itself just leaving an instruction or two for the let-setq
handler (or primop reshaper, which is where that case will get taken
care of)).

Here are the changes:
In analyze-optimize-let:

1.  (if (and (memq vnode readers)
(null (rest (%variable-refs vnode))))
(mul...

==> (if (and (memq vnode readers)
(null (rest (%variable-refs vnode)))
(or (eq bind-type 'procall)
(eq bind-type 'primop)))
(mul...

2. (cond ((and (cond ((eq place-type 'primop)
(if place-fastp
...))
(t 't)

==>(cond ((and (cond ((eq place-type 'primop)
(and (eq bind-type 'primop)
(if place-fastp
...)))
(t 't)

In analyze-extract-reference the (eq type 'primop) clause of the  big
cond becomes:

((eq type 'primop)
(multiple-value-bind (place passers)
(analyze-extract-ref-seq refcell
(%primop-args internal)
anode)
(if (and place
(memq (first refcell) (first (%anode-source anode))))
(values anode passers)
(values place passers))))

Rod

EJG - shipping and installing this bugfix - Sat 850209
∂10-Feb-85  0825	ROD  	losing let value bug
To:   RPG
CC:   FTL
This was a side effect of fixing tail recursion... the bug was
also in multiple-value-bind and block. Here's the fix:

Right at the end of analyze.lisp at the end of the definition of
label-destinations it says:

(push ret collect)))))
(setf (%anode-returns node) collect)
collect))

<eof>

should have a line of code added to make it:

(push ret collect)))))
(setf (%anode-wantloc node) wantloc)
(setf (%anode-returns node) collect)
collect))

<eof>

EB: Added this fix to analyze.lisp 850210 1315
∂10-Feb-85  2151	ROD  	compiler status
To:   RPG, FTL
The compiler now:

Handles all cases of &rest, &optional, &key and &aux in any combination in
defuns and embedded lambdas.

Handles supplied-p parameters in &key in defuns and in &optional in embeedded
lambdas, but not the other way around (I did the easy cases first...).

Generates better code for (if (let ...)...) than it did before.

Has the bug fixes that I've sent the last few days.

Immediate plans are:

Do the other two cases of supplied-p parameters (maybe tomorrow night).

Make tail recursion work on cases besides fixed args, &optional and &rest.

Get on to closures.

When all but the last item is done the only things missing from the handling
of lambda lists will be the cases where the variables are declared special.
(Note that specials already work in embedded lambdas--we're only talking
about special parameters to functions here.)
The optimal code for all the possible combinations will require a lot of
compiler code to generate (my stomach turns at the thought of a special
supplied-p parameter for an optional, which must be specially bound
before the next default value gets computed!). I think it should be low
priority as no one in Lucid ought to write code which uses such a brain
damaged feature--I also suspect it would be a year or two before you got a
bug report if we left out the hairier cases, but on the other hand I bet
we could make a test suite to break any other CL implementation...

Get on to closures.
Another thing not mentioned in Jussi's list, which probably should be done
reasonably soon (maybe after all multiple value stuff is fixed) is handling
special declarations.

I can send a tape any time of you want the current version or you can
wait a week or so to get a better one.

∂11-Feb-85  1816	ROD  	(if (progn... bug
To:   RPG, FTL
I was trying to be too clever about avoiding some re-alphatization.
In alphatize-if in alpha.lisp there is a do in the first case
of the big cond. The return value is
(progn ,@(nreverse others)
(if ,(first forms) ,b ,c)

wrap this in a call to alphatize like:
(alphatize
(progn ,@(nreverse others)
(if ,(first forms) ,b ,c)
lexical
't)

(This bug is not new--I guess it had never come up before.)

EB - done.
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 Feb 85  22:50:34 PST
Received: ID <SCHERLIS@CMU-CS-C.ARPA>; Sat 9 Feb 85 01:52:12-EST
Date: Sat 9 Feb 85 01:52:10-EST
From: Bill.Scherlis@CMU-CS-C.ARPA
To: jk@SU-AI.ARPA

Jussi --

I just delivered a new reader to [1,FTL].  The files are:
(1) Code: RDECL, R0, R1, R2, R3, R4, R5, R6 -- all .LSP
(2) Debugging: RINIT, RTEST -- also .LSP
(3) Specification and Documentation: RSPEC.TXT
The reader is now complete except for two modules, BACKQ and SHARPM
(though the dispatching exists already), and two very minor (one page)
functions, PARSE-INTEGER and MAKE-FLOAT.  Most of the code has received
very preliminary testing, but of course I still owe you a formal test
set.  Nothing has been compiled, and in an interpreted system things run
slowly because of the giant TAGBODY.

You can actually load and run the reader on the Perq.  But I'm
getting clobbered by errors.  Thus, after initializing (calling
can say
(setq sample "(a '(bb::c 3.8e-5 158.) . \"b\") 2\\37. |ab|c ")
(setq s1 (make-string-input-stream sample))
(*read s1)	; will give an error.
$G (*read s1 nil 'foo) and so on. The files are much larger than I expected they would be. There are about 60 to 65 pages of code and 45 pages of specification and documentation. (I haven't counted lines, but I know the FSM alone is about 750 lines.) Has anybody started to read the first batch of code? This delivery is a bit late, I know: The CLM specifications for the READ flags are a bit ambiguous and Spice does it all wrong. (I had thought I could borrow heavily from them -- not so.) You will want to look at RSPEC to see what choices I have made. I will get the rest to you shortly. The first priority will be PARSE-INTEGER and MAKE-FLOAT, both of which are quite easy. Test data will follow that; then BACKQ, and finally most of SHARPM (except #. and #,). Please let me know if this is a reasonable order to do things. Also, please send comments concerning the code and documentation. Will my buddy (is it RPG?) do a specification presentation? I got your testing functions and will use them to make up the test set. I'm afraid that it will be enormous. (For example, there are about 40 distinct error messages to be elicited. Most non-EOF errors are continuable.) My travel plans are still uncertain. I will come out there for 10 days, but I am not yet sure when. The most likely time is now late Feb/early March. Could you send me a brief status report of the hacking activity there? Regards, Bill ------- ∂12-Feb-85 1915 JK Reader, continued. ∂12-Feb-85 1624 SCHERLIS@CMU-CS-C.ARPA Reader, continued. Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 12 Feb 85 16:24:06 PST Received: ID <SCHERLIS@CMU-CS-C.ARPA>; Tue 12 Feb 85 19:25:43-EST Date: Tue 12 Feb 85 19:25:39-EST From: Bill.Scherlis@CMU-CS-C.ARPA Subject: Reader, continued. To: jk@SU-AI.ARPA Jussi -- I just today got your handwritten comments of 2 Feb concerning the reader. Here are some responses: (1) [Add typechecking code.] Will be done in the next version. (2) [Can't find dispatch stuff.] Fixed in your latest version (of 9 Feb). (3) [Error msgs in specification.] Fixed in your latest version (of 9 Feb). **(4) [User friendly message.] The context should be the last few lines (if reading from a file) and the prefix of the current line. Could this be managed as part of the read-char buffering mechanism, or should it be an explicit part of the reader? (If it should be part of the reader, I'll include it in the next version.) -------------------- It should be an explicit part of the reader ---- maybe keep the last expression read from the same stream in a global. (5) [> to >&] Will be done in the next version. **(6) [List "non-trivial" outside functions.] Will be done in the next version. By the way, do we have any kind of "Masterscope" facility that will list functions used and free variables referenced? It should be easy enough to write.... -------------------- Martin Brooks wrote something like this --- it does not run yet. **(7) [Reader-read-char] Will be done. QUERY: What does BUFFERED-READ-STRING-CHAR return in the event of EOF. Also, the reader must accept all chars, not just string chars. What are the plans for fonts and bits? (See my docn on this point: We will eventually have to write primary attribute table code that handles the full range of characters.) ------------------- We have currently no plans for fonts and bits --- this will appear much later; don't worry about it. Buffered-read-string-char behaves like read-char. **(8) [Inline.] Please send me DEFSUBST and documentation so I can do testing here. I don't have functional specification for DEFSUBST!! -------------- Our defsubst expands into wierd compiler-macro hacking, so you can't use it. In the future, Defsubst expands into defun plus inline proclamation, thats all. So write a macro defsubst that expands into defun for time being. (9) [CLM refs.] Point taken. (10) [eql to =&] Will check for these. (11) [read-suppressed-token] Fixed in your latest version (of 9 Feb). (12) [return-from comment] Fixed in your latest version (of 9 Feb), but I'll clarify further. (13) [potnum] There is a problem here: In the specification, I define a POTNUM as a potential nunmber that is NOT also a number. We need a term for this kind of strange object -- saying "potential number" in error messages is misleading and wrong because all numbers are also potential numbers. Choices: [a] Write more elaborate error messages. [b] Define POTNUM in our user documentation. ---------------- We'll define potnum in user documentation. (14) [Errors] See my remarks at point (4) above. Jussi, I would appreciate any general stylistic comments as well, hlwever negative. We are all new to Common Lisp programming, and it would be helpful if we could criticize each other's coding style in addition to functionality. ----------------- Your style is excellent, no problems. The main problem that I see is getting the job done fast and getting you here as soon as possible to install and gettin the test files. We need you to do other stuff as soon as possible --- we are very short on man power. Could you send me a brief status report of the hacking activity there? ---------------- We are currently into the integration and test phase for stage 2 --- doing lots of compiling; I have placed the stage 2 report in your box. Would be glad to tell you more on the phone, so call if you want to know more. Please respond soon, but most urgently regarding points 4, 6, 7, and 8. Thanks, Bill ------- ∂12-Feb-85 2128 @MIT-MC:BROOKS@MIT-OZ Re: compiler and macros Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 12 Feb 85 21:28:01 PST Date: Wed 13 Feb 85 00:29:55-EST From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA> Subject: Re: compiler and macros To: FTL@SU-AI.ARPA In-Reply-To: Message from "Lucid <FTL@SU-AI.ARPA>" of Tue 12 Feb 85 20:05:00-EST The bug concerning blocks and return-froms was harder to track down than I expected. The problem is in reanalyze which should be redefined as: (defun reanalyze (form env stackheight) (let ((oldstate (save-lexical-env env))) (let ((newform (alphatize form env 't))) (restore-lexical-env env oldstate) (let ((newnode (analform newform stackheight env))) (setf (%anode-redone newnode) 't) newnode)))) ---------- I'm working on the macros in different files problem (probably tomorrow night)--whoever it was who sent me the message tonight about it. ------- EJG - transferred 850213 15:00. ∂13-Feb-85 2030 @MIT-MC:BROOKS@MIT-OZ defmacro in the same file bug. Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 13 Feb 85 20:30:22 PST Date: Wed 13 Feb 85 23:31:50-EST From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA> Subject: defmacro in the same file bug. To: ftl@SU-AI.ARPA cc: rpg@SU-AI.ARPA, ejg@SU-AI.ARPA Here are the changes necessary to get it so that you can have a defmacro in a file and use it in the next function without it complaining, and with it getting the right macro expansion (actually it used to often compile the right thing even when it complained but that was mostly fortuitous--it didn't always get things right). Note that compdefs.lisp is changed below. This means *everything* will get recompiled when you make the new compiler. Many files actually should be recompiled so it will be hard to circumvent it without losing. (Note to EB: defmacro currently uses 1- and =. Would be better for lcl if it used 1-& and =&. I'll fix the eval-when bogosity over the weekend and ship out a tape of everything on Monday.) /mods/lap/asm.lisp Change the definition of assemble form by inserting type' between the second and third arguments in the call to check-definition-consistency. Thus it becomes (check-definition-consistency name (make-%interval :lo 0 :hi ()) type 't) /mods/compiler/alpha/alpha.lisp Change the definition of alpha-macroexpand. There is an or clause with three subforms. The second of these is: (get name 'function-descriptor) Change this to be (let ((fdesc (get name 'function-descriptor))) (and (not (null fdesc)) (not (eq 'macro (%fdesc-proctype fdesc))))) Change the definition of check-definition-consistency by adding a third required argument proctype'. So the defun line looks like (defun check-definition-consistency (func argrange proctype &optional (assemmdef 'nil)) and add a :proctype arg in the call to make-%fdesc to make it: (make-%fdesc :function func :type 'user :proctype proctype :args (make-%interval :lo loargs :hi hiargs)) (The version here has some other stuff added for extra error checking and warnings about redefining macros as functions and vice-versa, but its earier to wait for the tape to get that.) /mods/compiler/analyze/analyze.lisp In the function analyze change the call to check-definition-consistency to include a third argument. Now it looks like: (check-definition-consistency name (%lambda-expected lnode) ftype) /mods/compiler/compdefs.lisp Change the definition of %fdesc to include a new field proctype'. I added it right after the type' field and before the args' field. ------- EJG - transferred 850214 12:00. ∂15-Feb-85 0814 JK Re: jobs ∂14-Feb-85 2135 sandy@Whitney Re: jobs Received: from SU-WHITNEY.ARPA by SU-AI.ARPA with TCP; 14 Feb 85 21:35:42 PST From: William "Sandy" Wells <sandy@Whitney> Date: 14 Feb 1985 2137-PST (Thursday) To: Jussi Ketonen <JK@SU-AI.ARPA> Cc: sandy@Whitney Subject: Re: jobs In-Reply-To: Jussi Ketonen <JK@SU-AI.ARPA> / 11 Feb 85 2025 PST. I really appreciate your contacting me about working for Lucid. It's an attractive invitation. I'm most interested in working in vision and robotics. I've managed to find a contingency situation in robotics and AI at SRI. Good luck with Lucid, I expect you will do well as I think there will be a good market, and you folks are the obvious people to do a first rate job of it. -sw Rod --- Sun would like to have an alpha version of our system for in-house testing by May 1. This means the end of the next 6-week cycle. It seems that we can deliver a very good subset to them at that time provided that we can extensively test and productize our code before that. The most crucial items for us are the gc (which rpg is doing), eval (which eb is doing right now), and the compiler (you). Before we can think in terms of delivery, we should have the compiler in a fully functional state (optimization issues taking the back seat) and be capable of maintaining it here at Lucid with some minor help from you. The most preferable scenario in my mind would be for you to add all the items necessary to make the compiler a full common lisp compiler during the next four weeks and then us taking over the compiler in the sense of making it more user friendly, testing it, and being able to maintain it here at Lucid. At the same time your help would be needed in learning its innards and hacking it for performance. To make your compiler fully functional, I can at least see the following tasks: (0) Remains of lambda keywords (again, performance is not important for supplied-p hacking etc.) (1) Full closures (flet, labels, macrolet, too.) (2) Special declarations (3) Multiple value stuff (catches, throws, etc.) I don't think performance is a crucial issue on any of these. The main point is political; we need to have a correct and complete compiler. Also, EB tells me that closures would be real nice for his eval stuff, too. JK ∂17-Feb-85 0425 @MIT-MC:BROOKS@MIT-OZ Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 17 Feb 85 04:25:30 PST Date: Sun 17 Feb 85 01:42:35-EST From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA> To: FTL@SU-AI.ARPA In-Reply-To: Message from "Lucid <FTL@SU-AI.ARPA>" of Sat 16 Feb 85 13:08:00-EST Jussi, I will endeavor to send a tape containing the rest of lambda list stuff, many bug fixes and some multiple value stuff EB needs right away on Tuesday (Monday is a holiday so I'm not sure Fed Exp will be open). That will leave special declarations (which I think will be fairly easy), the rest of multiple values with catches etc. (which are easy except for an efficient multiple-value-call, but not too bad for an inefficient one) and full closures (which will tax me greatly). It may be pushing things to get flet, labels, and macrolet all in in the next four weeks. After I send the tape on Tuesday and that stuff has been integrated I would appreciate getting the latest complete set of module files-- I'm still running a Jan 14th version of Lucille which is pretty minimal. Rod ------- Rod ---- sounds good. We will send you the new stuff as soon as possible. Your trip in March would be of crucial importance to us; let me know if there is anything you need from us in that regard. JK Bill --- Sun would like to have an alpha version of our system for in-house testing by May 1. This means the end of the next 6-week cycle. When are you going to be here? We need you to install the reader and the rest of the stuff as soon as possible. JK ∂17-Feb-85 2113 ROD adjust-stack bug To: RPG, EJG Here's the fix: The last function in analyze.lisp has a big cond. The last clause goes: (t (setf (%anode-wantloc ret) wantloc) (setf (%anode-wantrep ret) wantrep) (push ret colllect))... Remove the two setf's and place them at the head of the cond, as the first two expression in the enclosing let, so it looks like: (let ((type (%anode-type ret))) (setf (%anode-wantloc ret) wantloc) (setf (%anode-wantrep ret) wantrep) (cond ((eq type 'block) ... EB installed 850217. ∂18-Feb-85 0823 JK tape ∂18-Feb-85 0652 @MIT-MC:BROOKS@MIT-OZ tape Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 18 Feb 85 06:52:15 PST Date: Mon 18 Feb 85 09:54:00-EST From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA> Subject: tape To: eb@SU-AI.ARPA cc: jk@SU-AI.ARPA I'll be sending it off Tuesday to arrive Wednesday am. I have multiple-value-list, values-list and multiple-value-setq (trivial macro) all working as optimally as I can see how to do. (Question: what's the quickest way in Lucille to make a top level copy of a list? Answer: (multiple-value-list (values <list>)) !) I realized how to make supplied-p's for optionals work without having to shift all the arguments above. The cost is that non-trivial defaults take an extra instruction, as now the empty supplied-p's, keyword blocks etc. get set up before the defaults are computed, in the case there are optional supplied-p's. I hope to have that working by the time I make the tape. As for specials in lambda lists. They already work in embedded lamdba's and I made them work in multiple-value-bind yesterday. As a quick hack for now, I'm going to scan for them in the lambda list of a defun, and if there are any there make the defun take an &rest arg as soon as they start, then use a let to destructure into the right things. The stack debugger will have to be cleverer to hide this from the user. ------- ∂18-Feb-85 2133 EB ∂18-Feb-85 2018 ROD eval-when I made it work just like pages 69 and 70 of the aluminum edition, but it seems to me the result os not what you would expect. In particualr according to my reading of the definition, a top level defmacro does not get evaluated in the compiler's environment! So I added a third mode, namely toplevel, and it does everything pretty much as you would expect. The only thing you might find weird is that (eval-when (load) (defmacro foo ...)) causes foo to get compiled, but not evaluated in the compiler's environment. I guess I'm use to foo not being compiled in those circumstances, but actually this way seems better. To not have it compile would require even greater divergence from the CL spec. ∂18-Feb-85 2031 SCHERLIS@CMU-CS-C.ARPA travel Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 18 Feb 85 20:31:08 PST Received: ID <SCHERLIS@CMU-CS-C.ARPA>; Mon 18 Feb 85 23:32:44-EST Date: Mon 18 Feb 85 23:32:42-EST From: Bill.Scherlis@CMU-CS-C.ARPA Subject: travel To: jk@SU-AI.ARPA Jussi -- At the moment, it looks like I will travel to California in the very beginning of March -- arriving sometime March 2 and staying for about 10 days. Unfortunately, I cannot come any earlier as I have important visitors here on 1 March. I'll call sometime in the next few days for a status report. I also expect to ship another batch of code (including revisions to the last batch) to you in the next week. My major priority at the moment is testing; I'll try to have a test set worked up before I arrive there. Backquote is relatively easy, but sharpm is a bit tedious and will probably wait until I am out there. I hope all is well. Bill ------- Bill -- Sharpm shouldn't wait till you get here; if you are going to be here only for 10 days, I suspect that you will spend all your time integrating the stuff into the system. The reader with all the extras is becoming a time critical item; it can't be any later than it already is. JK ∂19-Feb-85 0853 JK ∂18-Feb-85 2237 @MIT-MC:BROOKS@MIT-OZ Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 18 Feb 85 22:37:25 PST Date: Tue 19 Feb 85 01:43:38-EST From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA> To: EB@SU-AI.ARPA cc: rpg@SU-AI.ARPA, jk@SU-AI.ARPA In-Reply-To: Message from "Eric A. Benson <EB@SU-AI.ARPA>" of Mon 18 Feb 85 21:48:00-EST To EB: The (eval-when (load) ...) does suppress the macro defintion getting into the compile time environment in ther version I'm sending. I don't think eval-when will do anything you don't like. To all: I'm holding off another day sending the tape in the interest of tracking down another stackheight bug EB jsut sent me, and to finally get supplied-p's for optionals finished. I'll send it out Wednesday. ------- ∂20-Feb-85 0739 JK tape ∂19-Feb-85 2206 @MIT-MC:BROOKS@MIT-OZ tape Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 19 Feb 85 22:06:28 PST Date: Wed 20 Feb 85 00:34:30-EST From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA> Subject: tape To: jk@SU-AI.ARPA, rpg@SU-AI.ARPA, eb@SU-AI.ARPA I am sending out a tape Wednesday to you. It contains all the bug fixes I have sent the last couple of weeks, plus more bug fixes (eg the if of a literal one), plus a whole lot of enhancements, mostly to do with lambda lists and specials. I still don't have supplied-p's for optionals in defuns working, and have not included that code-- I assume this is not time critical. As soon as I have got that working I will make specials work in defun lambda lists (with a quick hack) then move on to cleaning up multile value interactions with unwind-portect, catch etc. and making go work when it passes a catch or unwind-protect. Then closures. See the file log3 on the tape for a detailed description of all changes. ------- ∂20-Feb-85 0757 SCHERLIS@CMU-CS-C.ARPA Re: travel Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Feb 85 07:57:34 PST Received: ID <SCHERLIS@CMU-CS-C.ARPA>; Wed 20 Feb 85 10:59:00-EST Date: Wed 20 Feb 85 10:58:48-EST From: Bill.Scherlis@CMU-CS-C.ARPA Subject: Re: travel To: FTL@SU-AI.ARPA In-Reply-To: Message from "Lucid <FTL@SU-AI.ARPA>" of Wed 20 Feb 85 07:48:00-EST Jussi -- Given the time constraints, it would be useful for me to have some indication from you of the relative priorities of the various reader-related tasks remaining. This especially given that I have exactly ten days HERE before I leave from California. Bill ------- Do it all. You have 10 days. JK ∂21-Feb-85 0733 JK ["Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>: Kyoto Common Lisp] ∂20-Feb-85 2041 SCHERLIS@CMU-CS-C.ARPA ["Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>: Kyoto Common Lisp] Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Feb 85 20:41:32 PST Received: ID <SCHERLIS@CMU-CS-C.ARPA>; Wed 20 Feb 85 23:43:16-EST Date: Wed 20 Feb 85 23:43:15-EST From: Bill.Scherlis@CMU-CS-C.ARPA Subject: ["Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>: Kyoto Common Lisp] To: jk@SU-AI.ARPA Jussi -- You guys will be interested in this, perhaps. (Don't worry, I won't be involved with the port -- the letter was primarily to SEF's group.) Bill --------------- Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 20 Feb 85 23:39:59-EST Date: Wed, 20 Feb 1985 23:39 EST Message-ID: <FAHLMAN.12089345811.BABYL@CMU-CS-C.ARPA> Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA> To: slisp@CMU-CS-C.ARPA, rfr@CMU-CS-SPICE.ARPA, dzg@CMU-CS-SPICE.ARPA, rvb@CMU-CS-SPICE.ARPA, scherlis@CMU-CS-C.ARPA, spector@CMU-CS-C.ARPA, accetta@CMU-CS-A.ARPA Cc: wactlar@CMU-CS-A.ARPA, mcdermott@CMU-CS-C.ARPA Subject: Kyoto Common Lisp I just got a letter from Taiichi Yuasa and Masami Hagiya at Kyoto University. These are the guys who, all by themselves out in the woods, managed to get a full (so they say) Common Lisp running on the Data General Eclipse about a year ago. Anyway, they will be be visiting CMU on April 1 and 2. They say that they have ported their Common Lisp to Vax/Unix (4.2bsd) and to the Sun, and they would like to bring this code and install it for us when they come. Their implementations probably will be slower than the ones from DEC and Lucid respectively, but to have any Common Lisp at all on those machines would be very nice for us until DEC and Lucid deliver. I will ask them to bring along sources, if possible, so that we can take a crack at getting this stuff running under our 4.1 systems as well, and integrated with the ITC code for the Suns. I will probably be asking some of you to spend some time talking with these guys and to help with installing these systems on various machines around here. Just thought I'd give you some early warning. I assume that the place to do the Sun work is over at the ITC (with Dave McDonald either helping or finding some Sun wizard to help) and that Bob Baron can help with installing the Vax/Unix 4.2 version, with perhaps some help from Rashid and Accetta. -- Scott ------- ∂22-Feb-85 1819 JK trip to Lucid ∂22-Feb-85 1334 @MIT-MC:BROOKS@MIT-OZ trip to Lucid Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 22 Feb 85 13:33:54 PST Date: Fri 22 Feb 85 16:35:51-EST From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA> Subject: trip to Lucid To: jk@SU-AI.ARPA, rpg@SU-AI.ARPA I have just bought tickets (at bargain basement rates by doing it today rather than Monday) for a trip to Lucid late March. I arrive around 2pm Thurs 28 march and leave Tuesday 2nd April at 1pm. Thats 5 days in town. I have no other time commitments in Palo Alto. I can't squeeze more time in between teaching and research contract monitor malarky. I've been working on the assumption that I will find money to pay my fare, and Lucid will pay Nui's (I never got a reply to that suggestion). The tab for Lucid is$258.
-------

∂26-Feb-85  1027	FTL
closures
How are closures coming along? RPG said that he would contact you about
some ideas of his, mainly reading the S-1 code.
We have 3 weeks left on this cycle of development, projected end would
be March 18. At that point EB and to some extent me would like to
take the responsibility for the code so that we are ready for your
visit March 28.
JK

∂26-Feb-85  2015	@MIT-MC:BROOKS@MIT-OZ
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 26 Feb 85  20:15:45 PST
Date: Tue 26 Feb 85 23:18:21-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
To: FTL@SU-AI.ARPA
In-Reply-To: Message from "Lucid <FTL@SU-AI.ARPA>" of Tue 26 Feb 85 10:28:00-EST

No coding has started for closures. I will make sure RPG talks to me
soon. I have all the supplied-p's/keywords/optionals etc. completed.
I expect to get the extra cases of specials in argument lists done
tomorrow night, and fix go, unwind-protect etc over the weekend. That
leaves two weeks for closures according to your schedule. I'll try.
Keep hounding me.
-------

Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 1 Mar 85  22:23:35 PST
Received: ID <SCHERLIS@CMU-CS-C.ARPA>; Sat 2 Mar 85 01:25:32-EST
Date: Sat 2 Mar 85 01:25:29-EST
From: Bill.Scherlis@CMU-CS-C.ARPA
To: jk@SU-AI.ARPA

Jussi --
I just shipped a new set of reader files to SAIL.  The files
are R*.*[1,ftl].  The spec is in RS*.TXT.  The code is in R*.LSP.  Two
of the code files (RTEST and RINIT) are used only for debugging.
MK-FLOAT is done.  Most of Sharpm is done.  Backq will be
done when I arrive.  I still need to build a formal test set and
write parse-integer.
I'll be at Lucid Monday morning.  See you then.
Bill
-------

∂03-Mar-85  0936	JK   	compiler
∂02-Mar-85  2032	@MIT-MC:BROOKS@MIT-OZ 	compiler
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 2 Mar 85  20:31:55 PST
Date: Sat 2 Mar 85 23:28:51-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: compiler
To: rpg@SU-AI.ARPA, jk@SU-AI.ARPA, eb@SU-AI.ARPA

The current version of the compiler which you have never does tail merging.
To fix it you can mopver the three lines starting from
(label-destinations... in finishup-lambda in analyze.lisp to follow
the first line of the body of that function (the one that setf's
the %lambda-body).
-------

∂04-Mar-85  1107	JK   	status, hint and query.
∂03-Mar-85  1356	BROOKS%MIT-OZ%MIT-MC.ARPA.#Internet@MIT-XX.ARPA 	status, hint and query.
Received: from MIT-XX.ARPA by SU-AI.ARPA with TCP; 3 Mar 85  13:56:05 PST
Received: from MIT-OZ by MIT-XX via Chaosnet; 3-Mar-85 16:57:23-EST
Date: Sun 3 Mar 85 16:57:14-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: status, hint and query.
To: rpg%sail@MIT-XX, jk%sail@MIT-XX
cc: rpg@SU-AI.ARPA, jk@SU-AI.ARPA, eb@SU-AI.ARPA

MC seems to be down so any reply should go to "brooks%oz"@mit-xx.

Status.
o  All possible cases of lambda's with supplied-p's and/or specials and/or
anything else legal now work.
o  All possible cases of self tail recursion, no matter how hairy the lambda
list now work.
o  The let optimizer is much better with internal setq's so tail recurrence
and psetq should be much more efficient than before.
o  I'm now working on making go, return-from etc. break up catch frames
and fixing throw to handle multiple values. I may add a new way to
handle special binds for efficiency and for the sake of progv, a special
form which is not yet done.

Hint.
If someone is writing the billion functions that use keywords the following
may be relevent someplace (I thought it would be in equal but that
doesn't take keywords). Suppose you have an anonymous function used as
a predicate (probably handed in as a :test argument) and you have it
in a tail recursive place. E.g., (funcall test x y) in a tail recursive
place. The compiler can't tell how many values will be returned by funcall
and must assume the worst. It may be the case that the function writer
knows that only one will be used by the caller. This can be declared
by writing (values (funcall test x y)) instead. It generates precisely
as many instructions as it would have had it thought funcall always
returned exactly one value.

Query.
I've been thinking about the suggested way to implement closures following
the S-1 approach. However I don't think we can treat downward and upward
funargs identically, because block names and go tags are defined to
have lexical scope and dynamic extent. See examples on page 40 and
41 of the aluminum edition. So I think for downward funargs I need to
turn return-from/block pairs and go/tagbody pairs into throw/catch
combos. This will result in errors at the right time (e.g. page 41)
although we'll have to be clever to make the error messages meaningful
to the poor user. Does the above seem right?
-------

How's closures? RPG tells me he told you all that you ever need to
know about the stuff. McDonald is doing the new lap; this will include
the necessary support stuff. By the way, GC works and EJG
just got disksave to work.

JK
∂06-Mar-85  1915	@MIT-MC:BROOKS@MIT-OZ
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 6 Mar 85  19:15:19 PST
Received: from MIT-OZ by MIT-MC via Chaosnet; 03/06/85 22:14:03
Date: Wed 6 Mar 85 22:13:50-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
To: FTL@SU-AI.ARPA
In-Reply-To: Message from "Lucid <FTL@SU-AI.ARPA>" of Wed 6 Mar 85 08:55:00-EST

I think I know what I have to do (modulo the details) to get full CL
closure capabilities. I am currently implementing progv (needed by the
interpreter), and concurrently redoing go, return-from, throw, catch
and unwind-protect to bring them up to CL spec. The original verisions
(a) handled only single values, and (b) insulated all lexical objects
(except variables) created outside them, making them invisible from
within. The new way of doing this is a necessary pre-requiste for
getting closures to work right, and all of these special forms
interact with each other and with closures.  I hope to get all that done
by Saturday. Then I can work on the analysis phase of closures,
most of which will just be using the extra stuff I'm putting
in lexical enviroments (at analysis time) for the above. I plan on
sending you a tape of everything on March 18th. Then I will have to
work with McDonald when I'm out there to integrate code generation
with his new Lap. I have reduced my sleep phase considerably to
accomodate these goals. I will not be able to continue at the current
level of effort into April, and will want to scale back to more like
16 hours a week.

Disksave! Just like a real lisp, eh?

-------
Glad to hear you're working hard .....
Seriously speaking, the closure stuff is extremely important for the alpha
test since we suspect that Pratt will be the main SUN evaluator of our Lisp.
After it is done, I see no reason for you to have to slave away at the present
rate; I foresee EB and me (and possibly also RPG) taking over compiler stuff
with minor help from you in performance issues etc. You could start working
on a fancy inspector which is not as much of a time pressure item.

We are currently planning for the Big Hiccup which means bringing in:
(1) JONL's package code. This affects coldload, too.
(2) New lap, and new fasl format.
(3) GC and areas.
(4) McDonald's IO and Scherlis's reader.
(5) The Benson lexical evaluator
The hiccup is mainly caused by the new fasl format and package stuff.
The rest of the stuff can be integrated without too much pain.
JK
∂10-Mar-85  0755	JK
∂09-Mar-85  1442	ROD  	disk
To:   JK, RPG
ROB blames an alpha particle and thinks all the noise I heard coming
from the disk was the heads retracting to do a recalibration when
the disk looked weird to it. It turned out there was pretty minor
damage to the file system--the only file I lost was a lock file
for the uucp  spooler! But of course I didn't know that without
help from a unix wizard.

I have tapes of everything that Lucid doesn't now. I'll start backing
up to tape either every day, or twice a week or something. Maybe I
should send a weekly tape to Lucid too. And getting real paranoid,
maybe a cheap printer ($300 or$400) would be a good idea, as I
could list off all files I changed at the end of every session.
(I've just this week reorganized the files to be many smaller files
than before to save the amount of recompiling unchanged stuff I was
doing.)

I'll send a tape monday with the latest stuff. You might decide
to wait till the next round rather than integrate this one.

∂11-Mar-85  0841	JK   	68020
∂10-Mar-85  2244	@MIT-MC:BROOKS@MIT-OZ 	68020
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 10 Mar 85  22:44:26 PST
Received: from MIT-OZ by MIT-MC via Chaosnet; 11 MAR 85  01:43:10 EST
Date: Mon 11 Mar 85 01:43:05-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: 68020
To: rpg@SU-AI.ARPA, jk@SU-AI.ARPA

In talking with Web Augustine on Thursday I discovered that the SUN-III
they would use the full 32. Anyway that gives 26 bits of pointer
addressing which is 1 more than TI's explorer (which itself
made use of one more available one than did MIT CADR's), and 3 less
than 3600's.

Gee--maybe we should have used those top four bits and then we

-------

∂11-Mar-85  0843	JK   	tape
∂11-Mar-85  0828	@MIT-MC:BROOKS@MIT-OZ 	tape
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 11 Mar 85  08:27:49 PST
Received: from MIT-OZ by MIT-MC via Chaosnet; 11 MAR 85  11:25:58 EST
Date: Mon 11 Mar 85 11:25:52-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: tape
To: rpg@SU-AI.ARPA, jk@SU-AI.ARPA, eb@SU-AI.ARPA

A tape is on its way. This is mostly for insurance but you can install
it if you want (let me know what you decide so I can make the next
tape contain only the necessary stuff.) Features include:

o throw is almost certainly broken (I'm half way through the upgrade).

o progv works completely when the number of variables can be determined
at compile time--missing two runtimes for the other case. this
includes a bunch of new multiple value handling stuff which seems to
work and which I'll now install in catch and unwind-protect to bring
them up to spec.

o redone multiple value returning--basically cleaned up part of
coerce-loc-and-rep and added new cases. (this also fixes RPG's
bug when a function tries to return 0 values.)

o **full CL lambda lists including specials being allowed anywhere.**

o much better code produced for most tail recursions due to better analysis
of setq interactions (I used to just punt on seeing the first one...).

o or is sometimes smarter.

This version gives the 11 instruction loop for shorterp. If tak was
doing anything stupid in shuffling things on and off the stack (I
don't remember whether it was) then that will be fixed by this version
too.

-------

∂13-Mar-85  0758	JK   	status
∂13-Mar-85  0722	@MIT-MC:BROOKS@MIT-OZ 	status
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 13 Mar 85  07:22:21 PST
Received: from MIT-OZ by MIT-MC via Chaosnet; 13 MAR 85  10:21:21 EST
Date: Wed 13 Mar 85 10:21:10-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: status
To: jk@SU-AI.ARPA

You wanted me to be finished by Monday March 18th. Thats a good finishing day
for me until I get out to PA as I have lots of travel starting then.

Here's what I realistically expect to get done by next Monday:

THROW, CATCH, UNWIND-PROTECT, PROGV, GO, RETURN-FROM all up to full CL
spec with respect to their interactions and multiple values.

Closures: alphatization and analysis. No code generation.

This leaves the following to be done to make the compiler full CL:

Closure code generation.

LABELS, FLET, MACROLET (the latter is pretty trivial).

Making it listen to local special declarations--this is probably just an hour
or two's work.

I think that EB, RPG, JIM, JK and I, or some subset thereof working together while
I'm out there can get all of these finished.
-------

Sounds great ---- send us the code as soon as it is done so we can start looking
at it and figuring out who needs work on it.
I hope the last few weeks have not been too much of a strain on you -- thanks for
putting in the extra time.
JK
∂18-Mar-85  0716	JK   	tape
∂17-Mar-85  1956	@MIT-MC:BROOKS@MIT-OZ 	tape
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 17 Mar 85  19:56:00 PST
Received: from MIT-OZ by MIT-MC via Chaosnet; 17 MAR 85  22:55:02 EST
Date: Sun 17 Mar 85 22:54:41-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: tape
To: jk@SU-AI.ARPA
cc: eb@SU-AI.ARPA, rpg@SU-AI.ARPA

I'm sending a tape off in the morning. Here's the status:

o Everything I reported last time still works. I believe the compiiler
is in a workable state and won't screw you if you use it.

o catch, throw, unwind-protect, progv, go and return-from all are up
to full CL spec (modulo detail below) with respect to scope and
handling multiple values. In particular the only time these guys
cons is when they are returning more than four values through an
unwind-protect. E.g. if throw is throwing 627 values through
a bunch of catches and progvs it does no consing and only moves
things on the stack once.
**NB** The format of catch frames has changed. Everything in lcl
needs to be recompiled, otherwise, for instance, the debugger
wont work.

o special binds now use progv instead of unwind-protect gaining much
efficiency.

o alphatization of closures is complete.

o environment analysis now includes keeping track of lexical contours.
this was needed to enable go and return-from to be fully general.
it also allows you to figure out where a variable is established
for closure analysis.

o the analysis phase is fully recursive and can walk over closures
with all the right environments set up.

o block and tagbody notice when they have a return-from or go down in
them hidden inside a closure. I have the transformations worked
out that need to be done in these cases, and have some runtime
support implemented for getting the right error message when they are done
illegally dynamically. This is about 1 to 2 hours work to finish.
(I may have time later in the week.)

o the support is there to do all the rest of the stuff RPG did on the
S-1 compiler, but putting it together is not yet done. I suspect
he and I can do it together in a days solid hacking.

----
My status: I'll be at CMU for 2 days starting in about 8 hours. Then
I'll be back here for 4.5 days catching up on a million things I've
put off the last month while hacking the compiler--I doubt I'll
have much time to hack on this during that time. Then I'll be in
St. Louis until I arrive in Palo Alto on THhursday 28th.
(If you're not going to use the new compiler before then at least
make sure you can read the tape by the end of this week.)
-------

∂23-Mar-85  1144	JK
∂22-Mar-85  2040	ROD  	SUN sevice contract
To:   RPG, JK
Is my SUN under service contract? It is getting the same sort of disk
errors that happended two weeks ago tonight, but this time power
cycling doesn't help, and it doesn't get as far as letting me repair
the file system before it reboots again. (I'll try again
tomorrow but I'm not hopeful.)

Fortuneately I had just ifnished dictating some changes to EB so
there is nothing on the disk here that LIHQ doesn't have.

∂23-Mar-85  0802	ROD  	broke
To:   RPG, JK
The SUN disk seesm well and truly broke--trasnfer errors, seek errors,
drive faults, etc. Can one of you ask Jan to figure out what should
be done re service contract. If she wants she could get someone to come
over here sometime during Monday through Wednesday (after calling
Nui at (617)863-8930 to make sure she'llbe home to let them in), or
we can just leave it till after I get back.

From tomorrow I can be reached at the St Louis Marriott Pavilion
(314)421-1776 if compiler bugs warrant it.

∂26-Mar-85  0843	JK   	For your info...
∂21-Mar-85  0902	ROB%CCRMA@SU-AI.ARPA 	For your info...
Date: 21 Mar 85  0851 PST
From: Robert Poor <ROB%CCRMA@SU-AI.ARPA>
To:   jk@SU-AI.ARPA, rpg@SU-AI.ARPA

[This excerpted from unix-wizards-digest.  - Rob]
From: wegrzyn@encore.UUCP (Chuck Wegrzyn)
Subject: Public Domain EMACS available from GNU Project
Date: 20 Mar 85 16:03:20 GMT
To:       unix-wizards@brl-tgr.arpa

The GNU project has released its first major subsystem,
the EMACS editor. This editor is a sophisticated screen
editor that is compatible and comparable with the EMACS
editors being sold by UniPress and CCA. It comes with
Mock Lisp ( did you know that UniPress trademarked MLISP??),
and all the little bells and features most of us expect
with EMACS.

The GNU version of EMACS, written by Richard Stallman, is
available for distribution. The distribution includes all
source code for EMACS and a source code level debugger.
Furthermore, under the GNU project banner, the EMACS system
can be distributed (in source code form) by one and all.

I was thinking of sending out the source code over the net,
but resisted : it is over 1Mbyte of code. If there is
enough demand, I will add a UUCP dial-in to our system, or
send out tapes, or ... ?

Is anyone interested in EMACS? If so, please tell me how
you think I should distribute it?

Chuck Wegrzyn
{allegra,decvax,ihnp4,princeton}!encore!wegrzyn

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

∂02-Apr-85  0800	JK   	flavor ?s
∂01-Apr-85  1215	ssc-vax!steve@uw-beaver.arpa 	flavor ?s
Received: from UW-BEAVER.ARPA by SU-AI.ARPA with TCP; 1 Apr 85  12:15:02 PST
id AA25407; Mon, 1 Apr 85 12:18:13 PST
Return-Path: <ssc-vax!steve@uw-beaver.arpa>
id AA14891; Mon, 1 Apr 85 08:39:56 pst
Date: Mon, 1 Apr 85 08:39:56 pst
From: ssc-vax!steve@uw-beaver.arpa (Steve White)
Message-Id: <8504011639.AA14891@ssc-vax>
To: uw-beaver!jk@su-ai.arpa
Subject: flavor ?s

This is a short description of the problem mentioned over the phone.
Flavors compose according to a depth-first expansion of the
components tree (modulo :included-flavors), cycles are broken by
ignoring any flavor already in the components list.

(defflavor a nil (c b))			;C before B
(defflavor b nil (c))			;B before C

sets up a situation where according to A, flavor C is searched
before B for method handlers, but B has been "defined" assuming that
its messages are searched before the handlers for C. This seems to
violate the encapsulation property that OOP regards so high.
The funny case is when B sets up a lock for some resource that
C uses, then its possible to create a deadlock situation by
sending instances of Bs & Cs the message in the wrong order.
(It's arguable that if the programmer specified the above combination
they would deserve the result) In any case it seems that this is
detectable and possibly a warning could be issued.

Another problem is using :before & :after callers,

(defmethod (a :before :tst) nil (format t "Before A~%"))
(defmethod (b :before :tst) nil (format t "Before B~%"))
(defmethod (c :before :tst) nil (format t "Before C~%"))

(defmethod (a :after :tst) nil (format t "Before A~%"))
(defmethod (b :after :tst) nil (format t "Before B~%"))
(defmethod (c :after :tst) nil (format t "Before C~%"))

(defmethod (a :tst) nil (format t "A Handled~%"))
then
(send (make-instance 'a) :tst) ==>
Before A
Before B
Before C
A Handled
After C
After B
After A
I'm not real sure it makes sence to run all the :before & :after
methods "lower" then the primary handler if the primary handler

ssc-vax!steve@uw-beaver

∂02-Apr-85  0801	JK   	this is a test
∂01-Apr-85  1140	bcsaic!steve@uw-june.arpa 	this is a test
Received: from UW-JUNE.ARPA by SU-AI.ARPA with TCP; 1 Apr 85  11:40:30 PST
id AA28196; Mon, 1 Apr 85 11:38:56 pst
From: bcsaic!steve@uw-june.arpa
Return-Path: <bcsaic!steve>
id AA10539; Mon, 1 Apr 85 11:39:34 pst
Date: Mon, 1 Apr 85 11:39:34 pst
Message-Id: <8504011939.AA10539@bcsaic.UUCP>
To: uw-june!jk@sail
Subject: this is a test

message to see if this route gets out, could you reply if this
got there via route "bcsaic -> uw-june -> sail", the first hop
is via UUCP the second is over ARPA, thanks

-steve

-----
got it.

∂03-Apr-85  2026	JK
∂03-Apr-85  1950	ROD  	randomness
To:   RPG, JK, EB
I tried to boot the SUN at least 8 times over three days before I left for
St Louis. The SUN person is coming tomorrow at 10am. Just for fun I tried
booting it tonight--if corrected a coouple of errors in the file system
and booted just fine--not a single disk error.... So I'll call SUN in
the morning. Maybe its a flakey cable.

In any case please send me a tape of /mods, the big Franz Lisp,
EJG's 53 line emacs, and /pub/usr/rod. If you send it out Thursday
I can hack over the weekend. Make sure EB includes JONL's bug
tickling code too.

∂08-Apr-85  0822	JK   	tape
∂07-Apr-85  2219	@MIT-MC:BROOKS@MIT-OZ 	tape
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 7 Apr 85  22:19:19 PST
Received: from MIT-OZ by MIT-MC via Chaosnet; 8 APR 85  01:18:30 EST
Date: Mon 8 Apr 85 01:17:51-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: tape
To: jk@SU-AI.ARPA, ejg@SU-AI.ARPA, rpg@SU-AI.ARPA

I am sending a tape in the morning. It contains

o local special declarations complete and CL spec (trickier than I had
thought)

o random bug fixes tickled by exercising the special binding code in testing
the above.

o some improvement in handling multiple closures.

This should be a pretty straightforward integration into you current
compiler version.

What needs to happen before I can test any closure stuff is:

EB should write a fastcall for sq-fcons which takes a procedure on the
stack and returns a copy on the stack. I don't have enough of the
module structure here to figure out how to do that.

JIM should make newlap understand closures.

Then if you send me back a tape (also the modules I'm missing) I'll
work on finishing closures next weekend.

-------

∂12-Apr-85  0743	JK   	Announcement
∂11-Apr-85  0824	RPG   	Announcement
∂10-Apr-85  1654	HANDERSON@CMU-CS-C.ARPA 	Announcement
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 10 Apr 85  16:50:36 PST
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Wed 10 Apr 85 19:50:37-EST
Date: Wed, 10 Apr 1985  19:50 EST
Message-ID: <HANDERSON.12102149104.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To:   Dick Gabriel <RPG@SU-AI.ARPA>
Subject: Announcement
In-reply-to: Msg of 10 Apr 1985  19:36-EST from Dick Gabriel <RPG at SU-AI.ARPA>

Dick,

I think I yelled it on some mailing list I didn't intend to, but you're welcome
to look at the code.  It's in [cmu-cs-c]<handerson.flavors>.  I intend
everything to be portable CL.

All I ask is that you consider sharing improvements with me and that you
definitely inform me of any bugs you find - I can't fix what I don't know
about.  The kernel is currently broken, but I hope to have a still improved
version available tomorrow.

-- Steve

∂15-Apr-85  0721	JK
∂14-Apr-85  1602	ROD  	y combinator and bugs
I just now have a working compiler and assembler to play with. The
y-combinator now works, but in testing it on factorial I noticed
that whereas in

(*& 100000 100000)

gace an overflow error and trapped ot the debugger, lucille merely
gives a segmentation fault and dumps core. In making the new error
handler someone must have forgotten to fix &* for it.

∂16-Apr-85  0844	JK   	misc questions
∂15-Apr-85  1423	boeing@diablo 	misc questions
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 15 Apr 85  14:23:21 PST
Date: Mon, 15 Apr 85 14:23:40 pst
From: Boeing <boeing@diablo>
Subject: misc questions
To: jk@sail

I talked with Alan Snyder (@HPLABS) regarding a proposal for common lisp
objects, and he mentioned that he had already forwarded a copy of his
proposal to Eric Benson.  Could you ask Eric to send me a copy of the
proposal?

Possibly Eric could give me a call regarding objects w.r.t. LCL?

Tony had indicated that a copy of (all the) paperwork that I signed
would be forwarded back to me, so far I don't have a signed copy of
any of the last round of agreements.

Finally, I got several bids on putting in a drivewalast weekend,
these bids are only good for 30days, so I would like to get going
on them asap.  Who should I talk this over with?
-steve
PS: I would have probably just called but I forgot my list-of-numbers
this morning!?
-----------
Steve ---
Go ahead and take whichever bid is most convenient --- the view from
from our end is that we have a $2000 lump sum reserved for this purpose. We can send that money now or after --- in any case, keep your receipts. I will ask Jan to send you copies of the stuff. I will also ask EB to call you. JK ∂22-Apr-85 0749 JK ∂21-Apr-85 2252 ROD bugs and closures I telephoned in the last binding bug fix to EB who fixed it (I think) in the compiler. So now you can try bind-test again and it should all work. One hting that file doesn't test is interactions of local special declarations and multiple-value-bind. I have made a lot of progress on closures and can now compile closure-test (but not assemble it due to the lap bug) all the way up until you started putting closures as default values for optional arguments. There is only one other thing I have to do for bare clsoures--handle a closure inside a tagbody some of whose bindings are established outside (and imilarly for if). I plan to do that Monday eveneing and send you a tape tuesday. It will not include the default argument stuff yet. Then onto labels etc. I assume things will end eventually... ∂23-Apr-85 0810 JK closures ∂22-Apr-85 2237 @MIT-MC:BROOKS@MIT-OZ closures Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 22 Apr 85 22:32:31 PST Received: from MIT-OZ by MIT-MC via Chaosnet; 23 APR 85 01:32:48 EST Date: Tue 23 Apr 85 01:31:28-EST From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA> Subject: closures To: jk@SU-AI.ARPA, eb@SU-AI.ARPA I haven't quite got all the bugs out of the hairy loop sharing closure case, so I will not sen a tape until Wednesday after working onit again tomorrow night. Incidentally, I decided to do it right and am using cons cells to provide the shared data stucture rather than code-less closures as was the original hack plan. ------- ∂23-Apr-85 0811 JK ∂23-Apr-85 0700 ROD closures after my last message I got the hairy loop cases with closures working. I'll test some more tonight and try to get the closures in optional defaults working, then send a tape tomorrow. Incidentally, the multiple-value-bind example is neither a bug in multiple-value-bind nor in local special declaration hndling. It turns out there has been a bug all along in the way the let optimizers substitute into a let body such that the substitution gets ignored when the whole body is getting replaced. I'll fix that tonight too. ∂23-Apr-85 1938 JK ∂23-Apr-85 1442 ROD multiple valued fastcalls Jussi, Please tell Rob Poor that multiple valued fast calls already work. To define truncate& say, one would do: (defprimop truncate& 2 2 :pred (fixnump fixnump) :fast sq-truncate :effs nil)) The first "2" says it takes two arguments on the stack, and the second "2" says that it returns 2 arguments. 0.43 1 2 19 42,2012 13,390 3792P 53% 1 12 Also let him know that on entry to a fastcall the arguments are on the stack and immediately on top of them is a return pc. On exit the results should start where the first arg was. Rod ∂24-Apr-85 0743 JK ∂23-Apr-85 2200 ROD tape A tape with full closures and sundry bug fixes to other things should arrive at Lucid Thursday morning. I was able to test a few examples which didn't tickle the assembler bugs and it seem sto do the right thing for closures inside loops. It certainly compiles all the examples in closure-test, but I couldn't assemble many of them. It handles closures in optional and key defaults although that is not well exercised and may have some bugs lurking. ∂26-Apr-85 0738 JK 370 common lisp ∂26-Apr-85 0705 @MIT-MC:BROOKS@MIT-OZ 370 common lisp Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 26 Apr 85 07:01:31 PST Received: from MIT-OZ by MIT-MC via Chaosnet; 26 APR 85 10:02:22 EST Date: Fri 26 Apr 85 09:57:52-EST From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA> Subject: 370 common lisp To: rpg@SU-AI.ARPA, jk@SU-AI.ARPA Intermetrics claims to have a 370 Common Lisp (including compiler). There is a talk about it next Wednesday evening. I will go to it. Maybe we should schedule a similar sort of thing around here about Lucid CL. Dick, can you get in on whatever series it was you gave the timing talk at and get them to invite you again? ------- ∂29-Apr-85 0759 JK ∂28-Apr-85 1317 ROD do-all-symbols and performance To: JLW, EB, JK, RPG do-all-symbols macro is not defaultly in the compiler. After I put it there and ran it I discovered it is buggy--it returns a list with all the symbols, plus a bunch of entries like: (*empty*). I first tried to run it interpretively, with 0.5meg free space. It GCed after using 3kbytes of storage for the list--i.e. 99.4% consing overhead in the interpreter! After 5 minutes I gave up. Compiled it took abouta a second. This is unacceptable interpreter performance to most people. ∂29-Apr-85 0759 JK ∂28-Apr-85 1336 ROD storage To: JK, RPG, EB It occured to me that the arglists stored with each procedure might be taking up undue amounts of storage, so I started to collect some statistics. One thing led to another and I obtained the following puzzling results. I added headers and rounded up to 8 byte multiples everywhere. I looked at all symbols, and divieded them into two classes--those both unbound and unfbound and those which are at least one of those. Below first column is boht unbound and unfbound. Last column is all symbols. Row lables are: n: number of symbols in this category proc: bytes devoted to procedure headers argl: bytes devoted to arglist cons cells code: bytes devoted to code vectors symb: bytes devoted to symbols themselves pnam: bytes devoted to print names totl: total number of bytes n | 1567 | 2168 | 3735 | --------------------------------- proc | 0 | 79048 | 79048 | argl | 0 | 28264 | 28264 | code | 0 | 688328 | 688328 | symb | 37608 | 52032 | 89640 | pnam | 28008 | 48040 | 76048 | --------------------------------- totl | 65616 | 895712 | 961328 | Kahlua binary size: 2798592 GC reports free: 513040 Bytes accounted for: 961328 ------- Unaccounted bytes: 1324224 So that means 1.3Mb burnt on package structures (including obarrays) and GC tables. Or lost in space somewhere else. Or have I forgotten some other major piece of storage? ∂29-Apr-85 0801 JK ∂28-Apr-85 1901 RPG Well To: ROD@SU-AI.ARPA CC: JK@SU-AI.ARPA, EB@SU-AI.ARPA The GC reported (as of the version we sent you) the number of bytes free until a flip was required, so you can effectively take the amount of dynamic storage you know about, add the amount that GC reports free, and then double that total for the total amount of space used by dynamic structures plus the free space. To figure the amount free, take what the GC reports (= gc-free), what you know is in dynamic (= known-dynamic) and do: total+free = 2*(gc-free + known-dynamic) - known-dynamic = 2*gc-free + known-dynamic I'm not sure this jives Using your table, I get: 2*513040+961328+89640+76048 = 21530960 from know stuff. There are a number of free segments for code and static stuff, which I did not count, and the first 32k is a wash because of Unix. No GC tables are in dynamic space. -rpg- ∂29-Apr-85 0801 JK Re: Well ∂28-Apr-85 2039 @MIT-MC:BROOKS@MIT-OZ Re: Well Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 28 Apr 85 20:39:50 PDT Received: from MIT-OZ by MIT-MC via Chaosnet; 29 APR 85 00:38:48 EDT Date: Sun 28 Apr 85 23:39:23-EDT From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA> Subject: Re: Well To: RPG@SU-AI.ARPA cc: jk@SU-AI.ARPA, eb@SU-AI.ARPA In-Reply-To: Message from "Dick Gabriel <RPG@SU-AI.ARPA>" of Sun 28 Apr 85 19:01:00-EDT I don't completely follow your arithmetic. How about this: Total space = 2*(gc-free + known-dynamic) + known-code = 2*(513040+79048+28264+89640+76048) + 688328 = 2260328 (assuming code space doesn't count as dynamic?) Thats within 0.5Mb. ------- ∂29-Apr-85 0803 JK ∂28-Apr-85 2252 ROD common lisp compiler To: JK, EB, RPG I'll send a tape in the morning to arrive Tuesday that includes: compiler-let, flet, and labels all working completely. macrolet working modulo two things: 1. It relies on a function turn-macro-into-destructuring-lambda which takes a form like (macro (x y) (...)) and returns a lambda expression of one variable which could be funcalled on a form to be macro expanded and would return a single level of macro expansion under the sepcified macro. I assume JK will take care of writing this, or changing the single call to it in alph-special.lisp to the right thing. 2. I havne't added the optional environment argument to compiler-macroexpand, alpha-macroexpand or macroexpand. This is only needed in the screwiest of cases (I handle recursive macro expansions over macrolet'ed macros without it). I'll leave that for someone else to fix. The argument to seed the environment from alphatize is lexical'. I have not actually tested macrolet, but it mostly shares code with flet and labels. Can you send me a fixed lap sometime? I'll include my statistics gathering code in a file: gather.lisp I guess I should next test the errror handling for lost go tags and lexical blocks from within closures. (And modify the uncaught throw catcher to do the right things for them.) ∂30-Apr-85 0818 JK ∂30-Apr-85 0210 JLW do-all-symbols To: ROD@SU-AI.ARPA CC: JLW@SU-AI.ARPA, EB@SU-AI.ARPA, JK@SU-AI.ARPA, RPG@SU-AI.ARPA Re your message of 28-Apr-85 13:17 I just tried out the package-macros file in LCOMP, and am getting exactly the correct behaviour. Could some other bug explain your comment After I put it there and ran it I discovered it is buggy--it returns a list with all the symbols, plus a bunch of entries like: (*empty*). ? Actually, you shouldn't attempt to "run" do-all-symbols in the LCOMP environment -- only to macroexpand such forms. I did debug it under a Franz based environment, but it takes a bunch of setups t get the real package structure there. At any rate, EJG discovered a faslout bug today (and fixed it) that caused LCOMP to lose badly *ocasionally*; after that fix, I had no problem just loading in the file package-macros.o into LCOMP, compiling some code that used do-all-symbols, and then running the resultant .lbin file ok. The consiness of the evaluator which you remarked upon has been a subject of some discussion (and chagrin!) here already. -- JonL -- ∂30-Apr-85 1646 JK ∂22-Apr-85 1209 RPG ∂04-Apr-85 1300 ROD cmu summer hacker his name is Richard Wallace. rsw@cmu-ri-rover. He works for Hans and Kanade. --------- Rod Brooks tells me that you might be interested in a summer job at Lucid --- any truth in this? If so, could you send a resume of sorts etc for us to look at? Jussi Ketonen Project Manager, Lucid ∂30-Apr-85 1653 JK Lucid and LISP programming ∂22-Apr-85 1128 RPG Lucid and LISP programming ∂21-Apr-85 2254 RIK@SU-CSLI.ARPA Lucid and LISP programming Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 21 Apr 85 22:54:36 PST Date: Sun 21 Apr 85 22:53:47-PST From: Rik Sprague <RIK@SU-CSLI.ARPA> Subject: Lucid and LISP programming To: rpg@SU-AI.ARPA Hi, I'm an instructor for CS122 (LISP programming) this quarter. Just yesterday, I discovered that I will be staying around Stanford for the summer, so now I'm looking for a good LISP-type programming job. I was told that Lucid might be looking for people. Can you tell me who I might talk to, etc.? Rik Sprague ------- Hi, Lucid is indeed looking for people. In order to proceed we need (a) a resume (b) samples of Lisp programming done by you. Could send us some stuff soon ---- I would like to set up an interview as soon as possible. Best Regards, Jussi Ketonen Project Manager, Lucid ∂30-Apr-85 1654 JK Lucid & Lisp ∂22-Apr-85 1128 RPG Lucid & Lisp ∂18-Apr-85 1141 shivers@cmu-cs-h.arpa Lucid & Lisp Received: from CMU-CS-H.ARPA by SU-AI.ARPA with TCP; 18 Apr 85 11:40:53 PST Date: 18 Apr 1985 14:43:33-EST From: Olin.Shivers@CMU-CS-H To: rpg@su-ai Subject: Lucid & Lisp Hello. I am a graduate student at Carnegie Mellon University. I'm interested in optimising compilers for lexically scoped lisps. I've heard about your company, Lucid, from Scott Fahlman and David Toureztky. It looks like you have a sizeable fraction of the available lexically scoped Lisp talent cornered at Lucid. If you have summer positions open for Lisp compiler and system hacking, I'd be interested. I've had previous experiences with Lisp implementations. In 1981 I wrote a throw-away Scheme compiler in Maclisp that targeted into MACRO20 assembly for a DEC-20. It was a single-person effort, and included full lexical scoping, environment analysis for code optimisation, and upward funarging. Last summer, I worked with a group headed by Jonathan Rees on the design and implementation of version 3 of the T language, and its optimising compiler, Orbit. The compiler was targeted to the VAX and a RISC processor under development by DEC. I think you know Jonathan and T. The Orbit compiler included global register allocation, type analysis, environment analysis, trace-scheduling code generation, procedure integration, and representation analysis. It is the most highly optimising lisp compiler that I know of to date. It is also particularly elegant: almost the entire T system -- including the compiler, evaluator, garbage collector, loader, system linker, and assembler -- is written in T. My part of the effort included flow analysis, language design, runtime internals, and the linker. I like lexically scoped lisps because -- among other reasons -- of the leverage they give the compiler for doing powerful optimisations. Seeing Lisp judged by the example of franzlisp makes me flinch; I'd like to see the world do better. A C.V. follows. -Olin Shivers ----- Olin Shivers Computer Science Dept Carnegie-Mellon University Schenley Park Pittsburght, Pennsylvania (412) 578-7598 Olin.Shivers@CMUA INTERESTS: Design and implementation of Lisp, optimising compiler design, search-based achitectures for intelligent systems, digital circuit synthesis, expert systems. EDUCATION: September 1984 Carnegie-Mellon University Entered PhD program in the Computer Science Department. Doing research on search-based computer architectures with advisor Allen Newell. Summer 1983 Trinity College, Oxford University Summer program in English literature and Art History. May 1983 Yale College Awarded B.S. Cum Laude with double major in Computer Science and Mathematics. Strong background in Physics and EE. Employment: Summer 1984 DEC Western Research Lab Member of Jonathan Rees's T3 group. The group designed and implemented version 3 of the lexically scoped lisp, T, and its optimising compiler, Orbit. The compiler was targeted for the VAX and a DEC RISC processor currently under development. Worked on flow analysis, language design, runtime internals, and the linker. Summer 1982 MIT AI Lab Worked with Prof. Randy Davis' Hardware Troubleshooting project. Wrote constraint compiler for DPL implementation language. Designed language extensions. Summer 1981 Southwire Co., Carrollton, Ga. Developed device-independent 2D color graphics packages for business and engineering applications on Burroughs B6500. Project included hardware selection, software design, and implementation in ALGOL. Summer 1980 Southwire Co., Carrollton, Ga. Developed systems tools for program development on Tandem/16 computer. Smaller programs included printer servers, and file browsers. One major program was an interactive screen-oriented forms-design tool that compiled forms into COBOL source to produce a given transaction form. Another was a tool that analyzed application programs for references to system-wide files and structures, and maintained a table of these references. Summer 1979 CSTL Engineer Experiment Station, Georgia Inst. of Technology Minor programming tasks in compiler development project. Administrative work on Ada language development project. Minor hardware work. 1976-1979 EMS Department, Georgia Inst. of Technology Programmed part-time for professor. Developed a hidden-surface 3D graphics system in FORTRAN. Wrote small plotting package on CDC CYBER76 for experimental data. Some numerical analysis in FORTRAN. ∂30-Apr-85 1659 JK Lucid & Lisp ∂22-Apr-85 1128 RPG Lucid & Lisp ∂18-Apr-85 1141 shivers@cmu-cs-h.arpa Lucid & Lisp Received: from CMU-CS-H.ARPA by SU-AI.ARPA with TCP; 18 Apr 85 11:40:53 PST Date: 18 Apr 1985 14:43:33-EST From: Olin.Shivers@CMU-CS-H To: rpg@su-ai Subject: Lucid & Lisp Hello. I am a graduate student at Carnegie Mellon University. I'm interested in optimising compilers for lexically scoped lisps. I've heard about your company, Lucid, from Scott Fahlman and David Toureztky. It looks like you have a sizeable fraction of the available lexically scoped Lisp talent cornered at Lucid. If you have summer positions open for Lisp compiler and system hacking, I'd be interested. ---------------- Yes, we would be very interested. When could you come and how long can you stay? Do you have a phone number where we could reach you? Also: Phone number(s) of any references for you. Best regards, Jussi Ketonen Project Manager, Lucid ∂01-May-85 0754 JK Re: analyze-primop ∂30-Apr-85 2200 @MIT-MC:BROOKS@MIT-OZ Re: analyze-primop Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 30 Apr 85 22:00:09 PDT Received: from MIT-OZ by MIT-MC via Chaosnet; 1 MAY 85 00:58:54 EDT Date: Wed 1 May 85 00:58:24-EDT From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA> Subject: Re: analyze-primop To: JK@SU-AI.ARPA In-Reply-To: Message from "Jussi Ketonen <JK@SU-AI.ARPA>" of Tue 30 Apr 85 18:57:00-EDT Sounds like a good fix. I suspect this never mattered in the pre-EB tail days and everything worked out fine. Make sure I get a copy of the fixed file sometime. ------- ∂03-May-85 0831 JK 370 CL To: FTL, JLW ∂01-May-85 2127 @MIT-MC:BROOKS@MIT-OZ 370 CL Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 1 May 85 21:27:41 PDT Received: from MIT-OZ by MIT-MC via Chaosnet; 2 MAY 85 00:18:57 EDT Date: Thu 2 May 85 00:19:26-EDT From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA> Subject: 370 CL To: jk@SU-AI.ARPA, rpg@SU-AI.ARPA I went to the Intermetrics 370 Common Lisp talk tonight. They are pretty much babes in the woods. They are porting SPICE, including the compiler. 2 people have been working 5 months on the compiler. I believe others are working on other aspects as a GC question was deferred to someone at the back of the audience. They are running under cms/vm. They use the top eight bits for tags. They use excess 2↑23 fixnums. They write protect a page at the top of the heap(s) so that a write violation signals GC time, in order that cons need do no checking in line. They have two fixed size heaps to copy between. Call is 3 args in regs, arg count in R0, and rest of args on the stack in the callee's frame. Single value gets returned in the register. They snap links for speed. Normal funciton calls go via a pondering routine which decides whether the callee is interpreted etc. They do tail calls as jumps. Multiple values are always consed into a heap vector. They look back on the stack an arbitrary number of frames to see if multiple values were expected first however. They haven't yet decided how to do either catch, throw or unwind-protect. They make generic plus and minus fast in the case everything is actually a fixnum. Their tags are chosen such that if you add two things and get a fixnum then both arguments must have been fixnums. So they only exececute four instructions (out of six generated) if generic plus gets two fixnums. They associate access funs with every array. Every call to a closure does consing to set up the lexical environment to look like what the interpreter would have done. ------- ∂03-May-85 0831 JK gold hill ∂01-May-85 2158 @MIT-MC:BROOKS@MIT-OZ gold hill Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 1 May 85 21:58:06 PDT Received: from MIT-OZ by MIT-MC via Chaosnet; 2 MAY 85 00:58:12 EDT Date: Thu 2 May 85 00:58:43-EDT From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA> Subject: gold hill To: jk@SU-AI.ARPA, rpg@SU-AI.ARPA Jerry Barber was at the talk tonight (he is giving next month's). He told me that he and Nick Gall have just finished a compiler. Beta test in two weeks and market in August. ------- ∂03-May-85 0832 JK generic arithmetic ∂01-May-85 2200 @MIT-MC:BROOKS@MIT-OZ generic arithmetic Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 1 May 85 21:59:51 PDT Received: from MIT-OZ by MIT-MC via Chaosnet; 2 MAY 85 01:00:27 EDT Date: Thu 2 May 85 01:00:54-EDT From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA> Subject: generic arithmetic To: ejg@SU-AI.ARPA cc: jk@SU-AI.ARPA, rpg@SU-AI.ARPA Here are some thoughts on generic arithmetic. You've probably thought of most of these already but maybe there's something new. (EB told me about the OR trick tonight.) I think it extremely important that generic plus and minus turn out to be fast in the case that both arguments are fixnums and the result is a fixnum. I think that will capture 99% of all generic arithmetic of a large class of users. I think it is worth sacrificing portability of the code to implement this part of generic arithmetic and redo it for every machine. Thus generic plus and minus should be open coded with a call (or more) to fixup routines for the non fixnum cases. Since all arithmetic operations besides 32 bit plau and minus have to be handcoded anyway I don't think we should worry about this introducing a few new fastcalls. Consider just plus. There are special things you can do for each of the following cases: a. (+ x y) b. (+ x 5) c. (+ x 5.0) d. (setq x (+ x 7)) Likewise there will be 4 cases for - and 3 for reverse -. In case b the testing sequence is quicker. In case c it is non existent. Case d. is currently hacked into the compiler for +& and -&. It does these directlyu on the stack. Maybe it can't be done right generically because of overflow and not being able to get x back. The real problem is that arithmetic with overflow protection begs to be done in dreg's, but once you've got things there and discover they are not fixnum's you had better get the originals from their markable locations to send to the fixup routine, due to GC's. Havuing to get things twice kills code density. One possibility is to insist on args in the aregs (i.e. a0 and a1) and have the fixup routines expect args there and promise to deliver in a0. With suitable reordings in the optimizers things like (+ x y z (- d e)) would get chained into operations using a0 as an accumulator. Here's a code seqence then: (move a0 countreg) ((move w) a0 scratchreg) ((or w) a1 scratchreg) ((and w) (word-constant 3) scratchreg) ((branch eq) ok) (fastcall sq-+) (jmp done) ok (add a1 countreg) ((branch vc) done) ; branch no overflow--codegen needs to learn these cc's (fastcall sq-overflow-+) done I think fastcalls are two instructions meaning 12 instructions, 7 of which get executed in the average case. THe word instructions might be more efficient as byte instructions but I don't remember. Depending on relative costs of branch/no-branch this might be made tenser too. ------- ∂03-May-85 0833 JK More arithmetic To: FTL, JLW ∂02-May-85 0900 @MIT-MC:BROOKS@MIT-OZ More arithmetic Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 2 May 85 09:00:27 PDT Received: from MIT-OZ by MIT-MC via Chaosnet; 2 MAY 85 11:58:58 EDT Date: Thu 2 May 85 11:45:48-EDT From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA> Subject: More arithmetic To: ejg@SU-AI.ARPA cc: jk@SU-AI.ARPA, rpg@SU-AI.ARPA I bet d4 and d5 never get used in regular code. The code sequence I sent last night could be tightened if there were some markable data registers, as for the fixnum case you'd like the things to be in data registers, but they also must be markable. (Actually I missed one instruction last night--to put the answer back in a0. That made it 8 instructions in the common case.) So perhpas one could make d4 and d5 a new class of registers --call them nreg's for number registers, or even two new classes each with just one register in it; e.g. nrega and nregb. This would require no change at all to the compiler, just a change to *registers*. Primops could reuest args in an nrega (if which there'd be only one anyway) and an nregb, and pass back there result in one of their argumnets whioch would always turn out to be the nrega (i.e. d4). Before doing this one would have to chack all existing runtimes (especially *&) to make sure they don't put unmarkable things in d4 or d5. I don't know whether this would uncover any insoluble problems. The link to the GC would have to be changed to make sure it thought that d4 and d5 were markable too. So now the code sequence, after argument set up in d4 and d5, becomes ((move w) d4 scratchreg) ((or w) d5 scratchreg) ((and w) (word-constant 3) scratchreg) ((branch eq) ok) (fastcall sq-+) (jmp done) ok (add d5 d4) ((branch vc) done) ; branch no overflow--codegen needs to learn these cc's (fastcall sq-overflow-+) done And the result is in d4. That's 6 instructions executed when things turn out to be two fixnums. The overhead of getting things into d4 and d5 is no worse (in fact slightly better) than pushing things on the stack for a regular fastcall, and much better than for a regular procedure call. Now sq-+ etc. expect their args in d4 and d5 and return in d4. Optimizers can change argument orders and introduce reverse-minus, so that a chain of operations make use of d4 as an accumulator. All of the above is pretty minimal changes for 6 instruction generic arithmetic adds and subtracts in the most common case. It may even pay to make all numeric fastcalls obey this convention and go through the compiler and add a new sort of procedure call-- an arithcall (we already have three classes; inline-primop, fastcall and full-procedure-call). ------- ∂03-May-85 0835 JK GCs ∂02-May-85 0902 @MIT-MC:BROOKS@MIT-OZ GCs Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 2 May 85 09:02:22 PDT Received: from MIT-OZ by MIT-MC via Chaosnet; 2 MAY 85 12:01:44 EDT Date: Thu 2 May 85 11:53:50-EDT From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA> Subject: GCs To: jlw@SU-AI.ARPA cc: eb@SU-AI.ARPA, rpg@SU-AI.ARPA, jk@SU-AI.ARPA I think the biggest determining factor on GC choice for the next two years or so (i.e. until every sun user has gobs of physical memory) will be compaction and GC time paging. I suspect the only way we will be able to get a good handle on those for any particular GC strategy is to implement it and benchmark like crazy. So my vote is to try both the ref count and the one I've just suggested as soon as we get breathing time to do it. The one advantage of my suggestion is that it woud take EB and RPG about a day to fully implement it and try it out, (as it really does hardly anything different from at the moment, just reorders thing sin time a little). Thus it might provide a short-term quick performance improver while we can do a hairer system over the longer period of time it will take. ------- ∂06-May-85 1028 JK tape ∂05-May-85 2254 @MIT-MC:BROOKS@MIT-OZ tape Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 May 85 22:54:43 PDT Received: from MIT-OZ by MIT-MC via Chaosnet; 6 MAY 85 01:55:20 EDT Date: Mon 6 May 85 01:55:47-EDT From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA> Subject: tape To: jk@SU-AI.ARPA, rpg@SU-AI.ARPA I am sending you a tape with the improved recursion, 'fast option, and bug fix for the case of closures Chris Wright tickled. The closures still do too much consing sometimes. I have a scheme to make it all good by removing the s-1 style closures and using only shared cons cells (the copy-procedure can be delayed till the last minute in that case), which will get around all the problems you have observed. I'll do that next weekend. ---- Change subject. I suspect a straight forward interpreter with an association list for an environment would be much better the current set up--sure it would do consing for variable binds, but nothing like the current set up. Also having the code disappear is most upsetting. People like to look at the code with symbol-function. If you have anything like the current situationI predict we will lose big. People will not like it--they will try it and claim it is totally bogus. They will be correct. ------- ∂06-May-85 1032 JK Re: some to be done's ∂05-May-85 1644 @MIT-MC:BROOKS@MIT-OZ Re: some to be done's Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 May 85 16:44:01 PDT Received: from MIT-OZ by MIT-MC via Chaosnet; 5 MAY 85 19:41:15 EDT Date: Sun 5 May 85 19:41:42-EDT From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA> Subject: Re: some to be done's To: JK@SU-AI.ARPA In-Reply-To: Message from "Jussi Ketonen <JK@SU-AI.ARPA>" of Sun 5 May 85 16:02:00-EDT (1) I'll try. I can make multiple-value-call quite good in the case that there is only one argument form'' (it might produce multiple values of course). More than one form and multiple-value-prog1 are both tough because the compiler expects to know the stack height all the time, so the values can't be stashed on the stack.... (2) I'd like to see the source of Chris's code to know just what is happening. It is not necessarily true that all closures are consed on entry to a function. (I don't understand the reference to acons at all--according to my manual it is written (defun acons (x y a) (cons (cons x y) a)).) (page 279) [(3) Maybe Chris should write better code. Closures are never going to be free.] ------- ∂06-May-85 1033 JK ∂05-May-85 1602 JK some to be done's To: ROD@SU-AI.ARPA, JK@SU-AI.ARPA (1) We don't yet have multiple-value-prog1 and multiple-value-call in the compiler other than as compiler macros. These should be done somewhat better (2) Chris wrote member and assoc using closures and special casing eq. The result was an incredibly slow acons; when the body of the function is entered, apparently all closures are consed regardless whether they are used. Is it possible to improve this somewhat? ∂06-May-85 1040 JK Re: some to be done's ∂05-May-85 1644 @MIT-MC:BROOKS@MIT-OZ Re: some to be done's Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 May 85 16:44:01 PDT Received: from MIT-OZ by MIT-MC via Chaosnet; 5 MAY 85 19:41:15 EDT Date: Sun 5 May 85 19:41:42-EDT From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA> Subject: Re: some to be done's To: JK@SU-AI.ARPA In-Reply-To: Message from "Jussi Ketonen <JK@SU-AI.ARPA>" of Sun 5 May 85 16:02:00-EDT (1) I'll try. I can make multiple-value-call quite good in the case that there is only one argument form'' (it might produce multiple values of course). More than one form and multiple-value-prog1 are both tough because the compiler expects to know the stack height all the time, so the values can't be stashed on the stack.... (2) I'd like to see the source of Chris's code to know just what is happening. It is not necessarily true that all closures are consed on entry to a function. (I don't understand the reference to acons at all--according to my manual it is written (defun acons (x y a) (cons (cons x y) a)).) (page 279) --------------- I meant assoc; chris's assoc falls into closure stuff after it has done eq tests on #'eql; otherwise assq is called. [(3) Maybe Chris should write better code. Closures are never going to be free.] ------- ∂06-May-85 1040 JK CL bogosity ∂05-May-85 2247 @MIT-MC:BROOKS@MIT-OZ CL bogosity Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 May 85 22:47:24 PDT Received: from MIT-OZ by MIT-MC via Chaosnet; 6 MAY 85 01:46:26 EDT Date: Mon 6 May 85 01:46:53-EDT From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA> Subject: CL bogosity To: jk@SU-AI.ARPA cc: rpg@SU-AI.ARPA, eb@SU-AI.ARPA Jussi, I tracked down the problem with the go out of a closure and the bug turns out to be in code you wrote! I cc'ed RPG and EB on this because its resolution involves issues in interpreter semantics and language definition! The code you had was (defun return13 () (block as ...)). When I removed the outer block and changed the (return-from as ...)'s to (return-from return13 ...) everything worked fine--it compiled and the go out of the closures worked at runtime. When I tried to compile you code directly I got a message named BLOCK not supported''. This is from the Franz block macro. The problem is that to wrap the implicit return13 block around the supplied body it is necessary to pull out any declarations first and put them outside. This is done with JK's code parse-body. Called in /mods/functions/common/compmacs.lisp. The current CL definition says that macros can expand to declarations so parse-body uses macroexpand to macroexpand away at the first forms before doing the wrapping. Unfortunately macroexpand in the compiler is the wrong thing (should be compiler-macroexpand) as it gets the host's macro definitions. [I am slightly confused--earlier in the file you had similar block constructs. If I compile them they barf. I assume you can compile them, otherwise you would have complained. Therefore I guess you must be using the 3600, and somehow its block macro ddidn't screw you on those cases, but who knows what code you were compiling and testing...] Where does interpreter semantics come in? Well I think the current setup (/mods/controlmacro/definers.lisp for the interpreter) which does the same deal is wrong. Any macro which happens to be at the start of a code body is currently getting expanded only once (unless Jussi you are unrolling if there is no declare, but in that case there will be a macro expansion both at defun time and run time), and further more consider this case: (defun frotz () (declare (special x)) x) (defun foo (x) (declare-macro x) (frotz)) (defmacro declare-macro (var) (declare (special ,var))) (defun bar (x) (declare-macro x) (frotz)) which should give different results for foo and bar under the current scheme. [I tried it and they actually both give the same bizzarely wrong results and the results change the second time you try it---the current interpreter seems unuseable to me with the compiling crap. You can't even see the lisp code and it changes out from under you.] ...so I don't understand what is currently happening in the interpreter but it will be hard to fix in any case. As it happens this has been the subject of an all day debate on the CL mailing list today. Most people seem in favor of flushing the ability of macros to expand to declares, due to the gross inefficieny it causes in interpreters that do it right (have to memoize the first call, or not make the implicit block explicit, or something). I recomend flushing this feature from LCL, and voting in the current debate to have it flushed. I will have to change one place in the compiler too. As for the more immediate problem of making your example work, Jussi, I guess you have to somehow signal to parse-body to use the compiler-macroexpand, maybe by checking in parse-body whether the *inside-the-compiler* switch is set. Rod ------- ∂07-May-85 1437 JK ∂06-May-85 2346 FY Re: summer jobs [Reply to message recvd: 30 Apr 85 16:41 Pacific Time] At this point in time, I'd certainly like to come and talk to you. I really am not sure whether what I'm looking for is full time work or, more likely, part time consulting'' while I do desparately needed thesis catchup work. Should I call you to arrange sometime convenient for me to come by? Thanks. -- Frank ------------ Yes. I was thinking in terms of full time for the summer, but there may be other possibilities. ∂07-May-85 1438 JK ∂04-May-85 2145 ROD improved compilation To: RPG, JK, EJG, EB I have just done two things to the compiler: 1. Made it smarter about code for a recursive call to self in a non-tail position, when the function takes a fixed number of arguments. Cuts the function call overhead from 12 to 6 instructions executed. 2. Added an option 'fast which generates fixed number of argument function entries with no arg count checking. This takes two instructions off (of execution). It should only be used when you know the program is correct. (RPG's message to SUN prompted me to think about this one.) You might try compiling the GC with this option on (but make sure the user interface functions don't get compiled this way), and any other time critical pieces of lisp code. This option has no effect when case 1 above is happening. I tried this out on tak, and used my watch to time it over ten runs. I consistenly got 1.85 secs. This compares to 2.26 before, 2.35 for Franz with all the stops out, and 1.44 for PSL. In looking at the code I can't see how to get closer to PSL without passing args in regs rather than on the stack. (the 'fast option saves a total of two instructions being executed for the whole of (tak 18 12 6) in this case...) It's probably worth running the benchmarks through again, with and without the fast option (e.g. the fast option will help TAKR, but 1 above will not) ∂07-May-85 1900 JK ∂07-May-85 1427 JK ∂06-May-85 2346 FY Re: summer jobs [Reply to message recvd: 30 Apr 85 16:41 Pacific Time] At this point in time, I'd certainly like to come and talk to you. I really am not sure whether what I'm looking for is full time work or, more likely, part time consulting'' while I do desparately needed thesis catchup work. Should I call you to arrange sometime convenient for me to come by? Thanks. -- Frank ------------ Yes. I was thinking in terms of full time for the summer, but there may be other possibilities. ∂07-May-85 1900 JK trip ∂07-May-85 1456 @MIT-MC:BROOKS@MIT-OZ trip Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 7 May 85 14:56:09 PDT Received: from MIT-OZ by MIT-MC via Chaosnet; 7 MAY 85 17:45:49 EDT Date: Tue 7 May 85 17:33:42-EDT From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA> Subject: trip To: rpg@SU-AI.ARPA, jk@SU-AI.ARPA I have to be at Stanford Tuesday june 4th (afternoon) for JMM's orals. Currently plan to arrive Sunday eve and leave Tuesday eve. Can hack/whatever at Lucid. ------- ∂07-May-85 2002 JK Re: compiler bug ∂07-May-85 2001 @MIT-MC:BROOKS@MIT-OZ Re: compiler bug Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 7 May 85 20:00:58 PDT Received: from MIT-OZ by MIT-MC via Chaosnet; 7 MAY 85 22:58:49 EDT Date: Tue 7 May 85 22:57:50-EDT From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA> Subject: Re: compiler bug To: RPG@SU-SCORE.ARPA cc: jk@SU-AI.ARPA In-Reply-To: Message from "Dick Gabriel <RPG@SU-SCORE.ARPA>" of Tue 7 May 85 01:53:33-EDT This was not a subtle bug. Every time the value of a multiple-value-bind clause is let bound to a variable it puts it in the wrong place. I guess we've been lucky up until now... In anal-dispatch.lisp there is a function label-destinations with a big cond dispatch. In the case ((eq type 'multiple-value-bind) there is (if (eq 'stacktop wantloc) (frame ,(%anode-stack node)) wantloc) Change this to: (if (eq 'stacktop wantloc) (frame ,(1+& (%anode-stack node))) wantloc) i.e. change the frame location by one. ------- ∂08-May-85 0749 JK Re: compiler bugs ∂08-May-85 0652 @MIT-MC:BROOKS@MIT-OZ Re: compiler bugs Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 8 May 85 06:51:53 PDT Received: from MIT-OZ by MIT-MC via Chaosnet; 8 MAY 85 09:50:05 EDT Date: Wed 8 May 85 09:49:05-EDT From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA> Subject: Re: compiler bugs To: JK@SU-AI.ARPA In-Reply-To: Message from "Jussi Ketonen <JK@SU-AI.ARPA>" of Tue 7 May 85 21:14:00-EDT Maybe should should tell me exactly what you changed so I can keep my sources in step with yours. ------- Will send you a tape of the changes; the files that have changed are: alph-special, alph-lambda, alph-dispatch. Macrolet now works. We will rip out the macros-as-declarations junk. ∂09-May-85 0656 JK [Guy Steele <gls%AQUINAS@THINK.ARPA>: Macros -> declarations] ∂06-May-85 1047 @MIT-MC:BROOKS@MIT-OZ [Guy Steele <gls%AQUINAS@THINK.ARPA>: Macros -> declarations] Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 6 May 85 10:47:21 PDT Received: from MIT-OZ by MIT-MC via Chaosnet; 6 MAY 85 13:46:40 EDT Date: Mon 6 May 85 13:45:17-EDT From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA> Subject: [Guy Steele <gls%AQUINAS@THINK.ARPA>: Macros -> declarations] To: jk@SU-AI.ARPA Received: from MIT-MC by MIT-OZ via Chaosnet; 6 May 85 11:47-EDT Received: from SU-AI.ARPA by MIT-MC.ARPA; 6 MAY 85 11:47:14 EDT Received: from THINK.ARPA by SU-AI.ARPA with TCP; 6 May 85 08:45:14 PDT Received: by THINK.ARPA with CHAOS id AA14271; Mon, 6 May 85 11:43:25 edt Date: Monday, 6 May 1985, 11:43-EDT From: Guy Steele <gls%AQUINAS@THINK.ARPA> Subject: Macros -> declarations To: common-lisp@sail Cc: gls%AQUINAS@THINK.ARPA Message-Id: <850506114342.2.GLS@DESIDERIUS.THINK> I would be not at all unhappy if this feature were to go away. I agree that Scott's assessment that it is unlikely that any existing code (outside of diagnostic tests for this very feature) would be harmed. I am persuaded not at all by the argument that it is hard to implement. I am mildly swayed by the efficiency considerations for the interpreter. The convincing point to me, however, is that the facility is likely to confuse macro-writers (who do, indeed, frequently find it necessary to find the division point between declarations/documentation and body). As a proposal separate from the question of eliminating the expansion of macros into declarations, I suggest the following primitive for consideration: PARSE-BODY list The list is treated as a body (a list of forms) that may have declarations and a documentation string at its head. Three values are returned. The first is some tail of the list, the executable part of the body. The second value is a list of declarations (lists whose car is DECLARE) at the head of the body. The third value is the documentation string, or NIL if there was no documentation string. --Guy ------- ∂16-May-86 0807 JK olin shivers ∂15-May-85 1952 FAHLMAN@CMU-CS-C.ARPA olin shivers Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 15 May 85 19:52:14 PDT Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 15 May 85 22:50:49-EDT Date: Wed, 15 May 1985 22:50 EDT Message-ID: <FAHLMAN.12111346026.BABYL@CMU-CS-C.ARPA> Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA> To: Jussi Ketonen <JK@SU-AI.ARPA> Subject: olin shivers In-reply-to: Msg of 15 May 1985 20:24-EDT from Jussi Ketonen <JK at SU-AI.ARPA> Jussi, I've never worked with Olin, so the following is based on just a few conversations and looking at some stuff he has done. I would hate to think that what I say is going to be decisive, since it is based on superficial interactions. Please check with people he has actually worked with Olin to get the real scoop -- I assume he has given you some names. OK, so much for disclaimers... I think that Olin is very good technically. He has knocked off his quals here easily. He has done a fair amount of work in T Lisp and my impression is that he produces excellent, well-designed code at a good rate (though I've only seen a few small samples). He is very self-confident in technical matters, and would probably not be afraid to tackle some truly evil problem for you. He taught a Lisp mini-course here and decided to teach it like a Yale course: make it VERY difficult, tell people up front to expect that, and give all the survivors a good grade. I think only one person dropped out and the others, after bitching all term, gave him very high feedback. Personally, I think Olin would be pretty abrasive to work with, though not too bad just to have around. I don't think it ever occurs to him that he might be wrong about something or that some opposing position might have merit. I haven't hung around Lucid enough to know whether this would "fit in", but I doubt it. He wouldn't be disruptive, but I don't think he'd be just one of the gang. The bottom line is that I think he could be of real value to you working alone on some really tough problem, or perhaps working with one other person if that person is sufficiently high-powered and assertive. I wouldn't give him anything too routine to do. I would not team him with anyone who is not first-rate, and would certainly not put him into a group where he would be a small cog implementing someone else's design. Olin might tend to mellow over time, once he decides he doesn't have to prove himself to everyone on a daily basis, so getting your hooks into him early could be a good investment. -- Scott ∂23-May-85 1612 JK ∂23-May-85 1109 ROD status Jussi, Here's waht I plan to work on next: 1. tailmerging of arbitrary function calls (e..g foo calls bar in a tail place). 2. open codeing funcall and maybe apply. 3. error handlers for incorrect go's and return-from's out of lexical closures. 4. figuring out better when a progv is only returning a single value, and so tightneing up the generated code considerably. EB thinks that 1 and 2 will have significant impact on the interpreter and on faslin. The window inspector seems a constant distance away--maybe you should put someone in Palo Alto onto it to guarantee it for IJCAI. Rod ------------------------ Sounds great; maybe you should continue working on the compiler for the foreseeable future. Other items that we have to address on this line are: (1) Register allocator --- we need this for non-68k machines (2) Peep hole optimizer (3) PDL's for floats, in case we decide to get serious about this. Might interact with some TNBIND'sh thing. ∂23-May-85 1613 JK ∂23-May-85 1455 ROD potential summer employee To: RPG, JK Patrick Sobalvarro is looking for a summer job. He is an undergrad, a lab employee, and works at Terrapin part time. He has written most of the good Logo systems that are around. He would like to earn on the order of 10k for the summer. Mail to PGS@mit-mc if interested in more details. (He is not a undergrad age--he came back to school recently after hacking for a while.) ---------------- Would you recommend him? How good of a Lisp hacker is he? Would he fit in with the rest of us? ∂23-May-85 1619 JK compiler To: ROD@SU-AI.ARPA, FTL@SU-AI.ARPA Some other issues: (1) The tail recursion removal should be done under some flag--- speed/safety switches in common lisp (eb has some ideas here, I understand) (2) Perhaps most important from the point of view porting is removing extraneous dependencies on 68k from codegen. ∂07-Jun-85 1515 JK summer jobs ∂30-May-85 0651 @MIT-MC.ARPA:PGS@MIT-OZ summer jobs Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 29 May 85 20:07:03 PDT Received: from MIT-OZ by MIT-MC via Chaosnet; 29 MAY 85 23:07:49 EDT Date: Wed, 29 May 1985 23:08 EDT Message-ID: <PGS.12115019341.BABYL@MIT-OZ> From: PGS%MIT-OZ@MIT-MC.ARPA To: Jussi Ketonen <JK@SU-AI.ARPA> Subject: summer jobs Hi. I would indeed be interested in a summer job at Lucid. I'm currently working at the AI Lab and wondering how I'm going to pay next year's tuition on what MIT pays its research staff. I'm including a copy of my resume below. I'm just finishing a major project for Terrapin. Allowing two weeks of slop for extraordinary occurrences, I'd be able to start on July 1, and I'd have to come back to school here around September 11. I'm not too sure what people do when they work for a summer, not having done that much, so I don't know if that's too short a period. Certainly I can imagine doing useful work in that period. As to interests, well, I'm thinking of doing a thesis on language design for highly parallel machines, but I haven't done any work in that area yet and you're a Common Lisp company, so I don't know how much that counts for. I've done things like write interpreters and storage management stuff like garbage collectors, and I'd be happy to do anything along those lines. Rod tells me that your implementation is pretty much written, though, so I'd be interested in working on just about anything you've got; for example, if you needed something along the lines of DEFSYSTEM, to supplement this module stuff that's in Common Lisp, I could do something like that in part of the time I was there, or if you have dead bears lurking in your code (like if you've always planned to rewrite your fasloader or the package system, or whatever), I could do stuff like that. I'm pretty flexible -- I would even be willing to work on interfacing to various operating systems (although I don't feel as enthusiastic about that). Because I have to go back and forth a lot between Terrapin and MIT right now, it might be hard to reach me on the phone. My home number is 864-4049; my MIT office number is 253-5834, and I can be reached at Terrapin at 492-8816. I'm usually at Terrapin at night. All these are in area code 617. Here's my resume: PATRICK G. SOBALVARRO 1010 Massachusetts Avenue Apt. 1B Cambridge, Massachusetts 02138 Home: (617) 864-4049 Work: 253-5834 Born July 21, 1959 Citizenship: U.S. Career objective: research in artificial intelligence EDUCATION 1984- MASSACHUSETTS INSTITUTE OF TECHNOLOGY CAMBRIDGE, MA. Continued undergraduate education. I am currently a senior in computer science. Courses taken include the graduate core courses in programming languages, computer architecture, and artificial intelligence. 1977-1979 MASSACHUSETTS INSTITUTE OF TECHNOLOGY CAMBRIDGE, MA. Two years as undergraduate in mathematics. Courses taken include mathematical logic, recursion theory, mathematical analysis. Extracurricular activities include: chairman of student steering committee (CICDO) of the Experimental Study Group, 1977 - 1978; staffer on Nightline, the MIT student peer help service, 1978 - 1979; member of Judo Club, 1977 - 1979. 1973 - 1977 EPISCOPAL CATHEDRAL SCHOOL SANTURCE, P.R. Valedictorian; Student Council President; National Honor Society; National Merit Scholar, 1977. EXPERIENCE February 1982 - present Research specialist, MIT Artificial Intelligence Laboratory. Designed and implemented an innovative control system for the Unimation Puma 600 industrial robot arm, in PDP-11 assembly code and Lisp Machine Lisp. This robot control system was, to the best of our knowledge, the first ever to work over a local network. Systems programming for various operating systems: ITS, an operating system for the PDP-10; MINITS, an operating system for PDP-11s. Occasionally worked on maintenance of the Lisp Machine operating system. Did maintenance, configuration, and installation of Chaosnet and Ethernet hardware; supervised technicians in installation and testing of Lisp Machines. ! - 2 - September 1981 - January 1982 Software engineer, Terrapin, Inc. Worked on readying MIT's Logo for the Apple II for market. March 1980 - August 1981 Sponsored research staff programmer/engineer, Logo Group, MIT Artificial Intelligence Laboratory. Worked on the implementation of the Lisp-like programming language Logo for the Apple II, in 6502 assembly code. I also wrote for this version of Logo a screen editor implementing a subset of Emacs. CONSULTING June 1984 - June 1985 Designed and implemented a portable Logo interpreter, written in C, for Terrapin, Inc., of Cambridge, Massachusetts. This is the most ambitious implementation of Logo by anyone to date; it includes a copying garbage collector, arrays, strings, streams, immediate fixnums, and optimal tail-recursion optimization (Logo is a parsed Lisp-like language with dynamic scoping; determining when tail-recursion optimization is possible can be difficult). It currently runs under Unix, on the Apple MacIntosh and on other personal computers. June 1983 - March 1985 Designed a Logo interpreter for Itautec of Sao Paulo, Brazil, and travelled to Brazil three times over a period of about a year to teach and supervise its implementation by a team of programmers. The interpreter runs on Itautec's own Z80-based personal computer. BACKGROUND I was born in El Salvador, and grew up in Puerto Rico. While Spanish was my first language, I have native-speaker fluency in English. I have experience programming in Lisp, many other high-level languages, PDP-10, PDP-11, 6502, and Z80 assembler. INTERESTS Some of the problems I find interesting currently are the implementation of Lisp and Lisp-like languages, and the implementation of operating systems. My other interests include: sports cars, backpacking, travel, and modern British poetry. ! - 3 - References will be provided upon request. ! ∂11-Jun-85 1758 JK Dear Pat -- This is to confirm our conversation last week. Lucid will pay for your airfare and$3500 a month for a period starting
July 1 and ending approximately September 15.
It seems that we would like you to work on our Common Lisp
interface to window systems; currently we are planning on a two-track
approach: First, a fairly quick job using SUN windows and
foreign function calls. Secondly, a more Lisp-like system with
several levels of window-manipulation primitives. It would
be nice if the first approach would not be completely throw-away.
The first goal is necessary for IJCAI and several AI companies who
want to put up their system ASAP. We would like to approximate
Interlisp-D functionality for window systems, as specified in
section 19 of the Interlisp-D manual. Another nice reference
to look at is the SUN windows manual. If you would like to
study these issues in advance, we could send copies of the
relevant materials. I would like you to work on this system
together with Zach Smith, a new addition to our full-time
technical staff. He has quite a bit of experience in C and graphics,
but none in Lisp.

Best regards,

Jussi

∂13-Jun-85  0746	JK
∂12-Jun-85  2116	@MIT-MC.ARPA:PGS@MIT-OZ
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 12 Jun 85  21:16:13 PDT
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 13 JUN 85  00:15:07 EDT
Date: Thu, 13 Jun 1985  00:12 EDT
Message-ID: <PGS.12118700936.BABYL@MIT-OZ>
From: PGS%MIT-OZ@MIT-MC.ARPA
To:   Jussi Ketonen <JK@SU-AI.ARPA>
In-reply-to: Msg of 11 Jun 1985  20:57-EDT from Jussi Ketonen <JK at SU-AI.ARPA>

That's my understanding of our agreement, except that I may have to leave
just a bit earlier -- I believe school starts here on September 11th.  I'll
check on that.  I'm also still considering driving out there -- were I to do
that, could I present gas receipts, or something?  My car is a Datsun; it
ought to be reasonably gas-economical, and probably cheaper than airfare.

Working on a window system sounds fine to me.  There aren't any SUN or
Interlisp-D manuals around here, and I would like to look at them as soon as
possible, so copies of the relevant sections would be great.

Incidentally, do you have flavors, or some sort of hierarchical object-
oriented class system?  I'm not religious, I was just wondering what the
implementation technology for the second-level (more Lisp-oriented) window
system would be.
----------------
Driving out here is fine, too. Keep some set of receipts (lodging, gas, etc)
so we can justify it in our books. My only concern here is time --- you will
be here July 1st, right?

I'll try to get some documentation asap --- we expect to have flavors in
JK

∂13-Jun-85  0750	JK   	declaration pervasiveness.
∂12-Jun-85  1704	@MIT-MC.ARPA:BROOKS@MIT-OZ 	declaration pervasiveness.
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 12 Jun 85  17:04:32 PDT
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 12 JUN 85  19:46:52 EDT
Date: Wed 12 Jun 85 19:44:14-EDT
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: declaration pervasiveness.
To: common-lisp@SU-AI.ARPA
cc: jk@SU-AI.ARPA

I'm having trouble deciding exactly how pervasive certain declarations
are. For instance:

(defun f (n)
(flet ((f (m) (* m m)))
(declare (ftype (function (integer) integer) f))
(declare (notinline f))
(+ (f n)
(flet ((f (m) (bar m m)))
(f n)))))

By analogy to type it would appear that the ftype declaration applies
to the call to the (* m m) f, but not to the (bar m m) call. There is
specific language in the first paragraph of page 159 that implies
that. However notinline , which has precisely the same language
applied to it at the top of page 160, is earlier singled out has
having nothing to do with bindings and being pervasive on page 155.

So does the notinline apply to the call to the (bar m m) version or
not? If not, then page 155, and the notion of pervasiveness seem
-------
∂13-Jun-85  0254	@MIT-MC.ARPA:BROOKS@MIT-OZ 	done
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 13 Jun 85  02:46:55 PDT
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 13 JUN 85  05:46:59 EDT
Date: Thu 13 Jun 85 05:44:21-EDT
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: done
To: jk@SU-AI.ARPA

Well the sun is shining here, but I think I'm done sort of.

Read the file install--it includes some documentation on handles into
the environment structure. Also logger and bugs contain bits and pieces.
There are 13 files to be integrated at LIHQ (plus a back up of the old
closure code in case we panic and fall back to that).

All declarations and proclamations re now handled, as is the' and
locally'. I have observed it not inline code CAR, and infer that
in (declare (type fixnum a b)) (if (>& a b) a b) the if always returns
a fixnum. (With no AND in the type mind you!)

There is one known problem (CONS and some other insist on inline coding--
I'm sure the fix will be quit localized in the analysis phase and you
can wait a few days for it.)

I have not had a chance to do two much testing. Also the data base
is not complete (in the fdesc's). Additionally by the time I load
all my patches in there is so mauch dynamic space gone, things
become fairly slow.

I'll be in my office late afternoon if you want to talk. I'll send
the tape out today.
-------

∂13-Jun-85  0751	JK
∂12-Jun-85  1320	ROD  	jump bug?
Breaking the function up into smaller pieces fixed it. I eyeballed
the lap code and transformations and it all seemed ok, so I suspect
the assembler or loader. I will include the big version of the function
on the tape.

∂17-Jun-85  0807	JK
∂16-Jun-85  2347	ROD  	progress
I have:

o fixed some constant folding bugs EB pointed out.

o realized that we don't need to propagate types across let vars
in the short term at all--even for the primop case as there will
be no opitmization to be done there.

o hacked on getting ignore to work right. I've made changes in 8 files
already, and 2 more to go.

I can't do anymore tonight. My current plan is to finish it Tuesday
evening so it will be in your hands Thursday morning. EB tells me
beta test has slipped a week--I hope that is accurate.

I will also fix the cons not compiling out of line problem on
Tuesday.

∂21-Jun-85  0951	JK  	tape
To:   ROD@SU-AI.ARPA, FTL@SU-AI.ARPA
Have integrated your stuff with the little bit of mine
needed and it seems fine.
Will send you a tape today with a binary, compiler directory
and types directory.
(1) Had to change subtypep considerably since t no longer
contains all types. Also, there is a file called
typedispatch under /functions/utilities. Rewrote
project-type, and-type and or-type.
(2) the files alph-special, anal-tools have changed somewhat
(3) the file anal-procall has changed a lot, check it out
with the examples for dispatch-test.lisp under utilities
(4) macrology seems somewhat broken ---- beware of compile.lisp
which eb has also hacked. jonl got some pdl overflows.

∂23-Jun-85  0912	JK
∂22-Jun-85  2023	ROD  	bignum-decls
To:   JLW
CC:   JK
There are some bugs in ther version of bignum-decls which JK sent to me.

1. In additive-overflow-p there are two scoping problems with SPOSITION.
First there is ,(1+& SPOSITION), but SPOSITION is not bound at macro
expansion time--it is a variable that occurs in the resulting code.
Second, SPOSITION is used twice in the resulting code in positions
outside of the scope of the let that defines it.

2. In bignum-div-step variable carry-out is bound but unused whereas
borrow-back is used free. I suspect these should have the same name.

3. A bunch of &rest args are called IGNORE and are ignored. They should
have (declare (ignore IGNORE)) done to them.

4. The defconstant for fixnum-bucket-index through macro expanding
bn-temp-bucket-index causes eval to call integer-length&,
but that is not defined in lucille.

There is also a place where the compiler has a problem: in
mul-by-abigits-per-word -- I'm tracking that down.

∂27-Jun-85  0802	JK
∂26-Jun-85  2318	ROD  	unwind-protect/catch/progv fix
Here is a fix which has certain virtues, the main one being it replaces
a current error message by some code. That means it can break nothing

In the longer term I think it is not the correct'' fix. If you thought
analyze-primop was bad then don't look at coerce-loc-and-rep (it started
out as a 20 line function, honest). It needs to be completely rewritten
and de-68000-ized. For this particular bug I think label-destinations
and the code generators for the three forms need to be upgraded.
In general I think label-destinations is currently a source of
much inefficincy in generating uselss multiple value code for
the three special forms in question. So probably I should tackle
all three of these in the cleanup task that's on my list. However,
big test files would be really helpful. I don't expect the task to
be either quick or painless.

Anyway here's the fix. In code-coerce.lisp in function coerce-loc-and-rep
find again the generator of the error message (its right after
a cond clause (eq 'stacked novals) and is followed by a bunch
of commented code. Remove the error mesage line and the comments
from the following code. Then make the following two changes:

In:
(emit deflap
(move (frame ,stackh) mtempreg)
change to:
(emit deflap
(move (frame ,(1+& stackh)) mtempreg)

then after:
(emit deflap label)
insert the following lines:
;; this must have come from catch/progv/unwind-protect
(emit deflap

Take an asprin and call me in the morning if you still have problems.

∂26-Jun-85  2337	ROD  	ps
That last line of code should have closed with ))), closing the (emit.

∂30-Jun-85  0940	JK
∂30-Jun-85  0845	ROD  	tape
No tape showed up so I assume you didn't send one. To avoid vthe introduction
of version skew I'm working on the following things this weekend (won't
finish them all, or probably any):

o Documneting the virtual machine'' specified in lap-library-68k so
that new versions can easily be written for new architectures.

o Writing a new code-coerce that is cleaned up and documented, and contains
the necessary hooks and extensibility for pdlnums etc., besides getting
rid of 68k dependencies (most of the code generators 68k dependencies are
in this file).

o Redoing the primop stuff so that more general register class specifications
can be done (e.g. (not areg)) and so that primop's can return multiple
vaslues as per JLW and EB's requests.

Actually I probably won't even get to start the third item this weekend.
---------------

Right --- things are a bit chaotic around here.
I would like to send another tape some time in the middle of next week.
I have modified defforms somewhat.
EB fixed a bug involving folding of constants in multiple value situations.

One needs to do the same kind of type dispatching in anal-primop
as in anal-procall. For example, + would like to turn to +& and it is
a primop. This points out a general difficulty in the current setup:
If it were possible to get at the list of subnodes (new slot in %anode?)
one could pull the silly type dispatch stuff from anal-procall
and do it more top level for both anal-procall and anal-primop
instead of decorating the body of analyze-primop with yet more code.

JK

∂07-Jul-85  1232	JK
To:   ROD@SU-AI.ARPA, FTL@SU-AI.ARPA
Here's the other bug:

(defun foo (mnode1 mnode2 uvars constr alst)
(let ((lst1 (bxvars-of mnode1)) (lst2 (bxvars-of mnode2)))
(foo (bxmnode-of mnode1)
(bxmnode-of mnode2)
uvars
constr
(nconc (pairup lst1 lst2) alst) )))

this causes the generation of dotted lists thru analyze-extract-all-variable-refs
; loser is the end of the list. On the SUN this may never be
noticed since our memq (which was the function that blew up)
ignores the end of dotted lists.

proposed fix: as the first cond clause in the analyze ----- function have:
((eq refs 'loser) 'loser)

JK

P.S. the other bug seems to happend whenever a primop applies to
a special.
By the way, EKL now runs in LCL
>

∂15-Jul-85  0746	JK   	flavors
∂12-Jul-85  1250	FAHLMAN@CMU-CS-C.ARPA 	flavors
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 12 Jul 85  12:50:25 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 12 Jul 85 15:50:57-EDT
Date: Fri, 12 Jul 1985  15:50 EDT
Message-ID: <FAHLMAN.12126473946.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Jussi Ketonen <JK@SU-AI.ARPA>
Subject: flavors
In-reply-to: Msg of 12 Jul 1985  13:30-EDT from Jussi Ketonen <JK at SU-AI.ARPA>

Jussi,

We've got mail crossing every whichway, since RPG answered my note to
you and I sent a reply to him.  I'll send you a copy of that.
Basically, Dick asked what I thought was fair with respect to Skef
Wholey and Rob Maclachlan, and I proposed something.  I don't know if it
will run afoul of the various constraints on stock.  I hope you folks
have not painted yourselves into a corner where stock can only be
offered to people who are working for you full-time.

Thanks for the invitation to visit Lucid.  I'd like to do that sometime
soon, just to stay in touch with what's happening out there.  However, I
will be spending two weeks in Austria starting July 20, and then about
the time I've recovered from that trip it's off to IJCAI for me and
presumably also for most of the Lucidites.  For various reasons, I can't
really stretch the IJCAI trip.  I super-quick trip could be scheduled in
between there sometime, but that probably wouldn't accomplish anything
that couldn't be done by phone or mail, so it looks like sometime in
September is our best bet.  I'll probably see you folks at IJCAI, and we
can discuss it then.

As I told Dick, I think that both Rob Maclachlan and Skef Wholey would
be valuable to you as occasional consultants.  Steve Handerson will be
leaving the Spice Lisp project in September (the money that was paying
for his slot has run out), so you could consider hiring him full-time,
but I'm not sure he'd make it in a tight-deadlines company like Lucid.
Steve occasionally has a good month and has written some very nice
chunks of code for us, but then he'll have a month or two when he
doesn't do anything at all except play games and walk around looking
stoned.  He's just not very reliable.  It may be that with some
different kind of management Steve would turn into a winner, but he just
doesn't seem to thrive under the loose structure of the Spice Lisp
group, and he says he doesn't want to work under any tighter control.

-- Scott

∂16-Jul-85  1303	F.DUFFIE@SU-GSB-WHY.ARPA 	Re: TeX index macros
Received: from SU-GSB-WHY.ARPA by SU-AI.ARPA with TCP; 16 Jul 85  13:03:07 PDT
Date: Tue 16 Jul 85 13:01:47-PDT
From: James Duffie <F.DUFFIE@SU-GSB-WHY.ARPA>
Subject: Re: TeX index macros
To: FTL@SU-AI.ARPA
In-Reply-To: Message from "Lucid <FTL@SU-AI.ARPA>" of Tue 16 Jul 85 11:34:00-PDT

For you, Virginia, any time is fine. How about tomorrow other than
10-12:30. If you want to meet for lunch, say 1:15 PM at the faculty club?
Would you let me know? My number here is 497-1976. You can leave a
message if I'm not in. IMSSS is keeping me out of  the office a lot.
I have some new reading recommendations.

tovarich D.
-------

∂17-Jul-85  1639	F.DUFFIE@SU-GSB-WHY.ARPA 	TeXmacros to Virginia Kean
Received: from SU-GSB-WHY.ARPA by SU-AI.ARPA with TCP; 17 Jul 85  16:39:35 PDT
Date: Wed 17 Jul 85 16:38:11-PDT
From: James Duffie <F.DUFFIE@SU-GSB-WHY.ARPA>
Subject: TeXmacros to Virginia Kean
To: ftl@SU-AI.ARPA

OK Virginia; I got this to work. (My pride was at stake!)
Just put

\input kean.tex

at the beginning of your file. Then ↑{object} sends objext to index.tex
and ~{object} sends object to gloss.tex.
I presume ↑↑{ } and ~~{ } are the silent versions.

I'll attach kean.tex to this memo. Thanks for dropping over today. You are
always welcome.

Darrell
\def\up{↑}
\newwrite\inx %setup for indexing TeXbook, pp 423 - 424
\immediate\openout\inx=index % file for index entries
\newif\ifsilent
\def\specialhat{\ifmmode\def\next{↑}\else\let\next=\beginxref\fi\next}
\def\beginxref{\futurelet\next\beginxrefswitch}
\def\beginxrefswitch{\ifx\next\specialhat\let\next=\silentxref
\else\silentfalse\let\next=\xref\fi \next}
\catcode\↑=\active \let ↑=\specialhat
\def\silentxref↑{\silenttrue\xref}
\chardef\bslash=\\% \bslash makes a backslash
\def\xref{\futurelet\next\xrefswitch} % branch on the next character
\def\xrefswitch{\begingroup\ifx\next|\aftergroup\vxref
\else\ifx\next\<\aftergroup\anglexref
\else\aftergroup\normalxref \fi\fi \endgroup}
\def\vxref|{ }
\def\anglexref\<#1>{ }
\def\normalxref#1{\def\xreftype{0}\def\text{#1}\let\next=\text\makexref}
\newif\ifproofmode
\proofmodetrue % false at final stage
\def\makexref{\ifproofmode
\xdef\writeit{\write\inx{\text,\space\space\noexpand\number\pageno}}\writeit
\else\ifhmode\kern0pt \fi\fi
\ifsilent\ignorespaces\else\next\fi}
\newwrite\gls %setup for glossary: TeXbook, pp 423 - 424
\immediate\openout\gls=gloss % file for index entries
\newif\ifsilent
\def\specialtilde{\ifmmode\def\gnext{~}\else\let\gnext=\begglsref\fi\gnext}
\def\begglsref{\futurelet\gnext\begglsrefswitch}
\def\begglsrefswitch{\ifx\gnext\specialtilde\let\gnext=\silentgxref
\else\silentfalse\let\gnext=\gxref\fi \gnext}
\catcode\~=\active \let ~=\specialtilde
\def\silentgxref~{\silenttrue\gxref}
\chardef\bslash=\\% \bslash makes a backslash
\def\gxref{\futurelet\gnext\gxrefswitch} % branch on the next character
\def\gxrefswitch{\begingroup\ifx\gnext|\aftergroup\vgxref
\else\ifx\gnext\<\aftergroup\anglegxref
\else\aftergroup\normalgxref \fi\fi \endgroup}
\def\vgxref|{ }
\def\anglegxref\<#1>{ }
\def\normalgxref#1{\def\gxreftype{0}\def\gtext{#1}\let\gnext=\gtext\makegxref}
\newif\ifproofmode
\proofmodetrue % false at final stage
\def\makegxref{\ifproofmode
\xdef\writeit{\write\gls{\gtext,\space\space\noexpand\number\pageno}}\writeit
\else\ifhmode\kern0pt \fi\fi
\ifsilent\ignorespaces\else\gnext\fi}
-------

∂17-Jul-85  1754	F.DUFFIE@SU-GSB-WHY.ARPA 	Re: index macros
Received: from SU-GSB-WHY.ARPA by SU-AI.ARPA with TCP; 17 Jul 85  17:53:58 PDT
Date: Wed 17 Jul 85 17:52:33-PDT
From: James Duffie <F.DUFFIE@SU-GSB-WHY.ARPA>
Subject: Re: index macros
To: FTL@SU-AI.ARPA
In-Reply-To: Message from "Lucid <FTL@SU-AI.ARPA>" of Wed 17 Jul 85 17:43:00-PDT

A great pleasure.
d
-------

∂25-Jul-85  0849	F.DUFFIE@SU-GSB-WHY.ARPA 	doublecolumns macro
Received: from SU-GSB-WHY.ARPA by SU-AI.ARPA with TCP; 25 Jul 85  08:49:44 PDT
Date: Thu 25 Jul 85 08:48:48-PDT
From: James Duffie <F.DUFFIE@SU-GSB-WHY.ARPA>
Subject: doublecolumns macro
To: ftl@SU-AI.ARPA

What a subject for a memo! Good morning. I enclose the
doublecolumns macro and associated nonsense in the file col.tex, and
a sample input in the file sample.tex. My sample has specified an
eight point font; this is of course up to you and the fonts supported
at your facility. You do not need the other input files that I'm
using. Also note that with my version, as oppposed to the one you gave
me, you do not need to end a line of input with a period. A standard
index does not have periods in this fashion. You must, however, begin
and end the index entries as I have. In particular, don't forget
the }\endgroup at the end. You may want to play with spacing. Your
columns macro conveniently splits up a page properly even with
non standard \hsize and \vsize (I think).

Let me know if col.tex misbehaves.

Again, thanks for your help with this. Between the two of us, we're
making progress!

The Hers column in this morning's NYT is interesting.

Have a marvelous day.

Warm regards. Darrell
-------

∂25-Jul-85  0851	F.DUFFIE@SU-GSB-WHY.ARPA 	the files
Received: from SU-GSB-WHY.ARPA by SU-AI.ARPA with TCP; 25 Jul 85  08:50:51 PDT
Date: Thu 25 Jul 85 08:49:57-PDT
From: James Duffie <F.DUFFIE@SU-GSB-WHY.ARPA>
Subject: the files
To: ftl@SU-AI.ARPA

\newdimen\fullhsize
\fullhsize=\hsize
\newdimen\fullvsize
\fullvsize=\vsize
\catcode@=11
\newbox\partialpage
\def\begindoublecolumns{\begingroup
\output={\global\setbox\partialpage=\vbox{\unvbox255\bigskip}}\eject
\output={\doublecolumnout} \hsize=14pc \vsize=89pc}
\def\enddoublecolumns{\output={\balancecolumns}\eject
\endgroup \pagegoal=\vsize}

\def\doublecolumnout{\splittopskip=\topskip \splitmaxdepth=\maxdepth
\overfullrule=0pt
\setbox0=\vsplit255 to\dimen@ \setbox2=\vsplit255 to\dimen@
\onepageout\pagesofar
\unvbox255 \penalty\outputpenalty}
\def\pagesofar{\unvbox\partialpage
\wd0=\hsize \wd2=\hsize \hbox to\fullhsize{\box0\hfil\box2}}
\def\balancecolumns{\setbox0=\vbox{\unvbox255} \dimen@=\ht0
\divide\dimen@ by2 \splittopskip=\topskip
\global\setbox1=\vsplit3 to\dimen@
\setbox0=\vbox to\dimen@{\unvbox1}
\setbox2=\vbox to\dimen@{\unvbox3}
\pagesofar}

\rm\hfil\folio}}}
\ifnum\outputpenalty>-\@MM \else\dosupereject\fi}
\pageno=193
\centerline{\ti INDEX}
\bigskip
\font\eightrm=cmr8
\eightrm
\input thesis.def
\twosided
\newdimen\sqht \sqht=2.4pt % \square
\input col.tex
\begindoublecolumns
\baselineskip=9.9pt
\parskip=0pt plus 0.8pt
\begingroup \let\par=\cr \obeylines %
\halign{#\hfil
a.e.,  22
a.s.,  22
Aase,  158
Janich,  8
Kallianpur,  134
Karatzas,  158
Kennedy,  158
Klein,  112
random variable,  20
rank,  59
RCLL,  74
real security,  62
recession cone,  6
Reed,  33
refinement,  45
Revuz,  111
reward,  103
Riemann,  85
right--continuous filtration,  75
right--continuous,  74
right--limits,  74
Rishel,  144
risk tolerance,  166
Robertson,  8
root node,  54
Ross,  24,112,177
Royden,  33,85
Rudin,  24,49
Samuelson,  158
Savage model of beliefs and preferences,  25
Savage,  25
scalar multiplication,  2
scalar,  2
Schaefer,  8,33
Scholes,  90
Schal,  112
security price process,  115
security set,  33
security,  33,55,86
segment,  10
selector,  109
self,  5
self--financing,  91
semimartingale,  77
separable,  9
separated by a hyperplane,  18
Separating Hyperplane Theorem,  15
Sethi,  158
Shafer,  11,19,64
shareholder value,  66
Shiryayev,  134
Shreve,  112,158
sigma--algebra,  20
signum,  150
Simon,  33
simple process,  81
simple random variable,  22
single agent Markov equilibrium,  116
single--beta asset pricing model,  164
single--beta model,  165
Skorohod,  74
slack,  57,134
slack,  92
Sonnenschein,  19
span,  33
spanning number,  89
spanning,  87
spot price process,  54,85
square--integrable,  79
Standard Brownian Motion,  76
standard deviation of the market rate of return,  164
state process,  102,159
state space,  102
state--independent preferences,  25
state--independent,  25
stationary feedback control,  107
stationary infinite horizon discounted control problem,  104
stationary Markov control problem,  107
stationary reward,  106
stationary,  40
Stieltjes integral,  23
Stieltjes,  85
Stiglitz,  39,71
stochastic differential equation,  128
stochastic differential,  127
stochastic economy,  86
stochastic growth Markov control problem,  119
stochastic growth model,  118
stochastic integral,  79
stochastic process,  72
stock market equilibrium,  36
stopping time,  76
strict contraction,  109
strict order,  8
strict preference relation,  11
strictly convex,  10
strictly monotonic preference relation,  9
strictly positive continuous linear functional,  48
strictly price supported allocation,  12
strong continuous,  110
strongly convex,  10
Stroock,  134
sub--tribe,  45
Suchanecki,  49
sum of sets,  6
superdifferentiable,  43
support of the distribution,  27
symmetric difference,  49
Teicher,  24
term structure of interest rates,  172
terminal node,  54
the usual conditions,  75
Thompson,  112
tight,  92
time set,  71
Ting,  49
topological dual,  5
topological space,  6
topological vector spaces,  4
topology,  4
total consumption set,  16
total production set,  15
trace,  127
transition function,  106
transitive,  8
tribe generated,  21
tribe,  20
trivial tribe,  46,78
upper hemicontinuous,  105
upper semicontinuous correspondence,  105
upper semicontinuous,  105
utility function,  8
utility represention,  9
Vakhania,  49
value function,  100,107,138
value of the control problem,  103
value operators,  108
Van Vleck,  112
variance,  31
vector space,  2
vector subspace,  32
version,  22,79
von Neumann,  19
von Neumann--Morgenstern,  25
Wald,  112
Wald,  19
Walras,  19
Walrasian equilibrium,  13
weakly dominates,  14
weakly efficient allocation,  14
wealth process,  148,160
Werner,  63
Williams,  78,85,134
Wilson,  39
Yannelis,  19,52,90
Yip,  49
Yushkevich,  112
Zame,  19,52,90
zero,  2
}\endgroup
-------

∂26-Jul-85  1025	F.DUFFIE@SU-GSB-WHY.ARPA 	Re: index
Received: from SU-GSB-WHY.ARPA by SU-AI.ARPA with TCP; 26 Jul 85  10:25:20 PDT
Date: Fri 26 Jul 85 10:24:21-PDT
From: James Duffie <F.DUFFIE@SU-GSB-WHY.ARPA>
Subject: Re: index
To: FTL@SU-AI.ARPA
In-Reply-To: Message from "Lucid <FTL@SU-AI.ARPA>" of Fri 26 Jul 85 09:47:00-PDT

There's seems to be a big lag between sending and receiving. If you ever
need help in a hurry, perhaps you should call.

I can't really think of anything useful to say about the problems you're
having with doublecolumns. It works OK here. On the lines that are
too long for half a pagewidth, I had hoped that the macro would automatically
move to a new line and indent; it appears that it does not. Thus I will
be doing a little bit of manual adjustment before my last version. This
is a minor problem, for me at least.

Good luck with your extra work this weekend. I will be hibernating with my
own. There is so little time before I'm gone. I shall miss our
discussions.

Again, thanks.

Darrell
-------

∂26-Jul-85  1111	SCHERLIS@CMU-CS-C.ARPA 	Re: Lucid manual
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 26 Jul 85  11:11:40 PDT
Received: ID <SCHERLIS@CMU-CS-C.ARPA>; Fri 26 Jul 85 14:12:35-EDT
Date: Fri 26 Jul 85 14:12:30-EDT
From: Bill.Scherlis@CMU-CS-C.ARPA
Subject: Re: Lucid manual
To: FTL@SU-AI.ARPA
In-Reply-To: Message from "Lucid <FTL@SU-AI.ARPA>" of Fri 26 Jul 85 10:53:00-EDT

Virginia --
Thanks for your note.  I'll send a sketch of a sample session in
the next few days.  I'll also send along the usual collection of nits
picked from the present edition.
Do you know if Steele has an errata list for the CLM (and a new
index!) that we could distribute with our documentation?  That, together
with our document, would make our software worth purchasing for the
documentation alone.
Bill
-------

∂02-Aug-85  0702	SCHERLIS@CMU-CS-C.ARPA 	documentation notes
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 2 Aug 85  07:02:42 PDT
Received: ID <SCHERLIS@CMU-CS-C.ARPA>; Fri 2 Aug 85 10:04:43-EDT
Date: Fri 2 Aug 85 10:04:42-EDT
From: Bill.Scherlis@CMU-CS-C.ARPA
Subject: documentation notes
To: ftl@SU-AI.ARPA

Virginia --
I must apologize, but events here have prevented me from getting
my comments off to you on time.  I will send them in the next 24 hours.
Sorry again,
Bill
-------

∂03-Aug-85  1538	SCHERLIS@CMU-CS-C.ARPA 	First installment of COMMENTS
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 3 Aug 85  15:38:44 PDT
Received: ID <SCHERLIS@CMU-CS-C.ARPA>; Sat 3 Aug 85 18:40:46-EDT
Date: Sat 3 Aug 85 18:40:44-EDT
From: Bill.Scherlis@CMU-CS-C.ARPA
To: ftl@SU-AI.ARPA

Virginia --
Here is the first installment (of several, it seems) of comments
on the reference guide.  I'm making all comments that come to mind,
including some that won't deserve our attention for a while.  Let
me know if this is useful -- and how it can be made more useful.
Bill
===========================
Lucid Portable Common Lisp -- Suggestions and Comments (wls)

Overall, I am quite impressed with the Concise Reference Guide.  It
contains the information that users will most likely need to reference
regularly while programming.  It is organized well, and it enhances the
Steele book by providing some essential clarifying information.  The
quality of the writing is generally quite good.

I have a number of comments, however, concerning overall structure,
style, and the contents of the individual chapters.  I will try to
distinguish suggestions for long-term improvement from changes that are
more urgent.

I. Requirements.

The Reference Guide should contain at least the following:

-- An enumeration of all the Common Lisp entities (e.g., functions,
constants, macros) together with essential information (argument format and
types, result format and types).

-- Documentation for all Lucid additions to the Common Lisp language.

-- Clarifications of contradictory or confusing sections of the Steele
manual.

-- An indication of the extent to which optional language features (with
respect to the Steele manual) are implemented (for example, character set
and font information).

-- Language summary information (concerning format, readtable
initialization, types, and so on).

-- Documentation for the Lucid supporting environment common to all Lucid
development systems.

-- Documentation for system-specific features (for Sun, Apollo, etc).

The Guide should be organized in a way such that:

-- Readers are easily able to find the information they need.

-- Readers who are familiar with the language can use the Reference Guide
in their daily work and, generally, leave the Steele book on the shelf.

-- Lucid-specific features are always distinguished from features required
by the Steele manual.

-- New users who are familiar with Common Lisp but new to Lucid
implementations can acclimatize quickly.

-- Users who have used a different Lucid Common Lisp implementation can
move easily to the one described.

!
II. Comments on Structure and Style

(1) I like the idea of numbering chapters consistently with the Steele
book.  But the large number of appendices forced by that structure is
ackward.  Also, the material in Chapter 1 applied to the entire manual --
not just to the ensuing chapters.  We discussed this and considered a
hierarchical numbering scheme.  I'm still in favor of such a scheme.
Perhaps we should have:
Book A: Introduction:
The present Preface, Chapter 1.  The new Scenario.
Book B: The Lucid Language Environment:
The present Appendices C -- H.
Book B: Common Lisp Language Guide:
The present Chapters 2 -- 25.
Book C: The exhaustive lists of notions.
Appendices A, B.  A new full index.
But I'm not very strongly committed to this order.

(2) All Lucid functions (and other notions) should be flagged as such, at
EVERY instance of mention.  This will help readers (and glancers-through)
from thinking that we are somehow twisting the language (and the appelation
"Common Lisp") in the same way some other groups have.  I suggest a special
mark (the spade is fine) that appears each time the name is mentioned, but
in a nonobtrusive way.  Use of a special mark (as a superscript, say) will
prevent readers from thinking the mark is part of the function name.

(3) Lucid notion names, when they appear, should be cross-referenced to the
point of their definition (unless it is in the same chapter).  Otherwise,
readers cannot find all relevent descriptive prose.  An entry in the
listing presently in Appendix B should contain pointers to all chapters
where the notion is discussed or elaborated.

(4) The prosy structure of the individual chapters is fine if they are
short (as are most of them), but for the longer chapters (e.g.,
references: just a list of topics) at the start of the chapter would be a
help.   Also, placing topic phrases at the start of certain paragraphs
(in italics, say) would be a great help for readers who are scanning
through trying to find some bit of information.

(5) There is some question about how to make an index for the book.
Appendix A in its present form would overlap considerably with an index.
Although it is a difficult task, I would suggest that we ultimately make a
single overall index that included all CommonLisp notions, all Lucid
extensions, all keywords in use, and all lambda-list items (i.e.,
&optional, etc).  The information presently included in Appendix A would be
included, along with references to the chapters in which notions are
defined.  Including the parameter lists is essential!  (Presently, a reader
interested in, say, ECASE would, after looking in Appendix A, need to
look in the index of the Steele book in order to determine which chapter of
OUR manual contains our prose, if any, discussing Evalhook and related
Lucid extensions.)

(6) There is also some question about where to document the Lucid
extensions.  Either we can keep all the documentation in one place (the
present Appendix B) or we can distribute the definitions into the chapters.
My feeling at the moment is to keep the present structure, but to add some
detail to the discussions in the chapters.  (This is generally the case;
the point here is to recognize the issue.)

(7) Style.  I like the style. My only comment is to avoid starting
sentences with symbols (e.g., para 4, p.8).

!
III. A Scenario.

The present Preface contains a very brief example of interaction with the
system.  For users new to our system (but generally familiar with Lisp), it
would be useful to have an example protocol of interaction with the system.
This provides a single place where users and, more importantly, potential
users, can look to get an idea of how errors are handled and how the
debugging features can be used.

I suggest here the ingredients of a sample protocol.  Someone with access
to a Lucid system should sit with DRIBBLE and make one up.

-- Start the Lisp.
-- Show the Lisp banner.
-- Evaluate a simple form.
-- Produce an error from a top-level evaluation and type :A to abort.
-- Enter a  recursive function definition containing an error.
-- Evaluate a call, causing an error, and type :C to continue.
-- Use TRACE.
-- Use DRIBBLE.

!

Detailed comments are given below.  I have marked the comments that (I
believe) require immediate attention with "**".

Chapter 1.
-- "Lisp, Second Edition" by W and H  -->  "Lisp" by W and H (second edition)
-- In the syntactic descriptions for functions, put more space between the
function name and the argument list.
** p.1, Para 1: mention Lucid functions and the spade notation.
-- p.1, Para 3, last line: or  ->  and.
-- p.1, Para 6: say that programs can be in mixed case as well.
-- example 4: explain the arg syntax for SAMPLE-SPECIAL-FORM in words or by
example (after the description of the meta-syntax).  E.g.,
(SAMPLE-SPECIAL-FORM foo (x y z) bar (baz))
Actually, it is not clear how
(SAMPLE-SPECIAL-FORM nil nil)
will be parsed!
** Brackets appear in both italics and in typewriter font.  (See, for
example, the lambda-list syntax in Ch.5.)
** The italic words in the syntactic descriptions cannot always be
construed as parameter NAMES (e.g., in the case of {var}*).

Chapter 2.
** Several important types are missing: SEQUENCE, COMMON, BIT, FUNCTION,
and possibly others.   But I really like the idea of a type diagram.
-- Include pointers to Chapters 4 and 9.

Chapter 3.
-- In the "indefinite scope" paragraph: What is meant by "in any program"?
** In the "dynamic extent: paragraphs, add "in time" at the ed of the first
sentence.
-- Here are examples of the four binding phenomena mentioned:
- Lexical scope: (non-special) parameters, labels, block names.
- Indefinite scope: top level names, such as function and macro names.
- Dynamic extent: objects referenced by identifiers declared special.
- Indefinite extent: cons cells, closures, and other heap objects.
** It might be a good idea to include the list at the bottom of p.39 of the
Steele book.

Chapter 4.
** In sentence 3, "other types of objects" is a bit confusing.
-- In the TYPESPEC syntax: Explain the parameterization in NUMBER-limit.
Perhaps use some other font for the type parameters in the TYPESPEC
production.  Also, say somewhere that the first limit is a low limit and the
second is a high limit.  Are the limits optional (and, in particular, is
the second limit really optional)?
** After &optional in ARG-TYPESPEC-LIST should be one or more TYPESPECs.
-- (The brackets are in different fonts.)

Chapter 5.
** In sentence 2, results are ZERO or more values.
-- In para 2, change "functional computation" to "evaluation of a function".

Chapter 6.
-- Add a paragraph summarizing the differences between EQ, EQL, EQUAL, and
EQUALP.

Chapter 7.
** Define "generalized variable."  (This concept is unfamiliar to old-world
Lispers, and a quick definition or example would help here.)
-- Would it be better to move the discussion of PLACEs before the full
enumeration of notions?

Chapter 8.
-- Is this the place (if any) to mention caching (if any) of macro
expansions?  Should DECACHE-EVAL be mentioned here?  (I don't know.)

-------

∂07-Aug-85  0848	F.DUFFIE@SU-GSB-WHY.ARPA 	Fonts to Virginia Kean
Received: from SU-GSB-WHY.ARPA by SU-AI.ARPA with TCP; 7 Aug 85  08:47:56 PDT
Date: Wed 7 Aug 85 08:43:18-PDT
From: James Duffie <F.DUFFIE@SU-GSB-WHY.ARPA>
Subject: Fonts to Virginia Kean
To: FTL@SU-AI.ARPA

Virginia,
Attached to this memo is a file that sets up a ninepoint font suitable for
an index. You automatically get roman, slant, italics, boldface, and mathmode
with appropriately sized super and super-super scripting automatically
after the line
\ninepoint

Of course, you must have the line

\input fonts

at the front of your file. If you don't want ninpoint forever, you can
group:

{\ninepoint Now I'm in ninepoint.} Now I'm not.

Or you can switch back and forth as indicated by the more general
package of fonts in the TeXBOOK, page 414.

Remember that some of the fonts called for may not be preloaded on your
system. They aren't at GSB. They are at SCORE. See the TeXBOOK for
example, to preload cmr9 (ninepoint computer modern roman) simply
write

Note that some fonts I've called for may not even be available on your
system. In that case there ought to be a close substitute.

OK Here comes my little fonts.tex .  Let me know if you need more help.
Regards, Darrell

%This package of fonts set up by Darrell Duffie
%No liability for errors. It works for me, except for the
%comma and colon in ninepoint math mode, which I hope to fix later.
%
%Depending on your system, some of the fonts below have to be preloaded.
%See the TeXBook for details.
%The above is my excuse for documentation'.
%
\font\ninerm=cmr9 \font\eightrm=cmr8 \font\sixrm=cmr6
\font\ninei=cmi9  \font\sixi=cmi6
\font\ninesy=cmsy9 \font\sixsy=cmsy6
\font\ninebf=cmb9
\font\nineit=cmi9
\font\ninesl=cms9
\font\fiverm=cmr5
\font\fivei=cmi5
\font\fivesy=cmsy5
\def\ninepoint{\def\rm{\fam0\ninerm}%switch to ninepoint (TeXBOOK,
% p.414) missing some features
\textfont0=\ninerm \scriptfont0=\sixrm \scriptscriptfont0=\fiverm
\textfont1=\ninei  \scriptfont1=\sixi  \scriptscriptfont1=\fivei
\textfont2=\ninesy \scriptfont2=\sixsy \scriptscriptfont2=\fivesy
\textfont\itfam=\nineit \def\it{\fam\itfam\nineit}
\textfont\slfam\ninesl  \def\sl{\fam\slfam\ninesl}
\textfont\bffam\ninebf  \def\bf{\fam\bffam\ninebf}
\normalbaselineskip=11pt
\setbox\strutbox=\hbox{\vrule height8pt depth3pt width0pt}
\normalbaselines\rm}
-------

∂24-Oct-86  1619	edsel!bhopal!lgd@navajo.stanford.edu 	concepts.tex
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 24 Oct 86  16:19:05 PDT
Received: by navajo.stanford.edu; Fri, 24 Oct 86 16:17:19 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
id AA01958; Wed, 22 Oct 86 18:35:13 pdt
id AA11641; Wed, 22 Oct 86 18:34:24 PDT
Date: Wed, 22 Oct 86 18:34:24 PDT
From: edsel!bhopal!lgd@navajo.stanford.edu (Linda G. DeMichiel)
Message-Id: <8610230134.AA11641@bhopal.edsel.uucp>
To: navajo!ftl%sail.stanford.edu@navajo.stanford.edu
Subject: concepts.tex

\input macros
\def\bookline{\CLOS\  Specification}
\def\chapline{Basic User Interface Concepts}

\beginChapter 1.{Common Lisp Object System Specification}%
{Basic User Interface Concepts}{Basic User Interface Concepts}

Contributors to this document include Daniel G. Bobrow, Linda G.
DeMichiel,\break Richard P. Gabriel, Kenneth Kahn, Sonya E. Keene,
Gregor Kiczales, Larry\break Masinter, David A. Moon, Mark Stefik, and
Daniel L. Weinreb.

Comments and suggestions on this document are encouraged.
Changes will be incorporated over the next several months.
This text will be made available to the X3J13 Committee for the
Common Lisp Standards effort.

\endTitlePage

\beginSection{Introduction}

This proposal presents a description of the standard user
interface for object-oriented programming in the \CLOS.  A second
document, The \CLOS\ Meta-Object Protocol'' describes how the
\CLOS\ can be customized to accommodate existing object-oriented
paradigms and to define new ones.

Under this proposal, the primitive entities of Common Lisp are called
{\bit objects}.  The fundamental objects of the \CLOS\ are
classes, generic function objects, and method objects.  [What is
the ontological status of method combination?]  [Meta-objects?]

A {\bit class\/} object determines the structure and behavior of a set
of other objects, called its {\bit instances}.  The class of an object
indirectly determines the set of operations into which the object can
enter.  It is an important feature of the \OS\ that every Common Lisp
data structure is an object that is an {\bit instance\/} of a unique
class.

{\bit Generic functions} are objects that may be specialized to
provide class-specific operations.  A generic function is a function
that is able to designate one of a set of possible operations based on
the classes of its arguments.  A generic function can be used as an
argument to {\bf funcall} and {\bf apply} and stored in the
symbol-function cell of a symbol.

The class-specific operations provided by generic functions are
themselves defined and implemented by {\bit methods}.  A method is
also a function object.  The method object contains a method function
and a set of {\bit argument specializers\/} that specify when the
given method is applicable.

%  A method can be used as an argument to
%  {\bf funcall} and {\bf apply} and stored in the symbol-function cell
%  of a symbol.  [This needs to be decided.]

When a generic function is invoked, the selection and sequencing of
the individual methods that are applicable may be further controlled by the
{\bit method combination\/} facility.   Method combination qualifiers,
types, and rules [or what do we call these?] can be used to precisely
define which methods are invoked when a given generic function is called
with specific classes of arguments.

\vfill
\endSection%{Introduction}

\beginSection{Classes}

A {\bit class\/} is an object that determines the structure and behavior
of a set of other objects, called its {\bit instances}.

Like other objects, all classes are themselves instances of other classes.
The class of the class of an object is termed the {\bit metaclass\/} of that
object.  Less formally, we will also use the term {\bit metaclass\/} to
refer to a class that has instances that are themselves classes.
The metaclass determines the form of inheritance used by its classes and
the representation of the instances of those classes.

A class can inherit properties directly or indirectly from one or more
other classes.  A class that is defined so as to inherit from another
class is said to {\bit include\/} that class.  A class that inherits
from a class is said to be a {\bit subclass\/} of that inherited
class.  A class from which another class inherits properties is called
a {\bit superclass\/} of the inheriting class.  The inheritance
relationship is transitive.

Classes are organized into a {\bit lattice}.  There is a mapping from
the Common Lisp type lattice into the Common Lisp Object System class
lattice.  All of the standard Common Lisp types specified in
{\it Common Lisp: The Language\/} by Guy L. Steele Jr. except {\bf atom}
and {\bf common} have a corresponding class.

The \OS\ includes a set of standard objects.  We use the term
{\bit standard object\/} to refer to any object whose metaclass is
{\bf class}.  The class {\bf object} specifies the default behavior of the
set of all objects whose metaclass is {\bf class}.  In other words,
all standard objects inherit (directly or indirectly) from the class
{\bf object}.

The \OS\ also defines a set of standard classes.  A {\bit standard
class\/} is any class that is an instance of the class {\bf class}.
The class {\bf class} is itself of class {\bf class}.  It is therefore
both a standard class and a standard object.  The class {\bf object}
is also a standard class since it is also an instance of the class
{\bf class}.  As a standard object, the class {\bf class} is a
subclass of the class {\bf object}.

\vfill\eject
\Vskip 1pc!
\boxfig
{\bf\tabskip 0pt plus 1fil
\halign to \hsize{&#\hfil\cr
array&hashtable&sequence\cr
atom*&integer&short-float\cr
bignum&keyword&simple-array\cr
bit&list&simple-bit-vector\cr
bit-vector&long-float&simple-string\cr
character&nil&simple-vector\cr
common*&null&single-float\cr
compiled-function&number&standard-char\cr
complex&package&stream\cr
cons&pathname&string\cr
double-float&random-state&string-char\cr
fixnum&ratio&symbol\cr
float&rational&t\cr
}}
\caption{Standard Common Lisp types.  All these types except atom and common have\break
a corresponding class.}
\endfig

\beginsubSection{Defining Classes}

Classes with metaclass {\bf class} (standard classes)
are defined with the macro {\bf defclass}.
The use and definition of classes with other metaclasses %are
will be
discussed in the chapter Meta-Object Protocol.''

The syntax for {\bf defclass} is given in Figure~1-3.

The new class created by {\bf defclass} is a subclass of all the
classes specified in the {\it includes\/} list of the {\bf defclass}
form.  A class that is defined in this way is the most specific
element of a sublattice from which descriptions are inherited.  The
order of the classes in the {\it includes\/} list determines a local
precedence for classes and for the selection of methods.  The
transitive closure of all the {\it includes\/} specifies all the
classes that this class inherits from.  An ordering of this list for
purposes of precedence is called the {\bit class precedence list}.

The class precedence list for a standard class is computed as follows:

[To be spec'd.]
%1. A list is created, starting with the given class, of all the classes
%encountered in a depth-first traversal of
%the classes in the {\it includes\/} list of that class.  The classes in
%the {\it includes\/} list are processed in left-to-right order (the order
%of local precedence).
%
%2. If more than one occurrence of a class appears in the list that
%results from step 1, only the last occurrence of that class is kept.
%
%3. It is verified that the list that results from step 2 preserves the
%local precedence indicated in the {\it includes\/} list of each class
%encountered.  If any such local precedence is violated, an error is
%signalled.
\endsubSection

\beginsubSection{The Structure of Class Objects}

\endsubSection%{The Structure of Class Objects}

\beginsubSection{Creating Instances of Classes}

\endsubSection%{Creating Instances of Classes}

\beginsubSection{Superclasses}

\endsubSection%{Superclasses}

\beginsubSection{Inheritance}

\endsubSection%{Inheritance}

\beginsubSection{Class Precedence}

%brief introduction to notion of class precedence
\endsubSection%{Class Precedence}

\beginsubSection{Accessing Slots}

Slots can be accessed in two ways: by use of the accessors defined in
the {\bf defclass} form and by use of the primitive function
{\bf slot-value}.

The function {\bf slot-value} can be used with any of the slot names
specified in the {\bf defclass} form to access a specific slot in an object
of the given class.  If the object has no such slot, an error is
signalled.

The automatically-generated accessors specified in the {\bf defclass} form
are implemented in terms of {\bf slot-value}.

\endsubSection

\beginsubSection{Types and Classes}

The \OS\  maps the Common Lisp type space into the space
of classes.
Figure~1-2 displays part of the lattice of classes that are instances of
a subclass of {\bf standard-type-class}.

Creating a type by means of {\bf defstruct} also creates a class in
this lattice.  Such a class is an instance of {\bf structure-class}
and an immediate subclass of the class that
corresponds to the type given as its
{\bf :includes} argument.  If no such type was specified, it
is an immediate subclass of the class {\bf t}.

The following precedence relations hold among classes:
{\bf list} has precedence over {\bf symbol} (for {\bf nil});
{\bf array} has precedence over {\bf sequence} (for vectors);
{\bf vector} has precedence over {\bf simple-array} (for simple-vectors);
{\bf bit-vector} has precedence over {\bf simple-array} (for simple-bit-vectors);
and {\bf string} has precedence over {\bf simple-array} (for simple-strings).

The classes {\bf number}, {\bf integer}, {\bf rational}, {\bf float},
{\bf list}, and {\bf sequence} are {\bit abstract classes}, that is,
they can never be directly instantiated.  The function {\bf class-of}
will never return one of these classes.

\endsubSection%{Integrating Types and Classes}

\eject
\beginsubSection{Lattice of classes that are instances of standard-type-class}
\fig{
\def\IgnoreLineBreaks{\catcode'15=9     \catcode'12=9}
\def\IgnoreWhiteSpace{\catcode'11=9 \catcode'40=9 \IgnoreLineBreaks}
\def\DontIgnoreWhiteSpace{\catcode'12=\active\catcode'15=5\catcode'11=10\catcode'40=10}

\font \pipefont= circlew10
\font \foofont = amr10 at 1sp

\IgnoreWhiteSpace

\def\he{height}
\def\wi{width}
\def\de{depth}

\newdimen \stroke
\stroke= \fontdimen8\pipefont   % thickness of line in circles

\newbox\BStrutbox

\setbox\BStrutbox\hbox{\vrule\wi0pt\he8.5pt\de8.5pt}
\def\BoxStrut{\unhcopy\BStrutbox}

!% Arrows

\newdimen\ArrowShift
\ArrowShift=\fontdimen22\tensy

\def\StrikeOut #1
{       \setbox0\hbox{#1}
\hbox to 1\wd0
{       \vrule \he\stroke\de0pt\wi\wd0
\hskip-\wd0
\unhbox0
}
}

\def\LeftArrow
{       \hskip 0.5\stroke
\StrikeOut{\lower\ArrowShift\hbox to 10pt{\tensy\char'40\hss}}
}

\def\RightArrow
{       \StrikeOut{\lower\ArrowShift\hbox to 10pt{\hss\tensy\char'41}}
\hskip 0.5\stroke
}

\def\ArrowLine
{       \StrikeOut{\hskip 10pt\hskip 0.5\stroke}
}

\def\LeftToRight
{       \let\RightSideArrow=\ArrowLine
\let\LeftSideArrow=\RightArrow
}

\def\RightToLeft
{       \let\LeftSideArrow=\ArrowLine
\let\RightSideArrow=\LeftArrow
}

\def\NoArrows
{       \let\LeftSideArrow=\ArrowLine
\let\RightSideArrow=\ArrowLine
}
!% boxes around tokens

\let\NonterminalFont=\tenrm

\newbox\TStrutbox
\setbox0\hbox{\NonterminalFont{Bg}}
\setbox\TStrutbox\hbox{\vrule\wi0pt\he\ht0\de\dp0}
\def\TextStrut{\unhcopy\TStrutbox}

\def\HorzLine{\hrule \he \stroke \de 0pt}

\def\Nonterminal#1
{\setbox1\vbox to 0pt{
\vss
\hbox{\TextStrut\NonterminalFont\space#1\space\hskip-\stroke}
\vss}
\hbox{
\BoxStrut
\LeftSideArrow
\TopSquare
\copy1
\BotSquare}
\RightSideArrow}
}

\def\TopSquare
{       \hbox{
\vrule\he\stroke\de0pt\wi\wd1
}

\def\BotSquare
{       \hbox{
\vrule\he\stroke\de0pt\wi\wd1
}

\def\\#1{\Nonterminal{#1}\HFil}
\def\last#1{{\def\RightSideArrow{}\Nonterminal{#1}}}

!% piping

\def\foo{\rlap{\foofont\char'40}}
\def\foo{}

\def\FulVert{\vrule             \wi\stroke\foo\hskip-\stroke}

\def\Center#1,#2.

\def\Center#1,#2.

\def\LT{\Center\BotVert,\lu.}
\def\LU{\Center\FulVert,\lu.}
\def\LL{\Center\FulVert,\ld.}
\def\LB{\Center\TopVert,\ld.}
\def\LMid{\Center\TopVert\BotVert,\rd\ru\thru.}
\def\LMU{\Center\TopVert,\rd\thru.}
\def\LML{\Center\BotVert,\ru\thru.}
\def\LFD{\Center\FulVert,\ru\thru.}
\def\LS{\Center\TopVert\BotVert,\rd\ru.}

\def\RT{\Center\BotVert,\ru.}
\def\RU{\Center\FulVert,\ru.}
\def\RL{\Center\FulVert,\rd.}
\def\RB{\Center\TopVert,\rd.}
\def\RMid{\Center\TopVert\BotVert,\ld\lu\thru.}
\def\RMU{\Center\TopVert,\ld\thru.}
\def\RML{\Center\BotVert,\lu\thru.}

\def\Cross{\Center\FulVert,\thru.}
\def\LR{\Center,\thru.}
\def\TB{\Center\FulVert,.}
!%  ShiftBox

\newbox\x
\newbox\y
\newbox\tempy
\newbox\z
\newbox\tempz

\def\ShiftBox#1{
\savemod
\saverulebox
\setbox\x
\vbox{  \everycr{\noalign{{\modifyrulebox\global\setbox\z\hbox{}}}}
\halign{&\setbox\x\hbox{##}
\global \setbox\z\hbox{\unhbox\z\vrule\he\ht\x\de\dp\x\wi0pt}
\unhbox\x
\cr
#1}}%
\lower\ht\y\box\x\HFil
\restoremod
\restorerulebox
}

\def\saverulebox{
\setbox\tempy\box\y
\global \setbox\y\vbox{}
\setbox\tempz\box\z
\global \setbox\z\hbox{}
}

\def\restorerulebox{
\global \setbox\y\box\tempy
\global \setbox\z\box\tempz
}

\def\topmod{}

\def\thisrow{\global\let\modifyrulebox\firstmod}

\def\firstmod{
\global\setbox\y\vbox{\hrule\he0pt\wi0pt\de\dp\z}
\global\let\modifyrulebox\latermod
}
\def\latermod{
\global\setbox\y\vbox{\unvbox\y\hrule\he\ht\z\de\dp\z\wi0pt}
}
\def\savemod{
\let\tempmod\modifyrulebox
\global \let\modifyrulebox\topmod
}
\def\restoremod{
\global\let\modifyrulebox\tempmod
}

\DontIgnoreWhiteSpace
!{\baselineskip0pt
\lineskip0pt
\LeftToRight
\IgnoreWhiteSpace

\def\ms{\os\os\os\os}
\def\os{\omit\span}
\hbox{
\\{NIL}
\ShiftBox{
\ms\LT\\{bit}&\RT\cr
\ms\ShiftBox{
\ShiftBox{
\ShiftBox{
\LU\\{fixnum}&\RT\cr
\LU\\{bignum}&\RMU\thisrow\cr
}\\{integer}&\RML\thisrow\cr
\LU\\{ratio}&\RB\cr
}\\{rational}&\RT\cr
\ShiftBox{
\LU\\{short-float}&\RT\cr
\LU\\{single-float}&\RMid\thisrow\cr
\LU\\{double-float}&\RL\cr
\LU\\{long-float}&\RB\cr
}\\{float}&\RMid\thisrow\cr
\LU\\{complex}&\RB\cr
}\\{number}&\RU\cr
\ms\LU\\{standard-char}\\{string-char}\\{character}&\RU\cr
\LU\\{keyword}&\os\os\os\RML\\{symbol}&\RU\cr
\LU\\{null}&\os\os\os\LS&\TB\cr
\LMid\\{cons}&\os\os\RMU\\{list}&\RML\\{sequence}&\RMid\thisrow\cr
\os\LL\\{simple-vector}&\LML\HFil&\RML\\{vector}&\LS&\TB\cr
\os\LL\\{simple-bit-vector}&\LFD\\{bit-vector}&\RL&\TB&\TB\cr
\os\LL\\{simple-string}&\LFD\\{string}&\RB&\TB&\TB\cr
\os\TB&\os\LB\HFil\\{simple-array}&\RMU\\{array}&\RL\cr
\ms\LL\\{stream}&\RL\cr
\ms\LL\\{hash-table}&\RL\cr
\ms\LL\\{package}&\RL\cr
\ms\LL\\{pathname}&\RL\cr
\ms\LL\\{function}&\RL\cr
\ms\LL\\{compiled-function}&\RL\cr
\ms\LB\\{random-state}&\RB\cr
}
\last{T}}}
\hbox{}
}\caption{This figure shows all required subclass relationships among the classes that\break
are instances of
standard-type-class, with the exception of classes defined by means of\break
defstruct.  Implementations may choose to impose additional ones.}
\endfig

\endsubSection%{Types and Classes}

\endSection%{Classes}

\beginSection{Generic Functions and Methods}

A {\bit generic function\/} is a function object, which, when it is invoked,
is able to designate one out of a set of operations, depending on the
classes of its arguments.  The generic function is said to
{\bit discriminate\/} on the classes of its arguments.

[The following is under discussion:
A generic function is a first-class object in the \CLOS.
It can be used as an argument to {\bf funcall} or {\bf apply} and
stored in the symbol-function cell of a symbol.]

[The following is under discussion:  A generic function is created
using the function {\bf make-generic} or the
macro {\bf defgeneric}. The macro {\bf defgeneric} stores the generic function
in a specified symbol-function cell.]

The operations that are provided by a generic function are defined by
the methods associated with it.

A {\bit method\/} is a function object.  It consists of two
parts: a set of argument
{\bit specializers\/} that is used to determine when it is applicable and a method
function.
%Methods are first-class objects in the \CLOS.
A method can be used as an argument to {\bf funcall} or {\bf apply} and
stored in the symbol-function cell of a symbol.

A method can be defined and associated
with a generic function by using {\bf defmethod} or {\bf add-method}.
[An issue under discussion is whether a generic function must be defined
before any methods can be added to it.]

When a generic function is invoked, the arguments specializers of its
associated methods are used to determine which method function is
invoked.
An {\bit argument specializer\/} is the name of a class or an
individual.
The class of each of the arguments passed to the generic function
is determined and the classes of the arguments are then
compared with the
argument specializers of each of the methods associated with the generic
function.  The method function of the method with the most specific
set of argument specializers that are identical to or more general than
the classes of the arguments is invoked.  The order in which differences
between the classes of the arguments and the arguments specializers are
considered is defined by the
{\bit argument precedence order\/} for the generic function. The relative
specificity of argument specializers is determined by the class lattice.
%The {\bf class precedence list} is used to determine
%which specializer is more specific.
Any individual is always more specific than any class.  There
is a class named {\bf t} that is more general than any other class.  When every
argument specializer in the set of argument specializers for a method is either
unspecified or {\bf t}, the method function for that method is called the
{\bit default method function\/} of the generic function.
%The precise definition for determining which method of a generic
%function to invoke will be given in section XXX.

\endSection%{Generic Functions and Methods}

\beginSection{Method Selection}
\endSection%{Method Selection}

\beginSection{Method Combination}

[To be written.]

We are currently working to integrate the programmatic ({\bf
run-super}) and declarative ({\bf define-method-combination}) method
combination techniques.  The references to method combination throughout
this document will be further specified in a future draft.

%Methods can be combined by means of the {\bf run-super} construct.
%The {\bf run-super} construct allows a method to specialize a super''
%method.

\endSection%{Method Combination}

\beginSection{Meta Objects}

\beginsubSection{Metaclasses}

The {\bit metaclass\/} of an object is the class of its class.  The metaclass
determines the form of inheritance used by its classes and
the representation of the instances of its classes.  The metaclass mechanism
can be used to provide particular forms of optimization or to tailor
the \OS\  for particular uses (such as the implementation of other
object languages---like Flavors, Smalltalk-80, and Loops).

Any new metaclass must define the structure of its instances, how their storage
is allocated, how their slots are accessed, and how slots and methods are
inherited.  The protocol for defining
metaclasses will be discussed in the chapter Meta-Object Protocol.''
\endsubSection

\beginsubSection{Standard Metaclasses}

The \OS\  defines a number of {\bit standard metaclasses}.  These include
the following:
{\bf standard-type-class}, {\bf structure-class}, and {\bf class}.

The class {\bf standard-type-class} is a superclass of all the classes
that correspond to the standard Common Lisp types specified in
{\it Common Lisp: The Language\/} by Guy L. Steele Jr. except {\bf atom} and
{\bf common}.  These types are listed in Figure~1-1.
This metaclass allows the special kind of class
inheritance rules that are needed to handle the classes that
correspond to the standard Common Lisp types.
It is not possible to make an instance
of a class whose class is {\bf standard-type-class} using the function
{\bf make-instance}.
%It is possible to define methods for built-in classes.

The class {\bf structure-class} is a subclass of {\bf standard-type-class}.
All classes defined by means of {\bf defstruct} are instances or
{\bf structure-class} or a subclass of {\bf structure-class}.
%The use of {\bf defstruct} implicitly defines a new class which is an
%instance of {\bf structure-class}.

%Instances of {\bf primitive-lisp-type-class} are classes that correspond
%to the basic Common Lisp types.
%While all classes that correspond to the types
%listed in Figure~1-1 must be instances of either {\bf structure-class}
%or {\bf primitive-lisp-type-class}, no implementation is {\it required\/} to
%have any class that is an instance of {\bf primitive-lisp-type-class}.
\endsubSection

\endSection

%\beginSection{Meta-Objects}

%Includes objects for classes, objects for methods, objects for generic functions.

%Use: efficiency in implementation; experimentation.

%Allows for variations in the representation of objects, the syntax of
%methods, the combination of methods.

%Can be used to provide tuning and optimization for a particular application.

%\endSection

\endChapter
\bye

`