23-OCT-74 01:02:59-PDT,835;000000000001
Date: 23 OCT 1974 0102-PDT
From: TEITELMAN
Subject: LAPRD, LCSKIP


When LAPRD or LCSKIP read an atom followed by a space,
and the next atm on the line is BINARY, reading is performed
by BINRD/BINSKIP. This is the normal case. If the atom is
anything else, a checkis made on the ropety list of
the atom for the property CODEREADER. If one is there,
its value is treated as a dotted pair of two functions,
the first for reading, the second for skipping, e.g.
(BINRD . BINSKIP).

CAR is called fro LAPRD (via apply*) giving it
the name of the copiled function being read as its first argument

(the first atom on the line). CDR is called from LCSKIP
giving it the name of the compiled function being read as its first argument
and the skip/copy flg (NIL means skip, T means copy) as its second argument.


-------
23-OCT-74 01:10:26-PDT,897;000000000001
Date: 23 OCT 1974 0110-PDT
From: TEITELMAN
Subject: FNOPENR et al


The following functions are to be used to eschew vag's and loc's
when rferencing compiled code. they will wokr
on either resident or swapped code, and take care
of making sure thatthe function is in the buffer.

fnopenr[def;adr]     def is a GETD - either ccodep or handlep
    and adr is a relative address. value is contents of
     corresponing cell. takes care of fact that
   getd for compiled def corresponds to the entry point
   and for handlep  to entry point -2 in that adr is always
  computed relative to  entry  point

fnopenra[def;adr]     like fnopenr but returns car of corresonding
   cell  i.e. right half (as unboxed quantity)

fnopenrd  --

fncloser[def;adr;x]   
similar  fnclosera,  fncloserd,  /fnclosera, /fncloserd, /fncloser

all but the / function  compile open.


-------
 3-NOV-74 01:10:46-PST,1879;000000000001
Date:  3 NOV 1974 0110-PST
From: MASINTER
Subject: HPRINT

There is a flag HPRINTALLFLG: if on, HPRINT checks for EQ strings
and large numbers (as well as lists, arrays, etc). 

initial value NIL (i.e. don't put strings in hash table).

----

initialization function HPINITRDTBL[chars] init's the read table.
chars is the list
(forwardchar forwardcdrchar bakchar fillchar finalchar).
  ^ used before an item which will have a back reference
	     ^ used before an item, the tail of the list starting
bakchar is used to denote both a back reference, and a hash array,
(when followed by H), a regular array (when followed by A[), a
datatype (when followed by [).

fillchar is used to pad around back reference numbers (since
it just leaves spaces a priori and goes back at the end to
remark the places).

finalchar is used to terminate the backref numbers (as well as
after arrays, datatypes, etc).

initially, these are set up:
forwardchar = ^ (up arrow)
forwrdcdrchar = ` (accent grave)
bakchar = { (left brace)
fillchar = (ASCII 0)  {usually non-printing)
finalchar = } (right brace)

This means that circular lists print in a similar format
to CIRCLPRINT's output.
Arrays print as {A[n1 n2 e1 e2 e3 ...]}    (the ei's are the elements)
Hash arrays print {H[n1 e1 e2 e3 ...]}
User datatypes as {[name e1 e2 e3 ...]}  except that the first
time a datatype is printed, the name is followed by NWORDS and 
NPOINTERS.

forwardchar, forwrdcdrchar, and bakchar are macros; 
fillchar and finalchar are just seprs (but there are redundancy
checks that (EQ (READC ..) finalchar) in various places).

----
READVARS, if the last arg is a list, will initialize the readtable
to those codes. HORRIBLEVARS prettydefmacro will put out the
codes in the READVARS expression if they are different from
those in HPDEFAULTCHARS.

Larry
-------
 5-NOV-74 23:39:42-PST,780;000000000000
Date:  5 NOV 1974 2339-PST
From: MASINTER
Subject: RECORD USE
To:   KAPLAN

If RECORDUSE is both set and defined, then whenever the
record package makes a translation, it will call
(RECORDUSE functionname recordname fieldnames). Functionname
is the name of the function containing the reference;
either recordname or fieldnames are non-nil. On CREATE's and
TYPE?'s, its recordname; on FETCH's and REPLACE's it's fieldnames
(which is a list of field names).

In addition, whenever a record is redeclared,
the record package function RECREDECLARE[redeclarelst,recname]
is called {redeclarelst is the list of field names}. You
can advise this function to, say, unsavedef all the functions
which use either that record name or any of those fields.

Larry
-------
18-APR-75 22:56:35-PDT,419;000000000001
Date: 18 APR 1975 2256-PDT
From: MASINTER
Subject: HELPSYSINTERRUPTS

The var HELPSYSINTERRUPTS contains the list given to
INTERRUPTCHAR to set the helpsys interrupts. It is currently
(5 (HELPCTRLE T) T 28 (HELPCTRLE) T).. If you want to
change the interrupts around, you can change this list,
set it to NIL (in which case HELPSYS won't enable ANY intterupts)
or, say, change the 28 to 15 to make oc
-------
18-APR-75 22:57:20-PDT,152;000000000001
Date: 18 APR 1975 2257-PDT
From: MASINTER
Subject: more

... or, say, change the 28 to 15 to make control-O the helpsys
shutup.

Larry
-------
21-APR-75 13:38:14-PDT,506;000000000001
Date: 21 APR 1975 1338-PDT
From: MASINTER
Subject: RECORD
To:   TEITELMAN

New RECORD and RECORD.COM on <NEWLISP>. Fixed GETLOCALDEC, (took
it out) prog/return in datatype code, and added new feature:
(copy of this msg to <LISP>UNDOC.TXT). New record type
BLOCKRECORD which works like DATATYPE, except that NO type checking
is done, create's not allowed, and no pointer fields allowed
(i.e. fields are either BIT, HALF, FIXED, FLOATING, etc).

For munging around in GETBLKs.

Larry
-------
29-APR-75 11:15:41-PDT,1487;000000000000
Date: 29 APR 1975 1115-PDT
From: DEUTSCH
Subject: GC
To:   hartley at BBNB
cc:   teitelman, bobrow

I have (apparently ) finally encountered a situation where I really
need to know under precisely what circumstances the G.C. will delete
an entry from a hash array.  I have a (unfortunately large) program
which works properly if I do MINFS(25000) and RECLAIM) before I
start running it, but if I don't, it blows up with a NON-NUMERIC ARG
NIL which results from something which it "knows" is in a hash array
not being there.  In the latter case, a GC: 8 occurs during a phase
of the computation when there are many hash arrays being
filled which will be examined later.

Just to explain my current understanding: it is my impression that
the G.C. will delete an entry from a hash array if the key
(the thing you give to GETHASH) is otherwise reclaimable, i.e. if
there are no references to the key other than from entry keys in
hash arrays, and the key is not a small number or litatom.
If this is true, I think it may be what is screwing me, since
I think I may have hash arrays which at some point in their lives
only exist to be scanned with MAPHASH and whose keys no longer have
references to them in some cases.  (This is not a contrived situation:
imagine a system for manipulating sets which represents sets as
hash arrays.  Then the keys almost certainly have no other references
to them, and the ONLY important use of the arrays is MAPHASH.)
-------
29-APR-75 13:21:41-PDT,1050;000000000000
Net mail from site BBN-TENEXB rcvd at 29-APR-75 13:21:33
Date: 29 APR 1975 1619-EDT
From: HARTLEY at BBN-TENEXB
Subject: HASH ARRAYS AND GC
To:   DEUTSCH at PARC
cc:   TEITELMAN at PARC, BOBROW at PARC, LEWIS

PETER,
YOUR SITUATION IS A MORE COMPLICATED VERSION OF A SITUATION
THAT AROSE HERE AWHILE AGO AND HAS BEEN BUGGING
ME EVER SINCE.
A USER SAVED A HASH ARRAY WITH DUMPHASH(SPELLING?) AND
FOUND THAT SHE COULDNT GET IT LOADED IN BECAUSE
A GC OCCURED WHILE IT WAS LOADING
AND ALL THE HASH ENTRIES WENT AWAY. HER INTENT WAS
TO LOAD THE HASH ARRAY AND THEN MAPHASH THRU IT
TO CONSTRUCT THE REST OF HER DATA STRUCTURE (HAD SHE
GOTTENT O THE STAGE OF CREATING THE REST OF THE
STRUCTURE BEFORE THE GC THEN THE HASH ARRAY WOULD NOT
HAVE DISAPPEARED (THE CONTENTS OF THE HASH ARRAY THET IS)
).

THE LESSON TO BE LEARNED IS THAT EITHER MAPHASH SHOULD NOT
EXIST, OR THAT THE GARBAGE COLLECTOR SHOULD NEVER
DELETE ENTRIES FROM A HASH ARRAY.
THIS PROBLEM IS RELATED TO MY OBJECTIONS TO THE
DESIRE FOR MAPATOMS.

ALICE
-------
29-APR-75 14:14:25-PDT,1517;000000000000
Date: 29 APR 1975 1414-PDT
From: DEUTSCH
Subject: hash arrays & gc
To:   hartley at BBNB
cc:   teitelman, bobrow, lewis at BBNB

Well, I'm glad to learn I'm not alone in being bitten by this bug.

The logical problem is fairly subtle.  I'm not willing to give up
MAPHASH (and I see it as being different than MAPATOMS in that it
requires an explicit act to create and delete hash associations whereas
atoms are created "at need" and therefore may more reasonable be
reclaimed "when no longer needed").  What is really going in is that
some hash arrays are sort of like property list associations,
which persist indefinitely even if the user has forgotten all about
the atom that possesses them, whereas others are more like associations
by direct pointers (like list-records), which disappear when the key
is no longer accessible.  Litatoms can possess both types of
associations: an example of the former is the EXPR property, whereas
a "memo function" like a numeric hash from the name might be an example
of the latter property.

I confess I don't see a good solution to this problem.  The one that
comes to mind is a bit in the hash array that tells the g.c. whether
it is allowed to delete entries, but somehow this is unsatisfying.
However, if (as it appears) the difference between the two situations
is really the user's "intent", then there is no way the system can
always do the right thing, and some kind of explicit user-settable bit
is really required.

Comments?
-------
15-DEC-75 23:42:12-PST,266;000000000001
Date: 15 DEC 1975 2342-PST
From: MASINTER
Subject: copy of msg to UNDOC.TXT
cc:   TEITELMAN, LEWIS at BBNA

There is a flag, NOPACKCALLSFLG, which, if T, causes CALLS not
to pack semicolons around functions called via linked function calls.

Larry
-------
30-JAN-76 10:20:18-PST,321;000000000001
Date: 30 JAN 1976 1020-PST
From: MASINTER
Subject: CIRCL
To:   Teitelman
cc:   HThompson, Sproull

New CIRCL and CIRCL.COM on <NEWLISP> with feature added to COPYALL:

The variable DONTCOPYDATATYPES (initially NIL) is used as a list
of data-type numbers which should NOT be copied by COPYALL.

Larry
-------
15-JUL-76 16:37:48-PDT,555;000000000001
Date: 15 JUL 1976 1637-PDT
From: MASINTER
Subject: CCREATE
To:   Kaplan

The way CCREATE works now is that the thing is evaluated and the value
treated as if it were a CREATE form; that is, the only difference between
CREATE and CCREATE is that CCREATE does an EVAL before doing the subst
that CREATE does.

When the CCREATE form is evaluated, the variables FIELDS.IN.CREATE,
USINGTYPE, and USINGEXPR may be interrogated.

You had some application with SEED and PRODUCT that you wanted to use
this with -- will this help?

Larry
-------
23-AUG-76 02:33:56-PDT,1354;000000000001
Date: 23 AUG 1976 0233-PDT
From: MASINTER
Subject: record, datatype
To:   TEitelman

New RECORD, DATATYPE and RECORD.COM on <NEWLISP>. Changes:

(a) I fixed a bug in the path-finding code which happened when
the desired field was in a separate declaration and there
was a field with the same name in an embedded declaration.

(b) I re-wrote almost all of the DATATYPE code: the format of
a "field descriptor" is no longer a list (BITS n1 n2 ..) or
(POINTER ...) etc but rather is a large number. Expressions
involving datatype expressions should compile as before.
Interpreted code using datatypes should be much faster.
The format of a field descriptor is as follows (for the record):

the field-descriptor resembles a byte pointer

bits 0-5 (from the left) contains the number of bits to the right
	of the given field
bits 6-11 contains the number of bits in the field
bits 13-14 contain the "field type":
	0 is a pointer field
	1 is a number field
	2 is a floating-point field
	3 is a "flag" field
Bits 15-19 are currently unused
Bits 21-26 contain the datatype number (or 0 if fetch/replace should not
	check)
Bits 27-36 contain the word offset of this field

bit 20 is set if the field is either floating or flag; it
signifies that this field-descriptor is not implemented in microcode
on Maxc.

Larry
-------
 9-JAN-77 23:26:43-PST,812;000000000001
Date:  9 JAN 1977 2326-PST
From: TEITELMAN
Subject: EDITOR
To:   DRB at SU-AI
cc:   MASINTER



Dave,

whatyou want to do has been asked for before and an
undocumented hook installed. this has remained fairly
stable for a while so you probaby are ok to use it.
ther is a function called EDITF1 which is
used by EDITF, EDITV, and EDITP. it has
five arguments, EXPR, COMS, ATM, TYPE, and IFCHANGEDFN
TYPE currently is NIL, PROP, or T, and is used
to distinguish the calls from editf, editv, etc.
in any case, if IFCHANGEDFN is not NIL, and
the edit results in a change, then IFCHANGEDFN is
applied to ATM and EXPR. (i suppose it really shuld
also be given ty`pe so you can use the same
function for diffrent types, but anyway this
should be sufficient for your purposes.

warren
-------
25-MAR-77 23:08:19-PST,2351;000000000001
Date: 25 MAR 1977 2308-PST
From: TEITELMAN
Subject: internal iterative variables
To:   KAPLAN


ron,

not all of the informationyou want is available when you want it.
in fact puting in the EVAL form of i.s.opr took me about two weeks
because the situation is as follows
(1) you cant dwimify their operands until the
entire i.s. has been scanned and all the vars found
(2) but some i.s.oprs might contain BINDS etc. so is important
to expand the i.s.oprs before dwimifying any of them, however
(3) one cannot substitute in the operands into the i.s.opr
definitions until after dwiifying since othrwise any oerrors corrected
in the operands wont be seen int he oriiginal i.s.
furthermore
(4) if i subsitute in beofe dwimifying, i cnt distinguish case where
user wirtes a $$VAL, thereby requiring a PROG in the
translation, or one comes as a result of an i.s.opr  xpansion
such as collect.


now for the particulars of your requests:

if all you want to do is see if some other operrtor has been
seen prevously in the i.s., this is smple. there is
a variable called i.s.ptrs, which is a list of the i.s.oprs
seen. CAR of each entry is the lowercase version of the i.s.
(in the current lisp, this variable is called forptrs in case
you want to  xperiment). so you can in fact determine if
a dfor has been seen at the time of  xpanding a dbind.


the tail of the i.s. immediatel foollowing the operatr is also
available at eval time, as is the tail of the i.s. as of
the next operator, i.e. everything between the two tails
(after dwiifying which doesnt happen till later) will be
the body. the way you find this is 
each element on i.s.ptrs is of the form
(opr tail1 tail2) where tail1 points into th i.s. as of
opr (however, (CAR of thattail may not be equal to opr,
e.g. CAR may be the uppercase version, opr the lower case,
or in the caseof an i.s.type opr will be the atm
i.s.type, but car of tail1 may be do, collect, etc.)
tail2 points to he next opr. so what you want is
cdr of tail1, i.e. (CDR (CADR (CAR LAST I.S.PTRS)))

note however that if you depend on this sort of thing,
then for your dfor, you will have to either handle the
cases (DFOR X INTEGER --) (DFOR (X INTEGER) --)
(DFOR X _ & INTEGER _ & --) etc. all yourself,
or else restrict yourself. 

more to come

warren
-------
 1-MAY-77 09:14:25-PDT,952;000000000001
Date:  1 MAY 1977 0914-PDT
From: DEUTSCH
Subject: BREAKDOWN
To:   teitelman

Yes, I'm willing to negotiate.  I'll specify the data structures later,
but here is the interface I have in mind:
1) To specify measuring several things at once, simply set BRKDWNTYPE
to a list, e.g. (TIME CONSES).  I haven't yet figured out a nice
format for printing out the results if they won't fit on one line --
maybe you have some suggestions for that.
2) To specify open compilation of the BRKDWN2 form, set
BREAKDOWNCOMPFLG to T (initially NIL).  As long as this flag is T,
any newly BREAKDOWN'ed functions, or ALL functions if you change
BRKDWNTYPE, will use open code for BRKDWN2 (less time overhead,
more space).  Any mix of open and closed code is permissible,
i.e. things will be OK no matter or how often you change the flag
setting.  I think it might also be worth indicating on the RESULTS
printout which functions use open code.
-------
 1-MAY-77 15:56:09-PDT,389;000000000001
Date:  1 MAY 1977 1556-PDT
From: DEUTSCH
Subject: printing multiple stats
To:   teitelman

As a first cut, I am just producing a separate listing in the
current format for each statistic being measured, e.g.
FNS	TIME	# CALLS	PER CALL	%
...

FNS	CONSES	# CALLS	PER CALL	%
...

I am not wildly happy about this, but it will do until we can
think of something better.
-------
31-MAY-77 23:46:41-PDT,762;000000000001
Date: 31 MAY 1977 2346-PDT
From: DEUTSCH
Subject: New BRKDWN
To:   TEITELMAN

I can have it ready for you tomorrow if you want it.

The new capabilities are all backward-compatible.  THe changes are
as follows:
1) BRKDWNTYPE can be a list of types, all those things will be measured.
2) If BRKDWNCOMPFLG is non-NIL, the BRKDWN2's are expanded in-line,
leading to much more precise measurements at a substantial cost in
code space, plus considerably longer setup time (for some reason the
compiler seems to be very slow, even on fairly simple functions).

If you and/or Mitch want to do someting about a bargraph display,
I will change RESULTS so you can get it to deliver the results in
a nice list form rather than printing them out.
-------
 1-JUN-77 14:51:51-PDT,1142;000000000000
Date:  1 JUN 1977 1451-PDT
From: DEUTSCH
Subject: BRKDWN
To:   TEITELMAN

You may take the version from <DEUTSCH> on Maxc2.  It works as far
as I can tell.  It includes multiple measurements and BRKDWNCOMPFLG.

I don't think a name like RESULTS belongs in a package like BREAKDOWN,
so I renamed the function that does the work as BRKDWNRESULTS and
just made RESULTS call it with no arguments.  My feeling is that
extensions to result reporting, like you and Mitch might want, should
go in BRKDWNRESULTS.

I've implemented one such extension: (BRKDWNRESULTS T) returns the
results in a list whose elements are of the form (function ncalls
stat1 ... statn) where the stat1 ... statn are raw data, divided by
the repetition counts if any but not by the number of calls, and in the
order given by BRKDWNLABELS (a copy of the original BRKDWNTYPE).
The intention is that later you could give BRKDWNRESULTS a list to
smash the results into, e.g. if you only wanted them for one function
you would give it a list of one such element.  I'm not sure this is the
best way to go, so you might consider not publicizing it.
-------
12-JUN-78 02:08:40-PDT,470;000000000001
Date: 12 JUN 1978 0208-PDT
From: TEITELMAN
Subject: clispdec
To:   alfvin at USC-ISIE


the quoted list (+ - * / +- LT GT) that appeared in
clispdec is now parameterized to be the value of CLISPARITHOPLST.
the quoted list (INTEGER FIXED MIXED FLOATING) is the value
of CLISPARITHCLASSLST. feel free to reset or
rebind these. however, i dont think i will document
this feature.

(note this wont take effect until next loadup and release)

warren
-------
29-JUN-78 16:42:29-PDT,1450;000000000000
Date: 29 JUN 1978 1642-PDT
From: TEITELMAN
Subject: BRACKETS IN CLISP
To:   CROCKER at ISIE, KAPLAN


havent worked out all the details yet but

(1) would you want to translate a bracket one way sometimes
and another way another time, e.g. translate {1,2}
differently than {1}, like use ELT for one and MULTI-ELT or
some such for another

(2) would you ever want to use more than one "separator"
inside of a bracket, such as ,'s mixed with
;

(3) if the latter, would it be tolerable to have to do your
own clispifying on this particular car of form via
a clispifyuserfn? i.e. suppose i clispified by simply
keying off car of form, and if it was a bracket translator,
put in the brackets (preceded by the first operand if
not a unaryop) and put in the ,'s or ;'s or whatever was
specified as the "separator" .

e.g. supose we define {} as a binary bracket operator
so that A{1} goes to (ELT A 1), and
A{1,2} goes to (MULTIELT A 1 2), 
then ELT and MULTIELT would always clispify
as A{1} and A{1,2}  but if you wanted
A{1,2;3} to mean something else (which
is acceptable since you get to specify a translation
function), then you would have to handle your own clispifying
because i wouldnt know how to put in , or ;.

basically i will let you specify "separator" characters
and explode them out but not do anything else with them
when dwimifying, and i will put them back in when
clispifying.

warren
-------
 2-JUL-78 22:28:17-PDT,291;000000000001
Date:  2 JUL 1978 2228-PDT
From: TEITELMAN


dontsavehistorycoms is a list of comands not saved by edit
history. initially SAVE P ? PP PP* and E.
compacthistorycoms is a lit of commands to be compacted and
is initially NIL. numbers ae automatically on compacthistorycoms.

-------
22-JUL-78 18:51:01-PDT,681;000000000001
Date: 22 JUL 1978 1851-PDT
From: TEITELMAN
Subject: filecreated and tops-20



larry,

marty observed to me that when moving a file from a tenex
site to a tops-20 site and then loading the file, the filpkg
gets confused because the name on the filedates, as obtained
from the filecreated expression, now correspond to a different
naming convention. thus even if one is careful to maintain
directory and version number, things still foul up. a simple
solution semeed to be to make filecreated
to a (packfilename (unpackfilename   on the file. this
costs 8 conses per filecreated. i have installed this.
do you have any objections or comments?

warren

-------
 3-AUG-78 12:36:50-PDT,908;000000000001
Date:  3 AUG 1978 1236-PDT
From: TEITELMAN
Subject: greeting
To:   kaplan, masinter


greetdirectory  is the directory on which the system initiatlizatio file
is to be found. initially LISP

greetfile  is the name of the file, initially INIT

greetext is the name of the extention, initially LISP

greetfile and greetext apply to both the system initialization
file and the users. the users file is always on his directory.

note that greetdirectory would only be of use for makesyses
or sysout other than lisp since there is no way for
thatto be changed before it gets acessed, however it wuld
be possible to put in init.lisp something which changed
greetfile and greetext if a site wished to hae the init files
stored on otherthan init.lisp. however, the main purpose of
making these variables is to aid implementors in setting
up their own makesyses or sysouts.

warren
-------
27-SEP-78 02:47:06-PDT,952;000000000001
Date: 27 SEP 1978 0247-PDT
From: MASINTER
Subject: JSYS error

It is now the case that JSYS calls which are followed by
a JUMP (of any kind, not just ERJMP and ERCAL) which cause
an illegal instruction trap, that the Lisp trap handler
will resume the computation at the effective address of
the JUMP instruction (normally JUMP is a  no-op).

By careful coding, it is possible to write JSYS calls
which will not cause a "TRAP AT LOCATION" either on
TENEX or TOPS-20.

In addition, any JSYS trap in which the next instruction
after the JSYS is a JFCL is assumed to be a "user JSYS"
(i.e. rather than one of the ones in the system which
are "critical region") and, rather than a TRAP AT LOCATION nnnn
being executed, the error, JSYS ERROR (error number 0)
is invoked.

The "offender" (CADR (ERRORN)) of error 0 is always the
error code. This permits an ERRORTYPELST entry which
would print the error message out.

Larry
-------
10-OCT-78 17:16:30-PDT,2020;000000000001
Date: 10 Oct 1978 5:16 pm (Tuesday)
From: Masinter
Subject: FILES as a file package command
To: Teitelman
cc:  Masinter, Deutsch, Kaplan

I wasn't going to document this before the manual went out, to save you some
trouble and becasue it wasn't very well defined. I have since been using it for a
while and think it is clean enough to let others use it; however I think it is still
reasonable to leave this out of the manual and just distribute the documentation
informally. 

There is a new file package command FILES, which specifies that certain files
are to be loaded with the given file is loaded.

(FILES FOO FUM) dumps on the file

(LOAD? (QUOTE FOO.COM) LDFLG)
(LOAD? (QUOTE FUM.COM) LDFLG)

The elements of the FILES command are the (namefield) of the files to load.
There are actually several other ways to load in files; the FILES? command
interprets LISTP elements of the commands as a series of tokens which change its
state. Those tokens can be:

to change aspects of the file loaded:
(FROM directory)    -- pack the given directory onto the beginning of the
		file, e.g. (FILES (FROM LISPUSERS) CJSYS)
(SOURCE)	-- load source version rather than compiled
(COMPILED)	-- load the compiled version (default)

to change the loading function:
(LOADCOMP)	-- use LOADCOMP? rather than LOAD?; automatically
			implies SOURCE
(LOAD)		-- use LOAD? (default)
(LOADFROM)	-- use LOADFROM 

to change the value of LDFLG in the call:
(SYSLOAD) -- use (QUOTE SYSLOAD) as the value of LDFLG
(PROP)
(ALLPROP) 

These tokens can actually be joined together in a single list, e.g. an actual
command in the FTP package is:

(DECLARE: EVAL@COMPILE DONTCOPY
	(FILES (LOADCOMP) NET (SYSLOAD FROM LISPUSERS) CJSYS))


Future extensions might include: allowing a list of directories in the FROM
specification; changing the implementation of the command so that the
COMPILE.EXT used when loading compiled files is determined at load time rather
than at makefile time.

Larry

16-OCT-78 13:42:38-PDT,1109;000000000001
Date: 16 Oct 1978 1:42 pm (Monday)
From: Masinter
Subject: bug fixes
To: Teitelman
cc: Lisp, masinter

I fixed the following "glitches" in FILEPKG:

HASDEF, GETDEF now only accept file package types (not commands), e.g.
GETDEF(FOO COMS) causes error "COMS not file package type". 

(undocumented feature)  The USERMACROS file package command will now also
dump entries on EDITMACROS as well (so that system files can contain
EDITMACROS entries).

(implementation change)
GETDEF(X FILES) now returns a more complicated data structure than before (it
used to just return the COMS for the file, now the value of GETDEF includes
part of the FILE and FILEDATES property of X).

PUTDEF(X FILE DEFINITION) will MAKEFILE(X) copying functions if
necessary from the "old" file (supplied as part of the DEFINITION).

This change should not affect any users (the only use I have ever
made of FILES as a type is to rename them); it made it possible to remove a
special check in the COPYDEF function to handle this case.

(fix to FULLNAME)
Fixed FULLNAME((A)) to cause ARG NOT LITATOM error.

17-OCT-78 19:16:08-PDT,867;000000000001
Date: 17 OCT 1978 1916-PDT
From: TEITELMAN
Subject: ( Forwarded Mail )
To:   LISP

Date: 17 Oct 1978 2205-EDT
From: LEWIS at BBN-TENEXD
Subject: set a/c link
To:   bobrow at MAXC2
cc:   YONKE, VITTAL, masinter at MAXC2, TEITELMAN at PARC-MAXC2

Danny,

It is now written and will be in the next lisp.mac (alice currently
has a hold on the file for a bug fix).
I made one change.  The fns take a 3rd arg, FLG.
If FLG=non-nil then NEWFRAME will be released if the change succeeds.
eg, if you want to do the smash and release all the stack pointers,
put still catch things if the smash fails, you could say

(if not (RELSTK (SETALINK FOO FUM T)) then (SMASHLINKERROR FOO FUM))

or some such.

Daryle

p.s. A test case I was using was setalink[foo;fum] followed by
setclink[fum;foo].  How's that for a case of lisp incest?
-------

-------
18-OCT-78 11:39:21-PDT,2350;000000000000
Date: 18 Oct 1978 11:38 am (Wednesday)
From: bobrow at PARC-MAXC
Subject: Documentation for SetAlink, etc
To: LEWIS at BBN-TENEXD,HARTLEY at BBN-TENEXD
cc: Teitelman,lisp,bobrow

This is the documentation for setalink, and setclink as I now understand them to
be implemented.  Thanks for looking at them so soon.


There are four primitive functions for manipulating the ALINK and CLINK of a
frame.  Combined with the functions for manipulating the structures of a single
frame (stknargs, stkname, setstkname, stkarg, setstkarg, stkargname,
setstkargname) and those for setting up a new frame with specified access and
control links (enveval, envapply), they form a complete set of primitives for
manipulating the control structures of Lisp.  Although all the other functions
can be written in terms of these primitives, the user will usually want to use the
higher level functions described above.

alink[pos, opos) returns a stack pointer to the frame which is referred to by the
access link of the frame specified by pos.  If opos is supplied, and is a
stackpointer, it is reused.  Returns T if the access link points to the top level. 
Same as stknth(1,pos,opos)

clink[pos, opos) returns a stack pointer to the frame which is referred to by the
control link of the frame specified by pos.  If opos is supplied, and is a
stackpointer, it is reused.  Returns T if the control link points to the top level. 
Same as stknth(-1,pos,opos)

setalink[pos, newpos, relflg] sets the alink of the frame specified by pos to be the
frame specified by newpos.  Causes an error if the access chain of the frame
specified by newpos contains the frame specified by pos.  This prevents the user
from accidentally creating a circular access chain.  If there is no error, and relflg
is nonNil, and newpos is a stackpointer, then newpos is released.  Returns pos if
there was no error.

setclink[pos, newpos, relflg] sets the control of the frame specified by pos to be
the frame specified by newpos.  Causes an error if the control chain of the frame
specified by newpos contains the frame specified by pos.  This prevents the user
from accidentally creating a circular control chain.  If there is no error, and
relflg is nonNil, and newpos is a stackpointer, then newpos is released.  Returns
pos if there was no error.

18-OCT-78 12:27:03-PDT,559;000000000001
Date: 18 Oct 1978 1504-EDT
Sender: LEWIS at BBN-TENEXD
Subject: Re: Documentation for SetAlink, etc
From: LEWIS at BBN-TENEXD
To: bobrow at PARC-MAXC
Cc: HARTLEY, Teitelman at PARC-MAXC, lisp at PARC-MAXC
Message-ID: <[BBN-TENEXD]18-Oct-78 15:04:00.LEWIS>
In-Reply-To: Your message of October 18, 1978

Two points:
(1) set a/c link does not generate an error when attempting to create
a circular structure.  They just return NIL.

(2) if alink and clink are really provided, they should have macros
that expand into the stknth forms.

Daryle
19-OCT-78 12:04:50-PDT,2299;000000000001
Date: 19 Oct 1978 12:04 pm (Thursday)
From: bobrow at PARC-MAXC
Subject: Revised Documentation for SetAlink, etc
To: LEWIS at BBN-TENEXD,HARTLEY at BBN-TENEXD
cc: Teitelman,lisp,bobrow

This is the revised documentation for setalink, and setclink based on Daryl's last
comment.


There are four primitive functions for manipulating the ALINK and CLINK of a
frame.  Combined with the functions for manipulating the structures of a single
frame (stknargs, stkname, setstkname, stkarg, setstkarg, stkargname,
setstkargname) and those for setting up a new frame with specified access and
control links (enveval, envapply), they form a complete set of primitives for
manipulating the control structures of Lisp.  Although all the other functions
can be written in terms of these primitives, the user will usually want to use the
higher level functions described above.

alink[pos, opos) returns a stack pointer to the frame which is referred to by the
access link of the frame specified by pos.  If opos is supplied, and is a
stackpointer, it is reused.  Returns T if the access link points to the top level. 
Same as stknth(1,pos,opos)

clink[pos, opos) returns a stack pointer to the frame which is referred to by the
control link of the frame specified by pos.  If opos is supplied, and is a
stackpointer, it is reused.  Returns T if the control link points to the top level. 
Same as stknth(-1,pos,opos)

setalink[pos, newpos, relflg] sets the alink of the frame specified by pos to be the
frame specified by newpos.  Returns NIL, and does not set the link if the access
chain of the frame specified by newpos contains the frame specified by pos. 
This prevents the user from accidentally creating a circular access chain. 
Returns pos otherwise, and if relflg is nonNil, and newpos is a stackpointer, then
newpos is released.

setclink[pos, newpos, relflg] sets the control of the frame specified by pos to be
the frame specified by newpos.  Returns NIL, and does not set the link if the
control chain of the frame specified by newpos contains the frame specified by
pos.  This prevents the user from accidentally creating a circular control chain. 
Returns pos otherwise, and if relflg is nonNil, and newpos is a stackpointer, then
newpos is released.


20-OCT-78 17:43:38-PDT,914;000000000001
Date: 20 Oct 1978 5:43 pm (Friday)
From: Masinter
To: laaser, lisp
Subject: cc: of message re: FAKESYS

Subject: MAKESYS -> FAKESYS

Through a coincidence I realized that it was possible to have a
lisp system which was a "sysout" in which a "makesys" had never
been done. The importance of this is that such a sysout would
be a good base in which to load up other packages (and in which
to get rid of packages) because the space had never been tied
down as system code.

There is a function fakesys[file] on [maxc2]<newlisp>fakesys which
creates such a sysout (all it does is to fool the system into
thinking it is in a makesys on <lisp>boot.sav and then call the
(unadvised version of) sysout. The reason for calling the unadvised
version is that, as a system which is just intended to save part
of the loadup state, none of the GREET or SYSOUTFORMS operations
should be performed).

Larry
24-OCT-78 23:18:26-PDT,392;000000000001
Date: 24 OCT 1978 2318-PDT
From: TEITELMAN
Subject: lower case spelling correction
To:   masinter, HTHOMPSON
cc:   fikes, bobrow, lisp


athenry's request, dwim will now ask for approval on
spelling correction involving simple case shiftts
when the correction is to a user program. it used to
always perform the correction qithout any approval
or notification.

warren
-------
29-OCT-78 22:12:07-PST,1178;000000000000
Date: 29 OCT 1978 2212-PST
From: TEITELMAN
Subject: VALUEOF
To:   LISP



the problem with valueof is how to  decide whethe or
not the event that caused the call to valueof is to be considered
when handling negative event specifications. it used
to be the case that valueof siplemindedly always backed
up the history list one, i.e. always ignored the current
event. thus your show comand worked. hwever,
if the user typed to the editor (I : (VALUEOF-1)), this
was incorrectly handled, since in this case, the event
causing the call to VALUEOF was not on the history list.
e.g. if user typed E -- and then (I : (VALUEOF -1))
the last event on lispxhistry was the -- from the E.

i changed VALUEOF therefore to check and see whethe
VALUEOF itself appeared in the type in. obviously this
is too strong a check for your case
where the user types in an expression which causes
a call to valueof via the SHOW command. the best i can do
for you i think is to separate out VALUEOF into two functions
and let you call a lower function with the event spec and
a flag which indictes whether or not to backup.
i am open to other suggestions.

warre

-------
30-OCT-78 10:39:46-PST,570;000000000000
Date: 30 OCT 1978 1039-PST
From: TEITELMAN
Subject: LISP
To:   LISP

Date: 30 Oct 1978 0953-EST
Sender: LEWIS at BBN-TENEXD
Subject: FILES
From: LEWIS at BBN-TENEXD
To: TEITELMAN at MAXC2
Cc: HARTLEY, MASINTER at MAXC2
Message-ID: <[BBN-TENEXD]30-Oct-78 09:53:08.LEWIS>

New lisp.mac .symbols .pdq on <newlisp>.
The determination of which format word to use for outputing
floating point numbers has been tied to PRXFLG.
eg, PACK will use the system default format rather than what the
user has set up via fltfmt (unless PRXFLG=T).

Daryle

-------
 5-NOV-78 19:22:55-PST,1416;000000000000
Date:  5 NOV 1978 1922-PST
From: TEITELMAN
Subject: fileinfo
To:   lisp

Date:  5 Nov 1978 1719-EST
From: VITTAL at BBN-TENEXD
Subject: fileinfo
To:   teitelman at MAXC2, masinter at MAXC2
cc:   kaplan at MAXC2

There is a new fileinfo on <vittal>.  It should work thru dec release 4
(to be announced come the beginning of the year), and includes the following
changes over the last one that I gave you.

1.  getfileinfo now takes a third argument that is equivalent to the 3rd 
    argument of gdate.  It works (I hope) for all calls to gdate (attributes
    readdate, writedate and creationdate), and attribute author (a new 
    attribute which returns the author of a file as a string -- clobbers the
    string pointer only on tops-20 versions release 3 and higher.  It
    could work for everything else if somebody fixed USERNAME to
    do the same thing gdate does.  Should I do it?).

2.  The archive/invisible/off-line stuff should only work for BBN release
    1B of tops-20, and DEC release 4 (which, for all intents, will be the
    same as bbn release 3A).  It should also not crash if tried under
    standard DEC releases without archive stuff -- e.g. releases 1, 2 and 3.

    Turns out that the way to tell what release a tops-20 site is running
    is by looking at the length of an fdb.  Look at function fisystemtype
    for specifics.

John
-------

-------
 9-NOV-78 23:27:51-PST,537;000000000000
Date:  9 NOV 1978 2327-PST
From: TEITELMAN
Subject: change to username
To:   lisp, yonke at BBND

Date: 9 Nov 1978 1535-EST
Sender: LEWIS at BBN-TENEXD
Subject: files
From: LEWIS at BBN-TENEXD
To: teitelman at PARC-MAXC2, hartley
Cc: masinter at MAXC2, vittal
Message-ID: <[BBN-TENEXD] 9-Nov-78 15:35:10.LEWIS>

New mac & .com on <newlisp>.
USERNAME now take a 2nd arg, FLG, which is a string ptr to smash.
I didnt use the name STRPTR because I plan to later add Marty's
request using the same arg.

Daryle

-------
13-NOV-78 23:25:44-PST,135;000000000000
Date: 13 NOV 1978 2325-PST
From: TEITELMAN
Subject: makekeylst
To:   lisp


now takes autocompleteflg as an argument

-------
13-NOV-78 23:26:21-PST,225;000000000000
Date: 13 NOV 1978 2326-PST
From: TEITELMAN
Subject: getcomment
To:   james at USC-ECL
cc:   lisp


now prints an error message (once) if the file that
the comment pointer points at has disapeared.

warren
-------
15-NOV-78 18:01:28-PST,306;000000000000
Date: 15 NOV 1978 1801-PST
From: TEITELMAN
Subject: errortypelst
To:   LISP, MASINTER, lewis at BBND


now is a list of expressions of the form (n . expressions) rather than (n expression).
this so you can have several for the same errortype
and will do them one after another.

warren
-------
15-NOV-78 22:29:52-PST,756;000000000000
Date: 15 NOV 1978 2229-PST
From: TEITELMAN
Subject: your problem with fltfmt
To:   YONKE at BBND
cc:   MASINTER, LEWIS at BBND, LISP


in version 124, the determination of which format word to use
for outputing floatng point numbers has been tied to PRXFLG., e.g.
pack (and mkstring) will use the system default format rather than
what the user has set via fltfmt (uless prxflg=T). this is consistent
the interaction between radix and pack and mkstring. the purpose
was that a numbe of clisp constructs e.g. <X 0.0>  would not
dwimify correctly if fltfmt was changed.
the problem hs nothing whatsoever to do with printnum.


daryle - i wonder if we shuld not simply default prxflg to T
and have dwim rebind it to NIL?

warren
-------
19-NOV-78 14:18:40-PST,1042;000000000000
Date: 19 NOV 1978 1418-PST
From: MASINTER
Subject: various fixes
To:   Teitelman
cc:   Lisp, Masinter

Fixed masterscope so that it does not call LOADEFS with the filename
from the FILEDATES property (i.e., if the file moves, it will use FINDFILE
to find it).

fixed RECORD so that if a field has both a sub-declaration and a
default value, as in
(RECORD FOO (A . B) (RECORD B (C . D)) B _ NIL)

that a CREATE expression will use the default value for B (i.e. B=NIL)
unless one of the fields of the sub-declaration is given; in the above
example, that means that (create FOO) returns (LIST NIL), but
(create FOO C _ 3) returns (LIST NIL 3). {fix to problem report from
AThompson at USC-ECL}.

I fixed UNSAVEFNS in Masterscope so that (a) it doesn't leave the file
open, (b) the (loaded FN) message comes after it loads it in, and 
(c) the error message is fixed.

I fixed the record package not to attempt to do spelling corrections
on the function names used in the tail of declarations.

(more to come)
-------
19-NOV-78 15:50:06-PST,903;000000000000
Date: 19 NOV 1978 1550-PST
From: MASINTER
Subject: other fixes
To:   Teitelman
cc:   Lisp, Masinter

new UTILITY & .COM:
Fixed DIRECTORY to put back in the TRIMTO option (request from Vittal,
as the OLDVERSIONS feature I had put in before did not work
for TOPS-20. Note that several versions ago, I installed a new
DIRECTORY package with several new features which I need
to document -in particular, I moved over some of the things
which were in EXEC where the cost of having them in the code
was slight). Main important feature is that the DELETE and
UNDELETE options of a DIR command are undoable; /DELFILE and
/UNDELFILE are included in the system. 

new FILEPKG & .COM:
I fixed LOADDEF not to print (fn REDEFINED) (or to mark fn as
changed) if the function was merely being unsaved from an
EXPR property or loaded from a file (unless it is also on
some other file).

-------
19-NOV-78 16:07:34-PST,215;000000000000
Date: 19 NOV 1978 1607-PST
From: MASINTER
To:   LISP

The new name for what the manual calls MOVEITEM is MOVETOFILE.
I wish I had thought of the better name before the manual went
to press.

Larry
-------
 2-DEC-78 14:49:13-PST,347;000000000000
Date:  2 DEC 1978 1449-PST
From: MASINTER
Subject: FILEPKGTYPE now allowed as synonym for FILEPKGCOM in calls to GETDEF, EDITDEF
To:   Kaplan
cc:   Lisp

at your suggestion (of 21 Nov).

Also, the 'GETDEF' property of a file package type is passed OPTIONS as a
3rd argument (it is now called with (NAME TYPE OPTIONS)).

Larry
-------
 2-DEC-78 17:04:49-PST,364;000000000000
Date:  2 DEC 1978 1704-PST
From: MASINTER
Subject: masterscope changes
To:   TEITELMAN
cc:   lisp, masinter

I added a template for EVALA.

I fixed parser confusion with the word 'GLOBALVARS', and with the construction
'AND NOT' (although WHO something AND NOT something WHO is still treated as
WHO something AND NOT something ANY).

Larry

-------
 2-DEC-78 17:08:04-PST,252;000000000000
Date: 2 Dec 1978 5:07 pm (Saturday)
From: Masinter
Subject: Re: masterscope
To: TEITELMAN, LISP
cc: MASINTER

I also fixed so that CHECK BLOCKS will not report unecessary SPECVARS unless
the variables are explicitly declared SPECVARS.

Larry
 3-DEC-78 15:57:42-PST,3131;000000000000
Date: 3 Dec 1978 3:57 pm (Sunday)
From: Masinter
Subject: new DIR features
To: lisp
cc: Masinter

a couple of weeks (months?) ago, I installed a new version of the DIRECTORY
package, with a couple of things cleaned up. This version has been stable long
enough that I am now documenting the new features.

The following is a complete list of the 'commands' recognized by the DIRECTORY
processor (some of these are old, and some are new):

commands which print something:

P	prints file name
PP	prints file name sans version (used by NDIR)

SIZE, READDATE, WRITEDATE, CREATIONDATE, LENGTH, BYTESIZE, 
PROTECTION, AUTHOR
	prints the appropriate information returned by GETFILEINFO.
	(the list fileinfotypes provides additional formatting information to
	the directory function).

"string"		print the given string


commands which affect the value returned:

COLLECT   	the value of DIRECTORY is a list of file names; add
		this file name to that list
COUNTSIZE	the value of DIRECTORY is a sum. Add the SIZE of
		this file to the sum.


interactive commands:

PAUSE	wait until the user types something before proceeding with
	the rest of the commands.

arbitrary expression or predicate:

@ expression	the expression following an @-sign is either a function
		of one argument (JFN), a function of two arguments
		(JFN FILENAME) or an arbitrary expression which uses
		JFN and/or FILENAME freely. (it is a minor efficiency hack
		that if FILENAME is not used in the expression, it isn't
		computed).

OLDERTHAN n	proceed if the file hasn't been referenced (read or 
		written) in n days; e.g. DIR *.* OLDERTHAN 90 P DELETE
		will delete all files not referenced in 90 days).

BY user	proceed if the file was last written by the given user.

OLDVERSIONS n	proceed if there are at least n more recent versions
		of the same file (note that this IS NOT IMPLEMENTED for
		TOPS20 and DIRECTORY will complain if you try to
		use it on a TOPS-20 system). For example, to delete all
		but the most recent version of a file,
		DIR FILE OLDVERSIONS 1 P DELETE

set internal directory state:

DELETED	allow DIRECTORY to examine deleted files (normally, they
		are not mapped over).
OUT filename	direct all output to given filename
COLUMNS n	attempt to format output in n columns (rather than
		just 1).

perform actions on the given file:

DELETE	delete the file (undoably!)
UNDELETE	un-delete the file (undoably!). This also does a 'DELETED'
		so that DIRECTORY only considers deleted files.


As before, DIRCOMMANDS is used as a spelling list and to supply defaults and
abbreviations. Valid shorthand commands are:

AU 		 AUTHOR
-  		 PAUSE
COLLECT?	PROMPT " ? " COLLECT
DA, TI		WRITEDATE
DEL		DELETE
DEL?, DELETE?	PROMPT " delete? " DELETE
OLD		OLDERTHAN 90
PR		PROTECTION
SI		SIZE



Also as part of the DIRECTORY package, the functions

/delfile[filename]	delete filename (undoably).
undelfile[filename]	undelete filename
/undelfile[filename]	undelete filename (undoably)

are provided. At type-in, delfile is converted to /delfile.

Larry 
 4-DEC-78 10:05:59-PST,768;000000000000
Date:  4 DEC 1978 1005-PST
From: MASINTER
Subject: recent changes
To:   Teitelman, Kaplan
cc:   Lisp, Masinter

(a) the definition of HASDEF had been extended from that described in
the manual to allowing spelling correction:

hasdef[name;type;spellflg]   returns name if name has a definition
		as a type; attempts spelling correction if not and if
		spellflg=T. 

At Ron's request, hasdef[NIL;type] will return T if NIL has a valid
definition.

(b) I fixed a bug relating to files getting marked as needing to
be dumped if they contained an ALISTS command and any alist got changed.

-----

there is a new HELPDL with a change to LISPINTERRUPTS at Danny's request.

-----

I don't have anything left on my lisp-bug queue.

Larry
-------
13-DEC-78 11:47:37-PST,220;000000000000
Date: 13 DEC 1978 1147-PST
From: MASINTER
Subject: another fix to DIR
To:   Teitelman
cc:   Lisp, Masinter

New UTILITY & .COM on <newlisp> with another bug having
to do with DIR files + files.

Larry
-------
14-DEC-78 11:25:37-PST,2045;000000000000
Date: 14 DEC 1978 1125-PST
From: TEITELMAN
Subject: SELECT
To:   lisp

Date: 14 Dec 1978 0858-EST
Sender: LEWIS at BBN-TENEXD
Subject: SELECT
From: LEWIS at BBN-TENEXD
To: teitelman at MAXC2, masinter at MAXC2
Cc: hartley, yonke
Message-ID: <[BBN-TENEXD]14-Dec-78 08:58:44.LEWIS>

[Below is the documentation for a new system function SELECT.  The
documentation is written assuming it follows the description of SELECTQ
in the manual (Section 5).  Subscripts are enclosed in <> (e.g.,
"e sub i" is written as e<i>).]

=============================================================

select[x;clause<1>;clause<2>;...;clause<n>;default]

        -  SELECT is similiar to SELECTQ except that the selection
           key (s<i>) is evaluated before the EQ test.

           That is, if s<i> is an atom, the value of x is tested to
           see if it is EQ to the value of s<i>.  If so, the
           expressions e<1i> ...  e<ki> are evaluated in sequence,
           and the value of the SELECT is the value of the last
           expression evaluated, i.e., e<ki>.

           If s<i> is a list, the value of x is compared with the
           value of each element of s<i>, and if x is EQ to any one
           of them, then e<1i> to e<ki> are evaluated in turn as
           above.  Note that if is s<i> is (FOO FIE) the test is
                (OR (EQ x FOO) (EQ x FIE)).
           To get the test
                (EQ x (FOO FIE)),
           s<i> should be ((FOO FIE)).

           If clause<i> is not selected in one of the two ways
           described, clause<i>+1 is tested, etc., until all the
           clause's have been tested.  If none is selected, the value
           of the SELECT is the value of default.  default must be
           present.

           SELECT compiles open, and is therefore very fast; however,
           it will not work if the value of x is a large integer or
           floating point number, since SELECT uses EQ for all
           comparisons.

-------
14-DEC-78 11:46:59-PST,686;000000000000
Date: 14 DEC 1978 1146-PST
From: TEITELMAN
Subject: username, hostname extra argument
To:   lisp

Date: 14 Dec 1978 1326-EST
Sender: LEWIS at BBN-TENEXD
Subject: FILES
From: LEWIS at BBN-TENEXD
To: TEITELMAN at MAXC2, MASINTER at MAXC2
Cc: HARTLEY, YONKE
Message-ID: <[BBN-TENEXD]14-Dec-78 13:26:08.LEWIS>

New mac & .com on <newlisp>.
The the FLG arg of USERNAME has now been expanded so that
if FLG is not a string pointer and non-nil, then
username will return it's result as an atom.

the FLG arg has also been added to HOSTNAME.

for macscratchstring hackers: The new fn ATMCONC0 is like STRCONC0 but
returns an atom instead of a string.

Daryle

-------
16-DEC-78 17:49:43-PST,152;000000000000
Date: 16 DEC 1978 1749-PST
From: TEITELMAN
Subject: backtrace
To:   lisp


p. 12.12  everything will be printed if flags=47q,  not 7.

-------
18-DEC-78 14:20:30-PST,567;000000000000
Date: 18 Dec 1978 2:20 pm (Monday)
From: Laaser
Subject: Re:
In-reply-to: Your message of 18 DEC 1978 1058-PST.
To: TEITELMAN
cc: LISP, LAASER

Here are the typos I found in the manual.

Page 4.1 -- first new line (in footnote 2)
	missing paren in the form (LAMBDA (X Y --)

Page 16.10
	the number for footnote 25 (in the text) is out of place

page 18.34 -- third new line
	"dicovers" should be "discovers"

page 22.20 -- first new line
	"assistnat" should be "assistant"

page 23.32 -- sixth new line
	"create" should be "creating"


Bill
18-DEC-78 15:51:46-PST,498;000000000000
Date: 18 Dec 1978 3:51 pm (Monday)
From: Masinter
to: lisp

Date: 14 Dec 1978 0855-EST
Sender: LEWIS at BBN-TENEXD
Subject: FILES
From: LEWIS at BBN-TENEXD
To: TEITELMAN at MAXC2, MASINTER at MAXC2
Cc: YONKE, HARTLEY
Message-ID: <[BBN-TENEXD]14-Dec-78 08:55:52.LEWIS>

New MISC, COMP, and MACROS with .COM's on <newlisp>
A long standing bug in the blklibrary definition of length has been fixed.
Also, a new user function, SELECT, has been added.  Documentation to follow.

Daryle
18-DEC-78 15:52:52-PST,2086;000000000000
Date: 18 Dec 1978 3:52 pm (Monday)
From: Masinter
TO: LISP

Date: 14 Dec 1978 0858-EST
Sender: LEWIS at BBN-TENEXD
Subject: SELECT
From: LEWIS at BBN-TENEXD
To: teitelman at MAXC2, masinter at MAXC2
Cc: hartley, yonke
Message-ID: <[BBN-TENEXD]14-Dec-78 08:58:44.LEWIS>

[Below is the documentation for a new system function SELECT.  The
documentation is written assuming it follows the description of SELECTQ
in the manual (Section 5).  Subscripts are enclosed in <> (e.g.,
"e sub i" is written as e<i>).]

=============================================================

select[x;clause<1>;clause<2>;...;clause<n>;default]

        -  SELECT is similiar to SELECTQ except that the selection
           key (s<i>) is evaluated before the EQ test.

           That is, if s<i> is an atom, the value of x is tested to
           see if it is EQ to the value of s<i>.  If so, the
           expressions e<1i> ...  e<ki> are evaluated in sequence,
           and the value of the SELECT is the value of the last
           expression evaluated, i.e., e<ki>.

           If s<i> is a list, the value of x is compared with the
           value of each element of s<i>, and if x is EQ to any one
           of them, then e<1i> to e<ki> are evaluated in turn as
           above.  Note that if is s<i> is (FOO FIE) the test is
                (OR (EQ x FOO) (EQ x FIE)).
           To get the test
                (EQ x (FOO FIE)),
           s<i> should be ((FOO FIE)).

           If clause<i> is not selected in one of the two ways
           described, clause<i>+1 is tested, etc., until all the
           clause's have been tested.  If none is selected, the value
           of the SELECT is the value of default.  default must be
           present.

           SELECT compiles open, and is therefore very fast; however,
           it will not work if the value of x is a large integer or
           floating point number, since SELECT uses EQ for all
           comparisons.
------------------------------------------------------------

18-DEC-78 15:53:39-PST,700;000000000000
Date: 18 Dec 1978 3:53 pm (Monday)
From: Masinter
to: lisp

Date: 14 Dec 1978 1326-EST
Sender: LEWIS at BBN-TENEXD
Subject: FILES
From: LEWIS at BBN-TENEXD
To: TEITELMAN at MAXC2, MASINTER at MAXC2
Cc: HARTLEY, YONKE
Message-ID: <[BBN-TENEXD]14-Dec-78 13:26:08.LEWIS>

New mac & .com on <newlisp>.
The the FLG arg of USERNAME has now been expanded so that
if FLG is not a string pointer and non-nil, then
username will return it's result as an atom.

the FLG arg has also been added to HOSTNAME.

for macscratchstring hackers: The new fn ATMCONC0 is like STRCONC0 but
returns an atom instead of a string.

Daryle
------------------------------------------------------------

18-DEC-78 16:02:26-PST,633;000000000000
Date: 18 Dec 1978 4:02 pm (Monday)
From: Masinter
To: lisp

The manual does not mention anything about the "2CHAR" argument of
settermchars, or anything about control-N being a terminal character; however, it
seems that the 'standard system' comes with control-N as the 2CHAR on
editcharacters, confusing anyone who attempts to make control-N an interrupt
during greet.

I also left out of the documentation for the new PMAP stuff that if you mappage
with "file"=777777Q and "page"=-1 that you will get a blank page. If you use the
same "file" later (i.e. the EQ large integer) then you will get the same page.

Larry
20-DEC-78 10:05:30-PST,1231;000000000001
Date: 20 Dec 1978 10:05 am (Wednesday)
From: bobrow
Subject: Change to the VM SPec
To: LISP

On page p 95, the top, add an alternatibve to "Save sufficient information ..."
as
"or, if the implementation allows immediate interrupts, call
INTERRUPT[NIL;NIL;2]
which will print 
Interrupted below <name of function interrupted>
and cause a break with BRKEXP = NIL.  Any value returned from the break will
be ignored, an d the computation will proceed."

2)  CLEARBUF takes two arguments in the manual and only one in the VM ????
Is this a change to the VM.

3) GETINTERRUPT[char] allows char to be only character codes, class names, T
or NIL as arguments.  If char =T returns a list of all current interrupts.  If
char=NIL returns a list of just user interrupts.  If char=<system interrupt class>
returns the charactercode which is enabled for that interrup (or NIL if none);  if
char=charactercode returns the class of interrupt for that character  code.

4)SETTINTERRUPT[char;class]
	if char is a system class name
		then disables that interrupt class, returns 
	else 
	 if class is a system class name
	  then disables the previous character for that class
	 enables char with interrupt class class

21-DEC-78 14:15:13-PST,652;000000000000
Date: 21 Dec 1978 2:15 pm (Thursday)
From: Masinter
Subject: Re: MAX, MIN, IMAX, IMIN, FMAX, FMIN
In-reply-to: Your message of 21 DEC 1978 1407-PST.
To: KAPLAN, LISP
cc: TEITELMAN, MASINTER

The documentation in the manual is wrong: it should say that MAX() and
IMAX() return MIN.INTEGER, while MIN() and IMIN() return MAX.INTEGER.

These functions should obey the standard property that

(fn arg) = (fn arg (fn)), e.g.

(MAX A) = A = (MAX A (MAX)) = (MAX A MIN.INTEGER)

{this property is shared by all of the 'spread' arithmetic functions, e.g. PLUS,
TIMES, LOGOR, LOGAND, etc).

FMAX and FMIN do need to be implemented.

Larry
21-DEC-78 15:24:50-PST,372;000000000000
Date: 21 DEC 1978 1524-PST
From: KAPLAN
Subject: Re: MAX, MIN, IMAX, IMIN, FMAX, FMIN
To:   Masinter, LISP
cc:   TEITELMAN

In response to the message sent 21 Dec 1978 2:15 pm (Thursday) from Masinter

I was about to send a message saying essentially what Larry said, and for
the same reason.  The implementation is right, the manual is wrong.

--Ron
-------
28-DEC-78 09:20:59-PST,565;000000000001
Date: 28 Dec 1978 0918-PST
Sender: GOLDMAN at USC-ISIE
Subject:  lisp manual typo\error
From: GOLDMAN at USC-ISIE
To: teitelman at PARC
Cc: goldman, lisp at PARC-MAXC2
Message-ID: <[USC-ISIE]28-Dec-78 09:18:39.GOLDMAN>
TOPIC: miscellaneous

 page 9.63  mismatch of formal parameters of esubst (old, new, expr)
             and those used in its description (y, x, z)

 pages 14.74,5  the CONTAIN property of filepkg commands should be CONTENTS

 page 14.75  the formal parameters to the first 3 functions on this page
	     are in the wrong order

 1-JAN-79 22:03:59-PST,1295;000000000001
Date:  1 JAN 1979 2203-PST
From: TEITELMAN
Subject: lisp
To:   lisp

Date: 31 DEC 1978 1348-PST
From: KAPLAN
Subject: For next manual
To:   TEITELMAN

I've been going over my old message files and eliminating things that
are now in the manual.  While doing that, I've noticed a few things
that should be changed for the next manual (perish the thought).  I'll
pass them along as they come up, and you can file them someplace.

p. 14.51  The description of fonprofile seems confused.  Looks like
part of a sentence disappared, and there is also som confusion abou whether
the third element of the list is called FONT or FONT#.  (The goofy sentence
is the last one in the first paagraph).  Also, FONT in the second paragraph
should be underlined.

Finally, a point of clarification:  in my old message, it says that FONT
can also be the name of a previusly defined fontclass, instead of a number.
Is that still true?

p 4.1, footnote 3 at bottom of page.  Mentions PRINTSTRUCTURE instead of
MASTERSCOPE.  (That's Chapter 4, not chapter 14 as in the comment above).

p. 14.9  Seprcase says that the various breaks and
clisp  haracters will be mapped into the SAME character, but it
doesn't say which one.  Is it space?  Does it matter?

--Ron
-------


-------
 4-JAN-79 14:24:23-PST,159;000000000001
Date:  4 JAN 1979 1424-PST
From: TEITELMAN
To:   lisp

OEFP now implemented 0 functio for
determinng if a file is at its end of file pointer.

-------
11-JAN-79 18:42:45-PST,285;000000000000
Date: 11 JAN 1979 1842-PST
From: TEITELMAN
Subject: compile not restoring primary input file
To:   JAMES
cc:   JAMES at USC-ECL, LISP, MASINTER


was not advertised to do such, and nobody has complained
until now - but easyy enough to fix. consider it done

warren
-------
12-JAN-79 10:35:22-PST,335;000000000001
Date: 12 Jan 1979 10:34 am (Friday)
From: Laaser
Subject: bug in new manual
To: teitelman
cc: lisp, Laaser

On page 21.13, the function ADDBUFFER is actually called ADDMAPBUFFER
in the system.  I.e. ADDBUFFER is undefined, but the function
ADDMAPBUFFER exists and does what the documentation says ADDBUFFER
does.

Bill


12-JAN-79 11:42:14-PST,452;000000000000
Date: 12 JAN 1979 1142-PST
From: TEITELMAN
Subject: addbuffer or addmapbuffer?
To:   MASINTER, lisp

Date: 12 Jan 1979 10:34 am (Friday)
From: Laaser
Subject: bug in new manual
To: teitelman
cc: lisp, Laaser

On page 21.13, the function ADDBUFFER is actually called ADDMAPBUFFER
in the system.  I.e. ADDBUFFER is undefined, but the function
ADDMAPBUFFER exists and does what the documentation says ADDBUFFER
does.

Bill



-------
15-JAN-79 15:11:14-PST,430;000000000000
Date: 15 JAN 1979 1511-PST
From: MASINTER
Subject: my bug in your file?
To:   Lewis at BBND
cc:   masinter, lisp

There was a glitch in SUBSYS where it wasn't checking USERFORKS when given
a FIXP fork handle. This led to problems where

EXEC
(KFORK T)
(SUBSYS foonly)
EXEC

would get foonly rather than a new exec.

I think it was my fault. In any case, I fixed it: new MAC on [maxc2]<newlisp>.

Larry
-------
15-JAN-79 23:02:44-PST,715;000000000000
Date: 15 JAN 1979 2302-PST
From: TEITELMAN
Subject: movd/copyflg
To:   KAPLAN, GOLDMAN at ISIE
cc:   MASINTER, LISP


i took a crack at writing supermovd. is too hard. to do
it "right," in the caseof a broken function etc,
one also wants to have the names changed inside,
e.g. if i breakon foo, and then movd foo to fie,
when i run fie, i want it to say fie broken, not foo broken.
siilarly, if i have done break((print in foo)) then movd
foo fie.  it gts very complicated. plus there is the
issue of making it undoable in /movd which means duplicating
all the code with / functons.  what i will do is
make movd take a virginfn in the case of copyflg=T.
ttats as far as ill go.

warren
-------
16-JAN-79 09:00:55-PST,252;000000000000
Date: 16 JAN 1979 0900-PST
From: KAPLAN
Subject: Re: movd/copyflg
To:   TEITELMAN, GOLDMAN at ISIE
cc:   MASINTER, LISP

In response to the message sent 15 JAN 1979 2302-PST from TEITELMAN

I think that is a good solution.  

--Ron
-------
16-JAN-79 11:42:36-PST,462;000000000000
Date: 16 JAN 1979 1142-PST
From: TEITELMAN
Subject: INFILECOMS?
To:   MASINTER, lisp

Date: 16 Jan 1979 0818-PST
From: Wilber at SRI-KL (Mike Wilber)
Subject: infilecoms?
To:   TEITELMAN at PARC-MAXC2

hi warren -- i guess that now that the manual's off your back, it's kind
of late for comments like this, but it may confuse other users as it
confused me that the second and third arguments to infilecoms? are
permuted -- mike
-------

-------
18-JAN-79 23:21:00-PST,270;000000000001
Date: 18 JAN 1979 2320-PST
From: TEITELMAN
Subject: scratchlist
To:   LISP

Date: 18 JAN 1979 2234-PST
From: KAPLAN
Subject: The manual doesn't say where SCRATCHLIST is to be found
To:   TEITELMAN

keep that in mind for the next revision.
-------

-------
22-JAN-79 23:12:11-PST,575;000000000000
Date: 22 JAN 1979 2312-PST
From: TEITELMAN
Subject: tightgc
To:   lisp

Date: 17 Jan 1979 1118-EST
Sender: LEWIS at BBN-TENEXD
Subject: TIGHTGC
From: LEWIS at BBN-TENEXD
To: teitelman at MAXC2, masinter at MAXC2, hartley, yonke, vittal
Message-ID: <[BBN-TENEXD]17-Jan-79 11:18:07.LEWIS>

TIGHTGC[FLG]

If FLG is non-nil, the garbage collector will never allocate pages for
any datatype except the one currently being collected.
If FLG is nil, GC will work as it currently does.
TIGHTGC returns it's previous setting.  The initial setting is NIL.

-------
25-JAN-79 10:52:04-PST,538;000000000000
Date: 25 JAN 1979 1052-PST
From: BOBROW
Subject: DWIM(C)  interacts with DWIM command
To:   TEITELMAN
cc:   LISP, MASINTER

Trying to invoke the function DWIM(C) at the top level caused me 
considerable grief because it just gave me an error message
"Unable to figure out what you meant in"
last history event

Larry finally helped me track it down to the interpretation of
DWIm as the LISPX command.  This is not documented in the manual
and causes some confusion if people want to change the DWIM setting.
danny
-------
28-JAN-79 18:15:10-PST,280;000000000001
Date: 28 JAN 1979 1815-PST
From: TEITELMAN
Subject: lisp
To:   LISP

Date: 28 JAN 1979 1236-PST
From: KAPLAN
Subject: Note for the next manual
To:   TEITELMAN

If you wanted to put a note in creditting me with PRINTOUT, I wouldn't
object.

--Ron
-------

-------
 5-FEB-79 12:15:12-PST,140;000000000001
Date:  5 FEB 1979 1215-PST
From: TEITELMAN
To:   lisp
cc:   manual

p. 9.61 talks about newfile? rather than markaschangd.

-------
 7-FEB-79 22:39:21-PST,116;000000000001
Date:  7 FEB 1979 2239-PST
From: TEITELMAN
To:   LISP

default for spellfile now is fixspelldefault

-------
 7-FEB-79 22:39:56-PST,264;000000000001
Date:  7 FEB 1979 2239-PST
From: TEITELMAN
Subject: translation of iterative statements
To:   goldman at ISIE
cc:   lisp


ok, if FOO is not defined and has a macro,
will translate to (FUNCTION (LAMBDA (X) (FOO X]

rather than (FUNCTION FOO)

-------
 7-FEB-79 23:03:38-PST,380;000000000001
Date:  7 FEB 1979 2303-PST
From: TEITELMAN
To:   LISP, BOBROW

setreadtable settermtabe now undoable.

(hapend to me while checking out your problem.
should be the case that if you type in etreadtable
or settermtabl eyou can undo it. you can undo
most other stuff like control, echomode etc.)

(will take effect for you when you compile undo the next time)

-------
 8-FEB-79 11:37:39-PST,499;000000000001
Date:  8 FEB 1979 1137-PST
From: TEITELMAN
Subject: manual
To:   lisp

Date:  8 FEB 1979 1039-PST
From: KAPLAN
Subject: Manual glitch
To:   TEITELMAN

In the last line of Section 23.5, it points to 23.17 as the place to
find out about clisp brackets.  In fact, the information is in 23.18.

Also, note for the next revision that a description of user
changewords should be included.  We punted on it this time cause we couldn't
agree on the interface.

--Ron
-------


-------
 8-FEB-79 14:12:42-PST,279;000000000001
Date:  8 FEB 1979 1412-PST
From: BOBROW
Subject: Documentation of CHOOZ
To:   TEITELMAN
cc:   LISP

In the manual it lists the order of the arguments to CHOOZ  on page 17.16
as xword, splst, rel where it really is (as shown inthe index) xword,rel,splst

danny
-------
 9-FEB-79 11:47:42-PST,569;000000000001
Date:  9 FEB 1979 1147-PST
From: TEITELMAN
Subject: compiler and spread macros
To:   lisp, wilber at SRI-KL

Date: 9 Feb 1979 1147-EST
Sender: LEWIS at BBN-TENEXD
Subject: Re: bug with compiler macros
From: LEWIS at BBN-TENEXD
To: TEITELMAN at PARC-MAXC2
Cc: masinter at PARC-MAXC2, lewis, hartley, 
Cc: DEUTSCH at PARC-MAXC2
Message-ID: <[BBN-TENEXD] 9-Feb-79 11:47:26.LEWIS>
In-Reply-To: Your message of  7 FEB 1979 1608-PST

New COMP and .com on <newlisp>.  Spread macros will now give a
warning message if given too many args.

Daryle

-------
19-FEB-79 01:32:00-PST,988;000000000001
Date: 19 FEB 1979 0131-PST
From: TEITELMAN
Subject: baktrace
To:   bobrow
cc:   lisp


after thining abut it some, this is whati decided to do -
the skipfn argument to baktrace is now SKIPFNS, i.e.
a list of functions any of which indicate to skip.
yyour solution in the alto i think is siply
either to advise baktrace to (SETQ SKIPFNS (CONS 'DUMMYFRAMEP SKIPFNS))
or else to change the defiition of BREAKMACROS
so that the corespndingcalls to BT BTV etc.
have (CONS 'DUMMYFRAMEP (BREAKREAD 'LINE)) where
they now have (BREAKREAD 'LINE).
the former has the avantage that it can be easily
overriden by unadvising, the latter in that
it does not require advising.  i would suggest the
latter, i.e. rather than have your own
baktracelst (our original discussion) you have your own
versions of defiition for BT, BTV, etc. on
breakmacros.  is this  acceptabble?

warren

i have done some work on the initialization of variabes
but have not completed it.

-------
20-FEB-79 17:32:37-PST,492;000000000001
Date: 20 FEB 1979 1732-PST
From: HTHOMPSON
Subject: Redeclaration of datatypes
To:   Bobrow, Teitelman, Masinter
cc:   LISP

Be informed that as a result of canging to having datatype
NAMES incorporated in field specifications on the Dorado as opposed to
datatype NUMBERS as on the 10, old specs will apply to new
instances after redeclaration on the dorado, which causes an error
on the 10.  This is sufficiently obscure that I don't think
it's a serious problem.
  HT
-------
23-FEB-79 13:46:39-PST,284;000000000001
Date: 23 Feb 1979 1:45 pm (Friday)
From: Masinter
Subject: Re: The function NEEDUNSAVE has disappeared
In-reply-to: Your message of 22 FEB 1979 0834-PST.
To: KAPLAN
cc: MASINTER, LISP

The function is now called MSNEEDUNSAVE. It should be documented in next
manual.

Larry
24-FEB-79 17:09:35-PST,268;000000000001
Date: 24 FEB 1979 1709-PST
From: MASINTER
Subject: DIRECTORY
To:   Teitelman
cc:   Lisp, Masinter

The DIRECTORY function will now accept specifications
with * and - in them, as advertised in the manual.

(new UTILITY & .COM on <NEWLISP>).

Larry
-------
24-FEB-79 17:34:03-PST,597;000000000001
Date: 24 FEB 1979 1734-PST
From: MASINTER
Subject: RECORD
To:   Teitelman, Lisp, Kaplan, Bobrow
cc:   Masinter

New RECORD & .COM on <NEWLISP>. Several fixes:

I split up RECORDECL1 into several pieces, hopefully fixing
the problem  with FRAME SIZE TOO BIG on the Alto. 
This involved some reorganization of the code. Danny: would
you please check to see if the problem is fixed?

I declared RECORDWORDS (Warren -- did you delete that file
MASINTER.TXT? I didn't find it).

Record declarations can contain a form (DECL ...) in their
tail which will be ignored.

Larry
-------
26-FEB-79 18:41:59-PST,138;000000000001
Date: 26 FEB 1979 1841-PST
From: TEITELMAN
To:   LISP

manual should say thatvirtual machine is done, not in preparation.

-------
26-FEB-79 20:54:42-PST,326;000000000001
Date: 26 FEB 1979 2054-PST
From: TEITELMAN
Subject: change to spellfile findfile
To:   MASINTER, LISP, YONKE at BBND, VITTAL at BBND, KAPLAN


now take an  xtra optional argument, DIRLST, which
if specifies is used in place of DIRECTORIES.
this to facilitate loading lispusers packages. morelater.

warren
-------
26-FEB-79 21:39:18-PST,1297;000000000000
Date: 26 FEB 1979 2139-PST
From: TEITELMAN
To:   LISP


i dont have any objections with marty's suggestion and have
made the necessary changes to the system to accomodate them.
authors of lispusers packages should make the changes
they need to. here is what i have done:

(1) added argument DIRLST to FINDFILE and SPELLFILE

(2) initialized LISPUSERSDIRECTORIES to LISPUSERS LISP).

you can replace the LOAD? calls in
the various lispusers files to
(LOAD? (FINDFILE file T LISPUSERSDIRECTORIES) LDFLG)
and individual sites can reset LISPUSERSDIRECTORIES

as for changin the FILES file package command, i dont
even know whatit does. (it is not in the lisp manual).

note that in the case thatthe ue expllcitly
calls load himself, and has a file by the same
name on the connected directory,
he will get that file. however i agree 
that in this case the user would be more reasonably be expected
to be aware of possible name conflicts than when
the file in question loads some other files.)
thus if the site resets lispuserdirectories, it should
also make sure thatthe value of DIRECTORIES
is consistent. i.e. putting lispusers files
on directory FOO and adding FOO to LISPUSERSDIRECTORIES
is not sufficient, should also add FOO to DIRECTORIES.

warren

-------
26-FEB-79 23:39:49-PST,1606;000000000000
Date: 26 Feb 1979 11:38 pm (Monday)
From: Masinter
to: lisp

------------------------------------------------------------
Date: 26 FEB 1979 2138-PST
From: TEITELMAN
Subject: loading files from lispuers directories
To:   MASINTER, KAPLAN, KAY, YONKE at BBND, VITTAL at BBND,
To:   LEWIS at BBND


i dont have any objections with marty's suggestion and have
made the necessary changes to the system to accomodate them.
authors of lispusers packages should make the changes
they need to. here is what i have done:

(1) added argument DIRLST to FINDFILE and SPELLFILE

(2) initialized LISPUSERSDIRECTORIES to LISPUSERS LISP).

you can replace the LOAD? calls in
the various lispusers files to
(LOAD? (FINDFILE file T LISPUSERSDIRECTORIES) LDFLG)
and individual sites can reset LISPUSERSDIRECTORIES

as for changin the FILES file package command, i dont
even know whatit does. (it is not in the lisp manual).

note that in the case thatthe ue expllcitly
calls load himself, and has a file by the same
name on the connected directory,
he will get that file. however i agree 
that in this case the user would be more reasonably be expected
to be aware of possible name conflicts than when
the file in question loads some other files.)
thus if the site resets lispuserdirectories, it should
also make sure thatthe value of DIRECTORIES
is consistent. i.e. putting lispusers files
on directory FOO and adding FOO to LISPUSERSDIRECTORIES
is not sufficient, should also add FOO to DIRECTORIES.

warren
-------
------------------------------------------------------------

27-FEB-79 19:48:52-PST,427;000000000001
Date: 27 FEB 1979 1948-PST
From: TEITELMAN
Subject: addtovar, appendtovar
To:   LEWIS at BBND
cc:   MASINTER, LISP


new versio of misc and misc.com on newlisp.
when given a null list, e.g. (ADDVARS (FOO)),
and the value of the idicated variable is
NOBIND, ADDVARS initialies it to NIL (same as before).
however if FOO is not NOBIND, ADDVARS does nothing.
(ADDVARS (FOO . lst)) works as before.

warren
-------
11-MAR-79 00:06:35-PST,758;000000000001
Date: 11 Mar 1979 12:03 am (Sunday)
From: Masinter
To: LISP

------------------------------------------------------------
Date: 9 Mar 1979 2031-PST
From: Elaine Kant <EK at SU-AI>
Subject: HELP! NEW INTERLISP CHANGES   
To:   MASINTER at PARC-MAXC 

Apparently NEWFILE2 has been renamed to INFILECOMS?.  That wasn't too
hard
to figure out.  But the arguments are listed as [name;coms;type;-].  I assume
the ;- is non-user type arguments.  But the coms and type arguments seem
to be reversed, at least according to ?=.  It seems to also work if I just
assume that there was a bug in the manual.  I hope I don't have too many
more such surprises in store...
Cheers,
Elaine


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

16-MAR-79 21:39:03-PST,319;000000000001
Date: 16 MAR 1979 2139-PST
From: TEITELMAN
Subject: evala
To:   LISP


the statement that evala simulates the alist in lisp
should be amended or clarified to indicate that
later bindings take precedence over earlier(rater
than other way around). i.e.
evala(foo ((foo . a) (foo . b))  is B

warren
-------
17-MAR-79 02:07:20-PST,671;000000000001
Date: 17 MAR 1979 0207-PST
From: TEITELMAN
Subject: dwimequivlst
To:   SHEIL
cc:   kaplan


undocumented, experimental feature. i am sure you will
find places where it is not checked and should be.
its hard to look at every EQ test.  in any case,
i will fix these on a one by one basis, i.e. i am
not going to invst a lot of time now trying to anticipate
all problems.

to make something dwimify like selectq, add (FOO . SELECTQ)
entry. this should obviate the need for any info properties,
but again, i may have missed some spots.

i have not done anything with clispify with respect
to dwimequivlst.

this is in latest byte.sav

warren
-------
 4-APR-79 23:07:16-PST,1083;000000000001
Date:  4 APR 1979 2307-PST
From: TEITELMAN
Subject: manual
To:   lisp

Mail-from: Arpanet host MIT-AI rcvd at 4-APR-79 1855-PST
Date: 4 APR 1979 2154-EST
From: MEEHAN at MIT-AI (James R. Meehan)
To: teitelman at PARC-MAXC

A question, a correction, and a suggestion about the new INTERLISP tome.
1. Am I correct in assuming that you are the original author of the 
chapter on the editor? The bulk of the text seems not to have changed
a great deal since the UCI LISP Manual came out in '73; I'm revising
that somewhat smaller tome and would certainly like to give credit
where credit is due.
2. In section 9.1, page 9.3, there's an error in the paragraph
beginning "In our editing session..." The phrase "add Z after CAR"
should read "add X after CAR". [Not exactly earthshaking, I know]
3. In section 9.2, page 9.9, the description of (B e1 ... em)
says it does an UP and then a -1. Better to say it does an UP and
then a (-1 e1 ... 1m), since -1 means something else.

(I'm at UCI. This is just a mailbox account I use.)
Thanks - Jim Meehan



-------
27-APR-79 10:54:41-PST,431;000000000001
Date: 27 APR 1979 1054-PST
From: TEITELMAN
Subject: manual
To:   lisp

Mail-from: Arpanet host USC-ECL rcvd at 26-APR-79 1433-PST
Date: 26 APR 1979 1423-PST
From: BILOFSKY at USC-ECL
Subject: LISP Manual Typo
To:   Teitelman at PARC

For your typo folder, the references on page 14.59 of the October 1978
edition of the Interlisp Manual, in items 24 and 25, should refer to
page 14.22, not 14.59.
-------

-------
 9-MAY-79 11:55:41-PDT,1306;000000000001
Date:  9 MAY 1979 1155-PDT
From: TEITELMAN
Subject: ( Forwarded Mail )
To:   lisp

Mail-from: Arpanet host SU-AI rcvd at 7-MAY-79 1659-PDT
Date: 7 May 1979 1657-PDT
From: Dave Barstow <DRB at SU-AI>
Subject: INTERLISP bugs
To:   teitelman at PARC-MAXC, masinter at PARC-MAXC
CC:   DRB at SU-AI  

A couple of problems that we've noticed with the INTERLISP from 22-Jan-79:

(1) page 14.74 of the manual gives CONTAIN as the name of the property
used with FILEPKGCOM, but that doesn't get accepted.  I looked at
the source code, and it seems that CONTENTS and IN? are acceptable.

(2) much more vexing is that the filepackage doesn't work very well
with subdirectories on TOPS-20.  for example, if I'm logged in as
<BARSTOW.LISP>, and load a file called FOO, this gets recorded on
FILELST as FOO.LISP>FOO, that is, the file name
is put in the position of the first part of the subdirectory name.
I looked around a little bit to see if I could fix it somehow, or
at least put in a patch that would catch it when it occurs,
but with no success.  this problem is actually quite
consequential, since some places (e.g. Yale), like to have people's
directories as subdirectories of projects.  Ditto for some
people at Schlumberger.

Any suggestions?

Dave Barstow




-------
11-MAY-79 02:09:02-PDT,10677;000000000000
Date: 11 MAY 1979 0209-PDT
From: TEITELMAN
Subject: username,usernumber,directoryname,directorynumber
To:   lisp

Mail-from: Arpanet host BBN-TENEXD rcvd at 10-MAY-79 0813-PDT
Date: 10 May 1979 1106-EDT
Sender: LEWIS at BBN-TENEXD
Subject: y
Subject: [YONKE at BBN-TENEXD: directory names]
From: LEWIS at BBN-TENEXD
To: teitelman at MAXC2
Message-ID: <[BBN-TENEXD]10-May-79 11:06:01.LEWIS>

Warren,
here is the description of the direcotry fns.

Daryle
	
Begin forwarded message
Mail from BBN-TENEXD rcvd at 12-Feb-79 1344-EST
Date: 12 Feb 1979 1344-EST
From: YONKE at BBN-TENEXD
To: Teitelman at MAXC2, Masinter at MAXC2, Kaplan at MAXC2, lewis, 
    hartley
Cc: vittal
Subject: directory names
Message-ID: <[BBN-TENEXD]12-Feb-79 13:44:05.YONKE>
Sender: YONKE at BBN-TENEXD
[Text]: 
Note by YONKE on 12 Feb 1979 1324-EST 

Below is a proposal for changing the way directory names and numbers are
talked about in interlisp.  This was brought on by a major change in
TOPS20 in release 3.  Daryle has volunteered to implement the functions
maintaining TENEX/TOPS20 compatibility.  Comments/uproars/suggestions
are heartily welcome.  /mdy

============================================================

Release 3 of TOPS20 contains a major change in the way one "talks" about
directories.  First, what is thought of on TENEX as a USERNAME/NUMBER
has been split into two catagories:

        1.  A USERNAME is something you login or attach to (and that
            is all!).  A USERNUMBER isn't good for much (except when
            used in conjunction with certain system tables) and can
            only be guarenteed to remain consistent with a
            particular USERNAME during a system's up-time (i.e.,
            they may change when a system is brought up).  A
            USERNAME has the same format (essentially) as a TENEX
            USERNAME (i.e., a string of characters not enclosed in
            <>s).

        2.  There are two new entities called DIRECTORYNAME and
            DIRECTORYNUMBER.  These are essentially what one thinks
            of as USERNAME/NUMBER on TENEX and are what one uses to
            talk about directories and files.  A DIRECTORYNAME has
            the format "structure:<directoryname>" where structure:
            can be thought of as a "device" in TENEX mode, but is a
            way of partitioning the disk (so there can be mountable
            structures that don't clutter up the disk space most of
            the time).  When you ask for a DIRECTORYNAME from TOPS20
            you'll always get back one of these -- including the
            structure:  and <>s.  A DIRECTORYNUMBER should be
            thought of as very temporary (akin to a JFN) and remains
            consistent with a particular DIRECTORYNAME only for the
            lifetime of the program that got the DIRECTORYNUMBER and
            only for that program (i.e., you can't pass
            DIRECTORYNUMBERs between programs).
 
            Both DIRECTORYNUMBER and USERNUMBER are full 36 bit
            quantites and are never the same number.

Obviously, this change has a major impact on a single TENEX/TOPS20
INTERLISP.  (At a minimum, almost all calls to the current function
USERNUMBER should add T as the second parameter so that on TOPS20 you'll
get the more useful DIRECTORYNUMBER back -- of course this implies a box
on TOPS20 since you'll get back a full 36 bit number.)  I'd like to
propose some new functions (and change the use of some old functions) to
"hide" the differences between between the two systems.  To help keep
things straight in this discussion, whenever I refer to a current system
function (and its current use) I'll precede it by the string "old"
(e.g., the current USERNUMBER will appear as oldUSERNUMBER in the text).

Essentially, the proposal is rename the functions oldUSERNAME and
oldUSERNUMBER to DIRECTORYNAME and DIRECTORYNUMBER respectively (details
of all new functions will appear below).  These are the functions to use
when dealing with the file system.  The functions USERNAME and
USERNUMBER should then only be used to identify a user (not a
directory).  To alleviate calls to DIRECTORYNUMBER (i.e., oldUSERNUMBER)
and USERNUMBER which become expensive on TOPS20 there should be two new
functions:  DIRECTORYNAMEP and USERNAMEP which determine if what they
are given legitimate directory or user names -- I believe this was the
major use of oldUSERNUMBER used in conjunction with oldUSERNAME.  Also,
DIRECTORYNAME and USERNAME have been expanded to take directory and user
names (with escapes) as opposed to the oldUSERNAME which only took T,
NIL, or a number.  And finally, there should be a new system function
CNDIR which should be used for connecting to another directory inside of
Lisp (connecting to a directory on TOPS20 is (will be) radically
different implementation wise).

The documentation for the proposed functions follows.  The parameter
names DIRNAME and USERNAME can either be a litatom or string.


DIRECTORYNAME[DIRNAME;STRPTR]

        -  Returns a "full directory name" for DIRNAME.  If
           DIRNAME=NIL then return the login directory.  If DIRNAME=T
           then return the connected directory.  If DIRNAME is a
           string or litatom with an $ (escape) on the end then name
           completion will be attempted; if unsuccessful NIL will be
           returned.  DIRNAME can also be a number, in which case if
           DIRNAME is a valid directory number return its
           corresponding directory name.  Normally the directory name
           is returned as a string.  If STRPTR is a string pointer
           then it is smashed with the new string pointer.  If
           STRPTR=T then the directory name is returned as an atom.

DIRECTORYNAMEP[DIRNAME]

        -  Returns T if DIRNAME is a legitimate directory name.  If
           DIRNAME ends with an $ (escape) then name completion is
           attempted and T returned if successful, otherwise NIL.
           This function is provided for efficency so the
           DIRECTORYNAME string doesn't have to be created.

DIRECTORYNUMBER[DIRNAME]

        -  Returns the directory number for DIRNAME.  DIRNAME may end
           with an $ (escape) in which case name completition is
           attempted.  if DIRNAME=NIL then login directory number is
           returned.  If DIRNAME=T then the connected directory is
           returned.

USERNAME[USERNAME;STRPTR]

        -  Returns a user name for USERNAME.  If USERNAME=NIL then
           return the login user.  If USERNAME is a string or litatom
           with an $ (escape) on the end then name completion will be
           attempted; if unsuccessful NIL will be returned.  USERNAME
           can also be a number, in which case if USERNAME is a user
           number return its user name.  Normally the user name is
           returned as a string.  If STRPTR is a string pointer then
           it is smashed with the new string pointer.  If STRPTR=T
           then the user name is returned as an atom.  Note:
           USERNAME=T is meaningless (by the old interpretation, this
           would mean something like "connected login user") and will
           simply return NIL.

USERNAMEP[USERNAME]

        -  Returns T if USERNAME is a legitimate user name.  If
           USERNAME ends with an $ (escape) then name completion is
           attempted and T returned if successful, otherwise NIL.

USERNUMBER[USERNAME]

        -  Returns the user number for USERNAME.  USERNAME may end
           with an $ (escape) in which case name completition is
           attempted.  if USERNAME=NIL then login user number is
           returned.

CNDIR[DIRNAME;PASSWORD;-]

        -  Tries to connect to DIRNAME and if successful returns a
           full directory name (as an atom) for DIRNAME otherwise it
           returns NIL.  If PASSWORD (a string or litatom) is
           supplied it is used to aid in the connecting process.  The
           third parameter (FLG) is only used on TOPS20 and is used
           to specify different ways to "connect" (more will be said
           about this in another message for those interested).

Interactions with PACKFILENAME, UNPACKFILENAME, and FILENAMEFIELD:

Since structure:  looks exactly like DEVICE, UNPACKFILENAME works fine
as is.  PACKFILENAME on TOPS20 would have to check for a structure being
on the "front" of a directory name.  If it is there and there is no
DEVICE specified then PACKFILENAME works essentially like it does now.
If a device is specified separately and there is one in the directory
name, I propose whichever occurs first be the one used (this is similiar
to the way BODY is used).  I would also like to propose that STRUCTURE
become a synonym for DEVICE.  PACKFILENAME and FILENAMEFIELD would
accept either on both TENEX and TOPS20.  UNPACKFILENAME would return
with either the field being called DEVICE or STRUCTURE based on which
type of system Lisp is running on.

Impact on the system and user code:

In system code all calls to USERNUMBER should be looked at to determine
if it was being used in conjunction with USERNAME to get a legitimate
and complete USERNAME.  If so, these should be consolidated to one call
to DIRECTORYNAME.  (I did a MAPATOMS and found the only compiled
functions which call USERNUMBER are FILEINFOBLOCK, SPELLFILE, and
DIRECTORY.  FILEINFOBLOCK when dealing with changing the author field in
the FDB seems to be the only one which needs the new USERNUMBER.)  All
calls to USERNAME which exist after the previous alteration should just
be renamed to DIRECTORYNAME (again, the only calls to USERNAME are in
the functions FILEINFOBLOCK, GREETBLOCK, SETINITIALS, and WRITEFILE and
non-functions such as AFTERSYSOUTFORMS).  Since the parameters are
compatable, this should be easy.  Some files in LISPUSERS will also
certainly be effected (especially EXEC), but the changes are similiar.

Old user code running on TENEX should notice no difference since
USERNAME and USERNUMBER work the same for them.  They should however be
advised of the new directory functions and to use them instead.  Old
user code running on TOPS20 will have to be modified similiarly to the
system code, but since they were going to have to add the second
parameter to oldUSERNUMBER when they got Release 3 of TOPS20 anyway this
doesn't seem like a burden.

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


-------
15-MAY-79 14:35:57-PDT,8664;000000000001
Mail-from: Arpanet host BBN-TENEXD rcvd at 15-MAY-79 1435-PDT
Date: 15 May 1979 1546-EDT
Sender: LEWIS at BBN-TENEXD
Subject: filefns documentation
From: LEWIS at BBN-TENEXD
To: teitelman at MAXC2
Message-ID: <[BBN-TENEXD]15-May-79 15:46:23.LEWIS>


Release 3 of TOPS20 contains a major change in the way one "talks"
about directories.  First, what is thought of on TENEX as a
USERNAME/NUMBER has been split into two catagories:

  1.  A USERNAME is something you login or attach to (and that is
      all!).  A USERNUMBER isn't good for much (except when used in
      conjunction with certain system tables) and can only be
      guarenteed to remain consistent with a particular USERNAME
      during a system's up-time (i.e.  they may change when a
      system is brought up).  A USERNAME has the same format
      (essentially) as a TENEX USERNAME (i.e., a string of
      characters not enclosed in <>'s).

  2.  There are two new entities called DIRECTORYNAME and
      DIRECTORYNUMBER.  These are essentially what one thinks of as
      USERNAME/NUMBER on TENEX and are what one uses to talk about
      directories and files.  A DIRECTORYNAME has the format
      "STRUCTURE:<DIRECTORYNAME>" where STRUCTURE:  can be thought
      of as a "device" in TENEX mode, but is a way of partitioning
      the disk (so there can be mountable structures that don't
      clutter up the disk space most of the time).  When you ask
      for a DIRECTORYNAME from TOPS20 you'll always get back one of
      these -- including the STRUCTURE and <>'s (e.g.
      PS:<TEITELMAN>).  A DIRECTORYNUMBER should be thought of as
      very temporary (akin to a JFN) and remains consistent with a
      particular DIRECTORYNAME only for the lifetime of the program
      that got the DIRECTORYNUMBER and only for that program (i.e.
      you can't pass DIRECTORYNUMBERs between programs).
 
      Both DIRECTORYNUMBER and USERNUMBER are full 36 bit quantites
      and are never the same number.

Obviously, this change has a major impact on a single TENEX/TOPS20
Interlisp-10.  The following new functions have been added (and
changes to the use of some current functions) to "hide" the
differences between between the two systems.  To help keep things
straight whenever a current system function (and its current use) is
referred to it will be preceded by the string "old" (e.g.  the
current USERNUMBER will appear as oldUSERNUMBER in the text).

Essentially, the change is to is rename the functions oldUSERNAME and
oldUSERNUMBER to DIRECTORYNAME and DIRECTORYNUMBER respectively
(details of all new functions will appear below).  These are the
functions to use when dealing with the file system.  The functions
USERNAME and USERNUMBER should then only be used to identify a user
(not a directory).  To alleviate calls to DIRECTORYNUMBER (i.e.
oldUSERNUMBER) and USERNUMBER which become expensive (because of the
boxing of the number) on TOPS20 there are two new functions:
DIRECTORYNAMEP and USERNAMEP which determine if what they are given
is legitimate directory or user name -- this was the major use of
oldUSERNUMBER used in conjunction with oldUSERNAME.  Also,
DIRECTORYNAME and USERNAME have been expanded to take directory and
user names (with escapes) as opposed to the oldUSERNAME which only
took T, NIL, or a number.  And finally, there is a new system
function CONNECTDIR which should be used for connecting to another
directory inside of Interlisp-10 (connecting to a directory on TOPS20
is radically different implementation wise).

The documentation for the functions follows.  The parameter names
DIRNAME and USERNAME can either be a litatom or string.


DIRECTORYNAME[DIRNAME;STRPTR]

  -  Returns a "full directory name" for DIRNAME.  If DIRNAME=NIL
     then return the login directory.  If DIRNAME=T then return the
     connected directory.  If DIRNAME is a string or litatom with an
     $ (escape) on the end then name completion will be attempted;
     if unsuccessful NIL will be returned.  DIRNAME can also be a
     number, in which case if DIRNAME is a valid directory number
     return its corresponding directory name.  Normally the
     directory name is returned as a string.  If STRPTR is a string
     pointer then it is smashed with the new string pointer.  If
     STRPTR=T then the directory name is returned as an atom.

DIRECTORYNAMEP[DIRNAME]

  -  Returns T if DIRNAME is a legitimate directory name.  If
     DIRNAME ends with an $ (escape) then name completion is
     attempted and T returned if successful, otherwise NIL.  This
     function is provided for efficency so the DIRECTORYNAME string
     doesn't have to be created.  [Footnote:  if DIRNAME=T or NIL
     then DIRECTORYNAMEP will return T since they are valid DIRNAMEs
     to DIRECTORYNAME.]

DIRECTORYNUMBER[DIRNAME]

  -  Returns the directory number for DIRNAME.  DIRNAME may end with
     an $ (escape) in which case name completition is attempted.  if
     DIRNAME=NIL then login directory number is returned.  If
     DIRNAME=T then the connected directory is returned.

USERNAME[USERNAME;STRPTR]

  -  Returns a user name for USERNAME.  If USERNAME=NIL then return
     the login user.  If USERNAME is a string or litatom with an $
     (escape) on the end then name completion will be attempted; if
     unsuccessful NIL will be returned.  USERNAME can also be a
     number, in which case if USERNAME is a user number return its
     user name.  Normally the user name is returned as a string.  If
     STRPTR is a string pointer then it is smashed with the new
     string pointer.  If STRPTR=T then the user name is returned as
     an atom.  [Footnote:  USERNAME=T is meaningless (by the old
     interpretation, this would mean something like "connected login
     user") and will simply return NIL.]

USERNAMEP[USERNAME]

  -  Returns T if USERNAME is a legitimate user name.  If USERNAME
     ends with an $ (escape) then name completion is attempted and T
     returned if successful, otherwise NIL.  [Footnote:  If
     USERNAME=NIL then T is returned.]

USERNUMBER[USERNAME]

  -  Returns the user number for USERNAME.  USERNAME may end with an
     $ (escape) in which case name completition is attempted.  if
     USERNAME=NIL then login user number is returned.

CONNECTDIR[DIRNAME;PASSWORD;-]

  -  Tries to connect to DIRNAME and if successful returns a full
     directory name (as an atom) for DIRNAME otherwise it returns
     NIL.  If PASSWORD (a string or litatom) is supplied it is used
     to aid in the connecting process.
 
     [Footnote:  The third parameter FLG is only used on TOPS20 and
     is used to specify different ways to "connect".  If FLG is the
     atom NIL or CONNECT then the normal "connection" is made.  If
     FLG is the atom T or ACCESS then the normal connection is not
     made but files in that directory will be accessible to you.]

Interactions with PACKFILENAME, UNPACKFILENAME, and FILENAMEFIELD:

Since STRUCTURE looks exactly like DEVICE, UNPACKFILENAME works fine
as is.  PACKFILENAME on TOPS20 would have to check for a structure
being on the "front" of a directory name.  If it is there and there
is no DEVICE specified then PACKFILENAME works essentially like it
does now.  If a device is specified separately and there is one in
the directory name, whichever occurs first is the one used (this is
similiar to the way BODY is used).  STRUCTURE is also a synonym for
DEVICE.  PACKFILENAME and FILENAMEFIELD would accept either on both
TENEX and TOPS20.  UNPACKFILENAME will return with either the field
being called DEVICE or STRUCTURE based on which type of system
Interlisp-10 is running on.

Impact on the system and user code:

In system code all calls to USERNUMBER should be looked at to
determine if it was being used in conjunction with USERNAME to get a
legitimate and complete USERNAME.  If so, these should be
consolidated to one call to DIRECTORYNAME.  All calls to USERNAME
which exist after the previous alteration should just be renamed to
DIRECTORYNAME Since the parameters are compatable, this should be
easy.  Some files in LISPUSERS will also certainly be effected
(especially EXEC), but the changes are similiar.

Old user code running on TENEX should notice no difference since
USERNAME and USERNUMBER work the same for them.  They should however
be advised of the new directory functions and to use them instead.
Old user code running on TOPS20 will have to be modified similiarly
to the system code.
 6-JUN-79 17:33:23-PDT,992;000000000001
Date:  6 JUN 1979 1733-PDT
From: KAPLAN
Subject: New HASH
To:   lisp

A new version of the HASH package is released (on <LISPUSERS> and <NETLISP>).

It provides the following new features:

1.  A new value-type, 2NUMBERS.  The values of this type consist of
a cons cell whose car is a 24-bit number and whose cdr is a 36 bit number.
Such values are returned in a "transient" cons with "transient" numbers (meaning
that they must be copied with CONS and/or IPLUS before another value is
called for).  This type might be used, for example, for storing the starting
and ending byte positions of expressions printed in the print-region.

2.  HASHFILEPROP recognizes two new attributes:

	#ENTRIES - returns the total number of entries in the file.
	ITEMLENGTH - returns the average number of characters per entry.

These values may be given to CREATEHASHFILE to indicate what the
initial allocations should be when creating a new hash-file based on
an old one.

-------
19-JUN-79 22:16:06-PDT,896;000000000001
Date: 19 JUN 1979 2216-PDT
From: TEITELMAN
Subject: SUBSYS -RSCAN

Mail-from: Arpanet host BBN-TENEXD rcvd at 19-JUN-79 2058-PDT
Date: 19 Jun 1979 2344-EDT
Sender: LEWIS at BBN-TENEXD
Subject: something for the bottom of your queue
From: LEWIS at BBN-TENEXD
To: teitelman at PARC-MAXC2
Message-ID: <[BBN-TENEXD]19-Jun-79 23:44:26.LEWIS>


If I have FOO defined as a "comment", I can easily get it to 
prettyprint to the terminal as **Foo** by defining a prettyprintmacro
where the fn rebinds **comment**flg.  But there is no way to
get it to do the same when I give a P command to the editor.
Such a thing might be nice.  eg, the timestamp stuff could be
changed do something like (Edited: 1-27-80 by Teitelman), and then
in the editor it could appear as **timestamp**.
Then there would be no quesiion of what is a timestamp and
what is a real comment.

Daryle

-------
28-JUN-79 10:23:30-PDT,1496;000000000001
Date: 28 JUN 1979 1023-PDT
From: TEITELMAN
Subject: interaction beween concat, pack* etc and defprint
To:   lisp

Mail-from: Arpanet host BBN-TENEXD rcvd at 28-JUN-79 0851-PDT
Date: 28 Jun 1979 1149-EDT
Sender: YONKE at BBN-TENEXD
Subject: defprint
From: YONKE at BBN-TENEXD
To: Goldman at USC-ISIE
Cc: Teitelman at PARC-MAXC2, Lewis, Hartley
Message-ID: <[BBN-TENEXD]28-Jun-79 11:49:02.YONKE>

Neil,

The manual says "Note that DEFPRINT also affects internal calls to
print from PACK, CONCAT, etc...".  This is much too weak a statment.
It should probably say something like "if your DEFPRINT function
calls anything that does internal printing like PACK, CONCAT, etc.
the result is unknown and more than likely you will get garbage
back".

The problem is that the internal printing routines are not recursive
and carry around pointers to internal strings, etc.  If your function
is called while inside a call to an internal printing function (which
is highly likely since it is being called to return someting to
print) these internal pointers get smashed.  Of course, this is not
"perfect", but the expense in cleaning up the internal printing
routines is high and at this time it can't be done.  Daryle didn't
even want it documented in the manual because we knew of these
problems.  You were actually lucky that PACK* didn't do something
funny.

Sorry about this.  Say "hi" to the folks at ISI for me and wave to
the ocean.

Regards,
Martin

-------
29-JUN-79 03:08:13-PDT,1181;000000000000
Date: 29 JUN 1979 0308-PDT
From: TEITELMAN
Subject: lisp{sp}
To:   KAPLAN
cc:   HTHOMPSON, lisp at Thesis, lisp, masinter


ok, here is what i did. i found a way to do it via init.lisp, so
tha in act you can try it out with current lisp.

typing lisp{sp} will cause neither system nor user initialization
to be done. however pregreetforms will be executed.
these are basically noops in the sense that they will get done
again when the system next gets greeted, so no problem, i.e.
they are the same at all sites, so that if you use
the procedure below and ship the result to another site, then
the fact thatpregreetforms have been executed once wont affect anything.

the way you handle the fact thatyou might wish, in your loadup,
to set something that normally is initialized in 
<lisp>init.lisp is to add the expression to POSTGREETFORMS
somewherealong the way. these are expression that
get done AFTER the user is subsequently greted, so for example if
you want to set DIRECTORIES, add it to POSTGREETFORMS.

play around with it with current lisp. i will also be reloading
so that we can make a new abc with the fix to defineq in.

warren
-------
4-JUL-79 12:17:42,261;000000000001
Date:  4 JUL 1979 1217-PDT
From: TEITELMAN
Subject: clipify bug
To:   NEWLISP


fixed bug wherein the expression following an atm
which ended in a ' was mistakenly being clispify, e.g.
FOO_'(PROGN (SETQ --))   the SETQ was being clispified.

-------
 4-JUL-79 12:17:42-PDT,261;000000000001
Date:  4 JUL 1979 1217-PDT
From: TEITELMAN
Subject: clipify bug
To:   NEWLISP


fixed bug wherein the expression following an atm
which ended in a ' was mistakenly being clispify, e.g.
FOO_'(PROGN (SETQ --))   the SETQ was being clispified.

-------
4-JUL-79 13:56:39,593;000000000000
Date:  4 JUL 1979 1356-PDT
From: TEITELMAN
Subject: compiler change
To:   PARC Lisp Users:
cc:   newlisp, yonke at BBND, wilber at SRI-KL,
cc:   goldman at USC-ISIE

ther have been many occasions when, looking at a compiled file,
it wold have been nice to know exactly how it had been compiled,
i.e. bcompl, tcopl, recompile, brecompile, and if the lattter, which
function were involved. i have fixed compile to do this.
the information will appear in the first fillcreated expression
on the compiled file, so you can do an infile and a read, and
find it out.

warren
-------
 4-JUL-79 13:56:39-PDT,593;000000000000
Date:  4 JUL 1979 1356-PDT
From: TEITELMAN
Subject: compiler change
To:   PARC Lisp Users:
cc:   newlisp, yonke at BBND, wilber at SRI-KL,
cc:   goldman at USC-ISIE

ther have been many occasions when, looking at a compiled file,
it wold have been nice to know exactly how it had been compiled,
i.e. bcompl, tcopl, recompile, brecompile, and if the lattter, which
function were involved. i have fixed compile to do this.
the information will appear in the first fillcreated expression
on the compiled file, so you can do an infile and a read, and
find it out.

warren
-------
4-JUL-79 17:07:11,318;000000000000
Date:  4 JUL 1979 1707-PDT
From: TEITELMAN
To:   NEWLISP

fixed a bug relatng to loadfns folllowed by a loadfrom. file was
not getting noticed.

fixed editloadfns - tightened a check so that editor
would not ask you to loadfrom a file that it should
have known did not contain the given function.

-------
 4-JUL-79 17:07:11-PDT,318;000000000000
Date:  4 JUL 1979 1707-PDT
From: TEITELMAN
To:   NEWLISP

fixed a bug relatng to loadfns folllowed by a loadfrom. file was
not getting noticed.

fixed editloadfns - tightened a check so that editor
would not ask you to loadfrom a file that it should
have known did not contain the given function.

-------
 6-JUL-79 13:14:20-PDT,751;000000000001
Date:  6 JUL 1979 1314-PDT
From: TEITELMAN
Subject: ( Forwarded Mail )
To:   LISP

Mail-from: Arpanet host SRI-KL rcvd at 6-JUL-79 1257-PDT
Date:  6 Jul 1979 1247-PDT
From: Wilber at SRI-KL (Mike Wilber)
Subject: manual typos
To:   teitelman at PARC-MAXC2

Date:  6 Jul 1979 1143-PDT
From: Tyson
Subject: Interlisp manual typo
To:   wilber

On pages 23.55,56 the function PUT is used 10 times.  Since PUT is not in the
manual, I presume PUTPROP would be more appropriate.
-------
...also, minhash (footnote on p 10.10) isn't indexed in the section, 
master or function indices...

in case i didn't mention it before, i think the new edition is a 
masterpiece, for which many, many thanks...

cheers -- mike
-------
-------
11-JUL-79 16:51:00-PDT,438;000000000001
Date: 11 JUL 1979 1650-PDT
From: TEITELMAN
Subject: LISP
To:   LISP

Date: 11 JUL 1979 1544-PDT
From: HTHOMPSON
Subject: Error in manual
To:   Gorlin at RAND-UNIX
cc:   Teitelman, Kaplan, Masinter

The listing of arguments in the manual on p 23.36 for RECORDACCESS is
wrong - the correct order is (as given in the index)
recordaccess[field;value;dec;type;newvalue].

Sorry for the confusion.
  HT
-------



-------
17-JUL-79 22:08:41-PDT,286;000000000001
Date: 17 JUL 1979 2208-PDT
From: TEITELMAN
Subject: greeting is now under a resetsave
To:   LISP, YONKE at BBND

permits user to change global settings just
for the duration of the greeting. separate resetlst for
system initialization and user initializaion.

warren
-------
21-JUL-79 15:33:44-PDT,608;000000000001
Date: 21 JUL 1979 1533-PDT
From: TEITELMAN
Subject: recordaccess
To:   lisp

Mail-from: Arpanet host BBN-TENEXD rcvd at 21-JUL-79 1500-PDT
Date: 21 Jul 1979 1753-EDT
Sender: YONKE at BBN-TENEXD
Subject: documentation for RECORDACCESS
From: YONKE at BBN-TENEXD
To: Teitelman at PARC-MAXC2
Message-ID: <[BBN-TENEXD]21-Jul-79 17:53:54.YONKE>

The parameter list for RECORDACCESS (p. 23.36) in the manual
is not in the same order as the real function.  It should read:

	recordaccess[field;value;dec;type;newvalue]

Should be changed whenever a new manual gets generated.

Martin

-------
23-JUL-79 00:05:00-PDT,120;000000000001
Date: 23 JUL 1979 0004-PDT
From: TEITELMAN
Subject: setinitials is not indexed in section 9
To:   LISP


-------
24-JUL-79 12:49:18-PDT,399;000000000001
Date: 24 JUL 1979 1249-PDT
From: KAPLAN
Subject: FILES command
To:   TEITELMAN, MASINTER, LISP

A new version of FILEPKG on <NEWLISP>, with the glitch concerning the
FILES command fixed up.  It now puts out the FINDFILE in an OR, so that
LOAD gets the users original specification if the FINDFILE fails, and thus
that file name is printed out in the file not found error.

--Ron
-------
24-JUL-79 12:56:27-PDT,2221;000000000000
Date: 24 JUL 1979 1256-PDT
From: TEITELMAN
Subject: filepkg changes
To:   lisp

Date: 23 JUL 1979 2327-PDT
From: KAPLAN
Subject: New FILEPKG on <NEWLISP>
To:   TEITELMAN
cc:   MASINTER

I think I fixed the rename of fields bug, but its a little tricky and
we'll just have to see what happens.

I also made a few other small changes:

1.  I added a feature to the FILES command originally requested by
Yonke so that he could more easily specify where lispusers files were to
come from.  THe keyword FROM can be followed by the keyword VALUEOF,
in which case a FINDFILE exprssion gets put out instead of a simple
quote.  E.g.
  (FILES (SYSLOAD FROM VALUEOF LISPUSERSDIRECTORIES) HASH) yields the
expression
  (LOAD? (FINDFILE (QUOTE HASH.COM) T LISPUSERSDIRECTORIES) (QUOTE SYSLOAD))
I think this does what Yoke wanted.  The only glitch is in the case the
file isn't found anywhere, the error message gives NIL not fond
instead of HASH.COM not found (cause the FINDFILE returns NIL).
I guess I could put out a more coplicted prog and test the value, but
this will do for now.

2.  In CHANGECALLERS, i changed the interpretation of DEFAULTRENAMEMETHOD
slightly.  If it is MASTERSCOPE and there is no masterscope data base, then
it is assumed to be EDITCALLERS.  (If the use actually secifies masterscope
(i.e. not by default) then that assumption isn't made).
Also, I made it cause an ERROR (instead of HELP) if the user specifies
an unrecognized method.

3.  I changed EDITDEF so that it does not print a warning that
the definition won't be unsaved if the definition is in fact EQUAL to
the current definition.  That warning is spurious and confusing--it has
been buggin me and Henry in ABC, where DFNFLG is PROP.

4.  I changed CHANGECALLERS in another way:  If the name to be changed
is defined as more than one type (e.g. a FNS and a VARS), then the editor
is called not with an EXAM command to let the user decide
what to do, but with a much more complicated command that interrogtes
the user as to what he wants done.  The responses to the askuser are
Yes, do the replacement, No skip to the next occurrence, and anything else, do
a TTY:.

--Ron
-------

-------
24-JUL-79 13:21:40-PDT,190;000000000001
Date: 24 JUL 1979 1321-PDT
From: KAPLAN
Subject: Manual description of EDITE talks about NEWFILE?, not MARKASCHANGED
To:   TEITELMAN, LISP

SHould be changed in next edition.
-------
 1-AUG-79 09:58:04-PDT,140;000000000001
Date:  1 AUG 1979 0958-PDT
From: KAPLAN
Subject: CALLS(subr) now returns NIL.
To:   TEITELMAN, LISP
cc:   MASINTER, SHEIL


-------
 6-AUG-79 14:19:56-PDT,143;000000000001
Date:  6 AUG 1979 1419-PDT
From: KAPLAN
Subject: ADDBUFFER is really called ADDMAPBUFFER; manual should be changed
To:   LISP


-------
9-AUG-79 00:49:21,260;000000000001
Date:  9 AUG 1979 0049-PDT
From: TEITELMAN

bug in resetsave macro fixed to accomodate differences between
shallow and deep binding system

bug in msanalyze fixed wherein if function had a macro template
and no macro caused an inifnite loop

-------
 9-AUG-79 00:49:21-PDT,260;000000000001
Date:  9 AUG 1979 0049-PDT
From: TEITELMAN

bug in resetsave macro fixed to accomodate differences between
shallow and deep binding system

bug in msanalyze fixed wherein if function had a macro template
and no macro caused an inifnite loop

-------
16-SEP-79 19:45:07-PDT,427;000000000001
Date: 16 SEP 1979 1945-PDT
From: TEITELMAN
Subject: new feature in smartarglist
To:   PARC Lisp Users:
cc:   lisp


before bailing out, will consult (extended) file package
and obtain argument names from there. thus if you have a system
consisting of several files, and are editing one, and are at a
place of a call to a function defined in another file, but not
defined in core, ?= will work correctly.

-------
20-SEP-79 13:51:50-PDT,176;000000000001
Date: 20 SEP 1979 1351-PDT
From: TEITELMAN
Subject: SETINITIALS
To:   KAPLAN
cc:   LISP


was not setting initials or firstname undoably. now fixed.

warren
-------
20-SEP-79 13:55:25-PDT,190;000000000001
Date: 20 SEP 1979 1355-PDT
From: TEITELMAN
Subject: control, echomode
To:   kaplan
cc:   lisp


ok, you convinced me. ill initialize breakresetforms appropriately.

waren
-------
21-SEP-79 13:57:55-PDT,471;000000000001
Date: 21 SEP 1979 1357-PDT
From: KAPLAN
Subject: Manual error
To:   LISP
cc:   TEITELMAN

The manual on p. 14.2 says that INFILEP is the filename if the
file can be opened for input.  This is false.  It merely indicates that
the file exists.  Whether or not you can open it depends on whether you
(or someone else) has it open for output at the time you do the INFILE.

I.e., a non-NIL INFILEP does not mean you won't get a file won't open
error.

-------
24-SEP-79 23:31:34-PDT,1115;000000000001
Date: 24 SEP 1979 2331-PDT
From: TEITELMAN
Subject: new error numbers and interpreter
To:   LEWIS at BBND
cc:   DEUTSCH, LISP, WILLIE-SUE


(1) whenever a u.b.a error occurs the error number will be set
to 44 (error string = UNBOUND ATOM) with culprit the atom.
note thatif dwim corrects the error, no error occurs and error number
is not set. however, if an error is going to occur, whether or
not it will cause a brak, the error number will be set.


(2) whenever an undefined car of form occurs, error number will
be 45 (error string = UNDEFINED CAR OF FORM), and culprit is the form.

(3) whenever an undefined function in aply occurs,
error number 46, culprit is list[fn;args]

(4) whenever user types control-e, error nummer will be 47, errorstring=
CONTROL-E.

the purpose of this is to allow programs to be written in lisp
which can detect what caused an error, and thus be made sufficiently
robust to use as servers.  

willie-sue, you should install these 4 new errors and errorstrings.
you dont have to do anything else since is all aken care f in helpdl.

warren
-------
25-SEP-79 00:32:38-PDT,996;000000000001
Date: 25 SEP 1979 0032-PDT
From: TEITELMAN
Subject: experimental new feeature in spelling corrector
To:   KAPLAN
cc:   LISP


fixspell1 has been modified so that if the value returned fro
askuser is a list, it simply passes this back. (fixspell1 used
to always return T or NIL).
the default keylst used by askuser and dwim have been modified
to allow user to type U for Use and then a value (one value - having
user be able to esentially type in two things meaning a run on correction
was too complicated an interaction with fixspell).

fixspell has  een modified so thatif fixspell1 returns a list,
it treats car of the list as the correct value.

i will be reloadin gsoon. lets try playing with this and
see if it has the desired properties. it was a little harder
to put in that one would think at first because of all the
interactios with runon corrections, synonyms, etc. and the
fact that fixspell can be called in lots of different configuraions.

warren
-------
26-SEP-79 21:33:40-PDT,232;000000000001
Date: 26 SEP 1979 2133-PDT
From: TEITELMAN
Subject: loadcomp?
To:   sheil
cc:   kaplan, burton, fikes, lisp


can now be used "recursively" (it looks up the stack to see 
if it s under another loadcomp).

warren
-------
26-SEP-79 21:59:05-PDT,1340;000000000000
Date: 26 SEP 1979 2159-PDT
From: TEITELMAN
Subject: changes to loadfns-vars
To:   KAPLAN
cc:   LISP


ok - here is what i have done.

when you are doing a loadcomp or loadcomp?, it only
evaluates things in a declare: where EVAL@COMPILE is specified.
if you say DONTEVAL@COMPILE, it does not descend.
if you are doing a loadvars, it evaluaes thngs
in a declare: if you say EVAL@LOAD (or leave it out since
thats the default, but if you say DONTEVAL@LOAD it doesnt).
when doing a loadcop, the tags EVAL@LOAD DONTEVAL@LOAD are totally
ignored. when doing a loadfns/vars  the tags
eval@compile, donteval@compile are ignored. 

note that the expressions are evaluated as well as being put
on donelst and returned.

i think this captures the semantics. the reason
loadfrom used to work was that it simply evaluated the
entire top level (DECLARE:  expression) i.e. never searched
inside it, so the tags hhd the right effect, i.e.
with a DONTEVAL@LOAD, it stopped. with loadfns or loadvars
want to sarch for a specific expression, and so should be
guided in a similar way by the tags.  

i would like for you to ban  n this extensively. i am not
sure tha i covered all cses, or thatsomething else
didnt fall apart. rather than reload, why dont
you load in loadfns.com and test it out
directly.

warren
-------
14-NOV-79 15:46:06-PST,163;000000000001
Date: 14 NOV 1979 1546-PST
From: TEITELMAN
Subject: @ IN EDIT PATTERN
To:   KAPLAN
cc:   LISP


now installed.  shall i reload tonight?

warren
-------
21-NOV-79 00:57:00-PST,1042;000000000000
Date: 21 NOV 1979 0057-PST
From: KAPLAN
Subject: New MASTERSCOPE on <NEWLISP>  - ANALYZEUSERFNS
To:   TEITELMAN, LISP
cc:   MASINTER

I added a hook to the masterscope function analyzer so that the user
could specify his own computations.

After a function has been analyzed, masterscope looks at the variable
ANALYZEUSERFNS.  If it is non-nil, it is assumed to be a list of functions.
Each of them is applied in turn to the function-name, function-definition,
and analysis data list for the function just analyzed.  The function should
return a new data list (or perhaps just the old one if all that is intened
is side-effecting).

This is the hook that is needed to add various user defined relations to
masterscope.  The MSHASH package will be able to store the argument
list of a function so that DESCRIBE won't have to rummage around for it
if the function is not loaded.  Also, DECL will be able to store the
RETURNS declaration for a function so that inter-function declarations
can be checked.

--Ron
-------
21-NOV-79 21:54:56-PST,201;000000000001
Date: 21 NOV 1979 2154-PST
From: TEITELMAN
To:   KAPLAN
cc:   LISP


by the way,  is sufficient to use (& .. FOO) as a pattern, you dont have to
do (*any* FOO (& .. FOO)).


warren
-------
23-NOV-79 22:57:49-PST,886;000000000001
Date: 23 NOV 1979 2257-PST
From: KAPLAN
Subject: DESCRIBELST in masterscope
To:   teitelman
cc:   lisp, masinter

there is also a new masterscope on <NEWLISP>.  I modified the dESCRIBE
command so that the user can specify additional information
that he would like to include in a functions description, other than
the information that is already provided by the system.

DESCRIBELST is a list each of whose elements is a pair conisting of
a string descriptor and a form.  The form is evaluated (it can refer to the
name of the funtion being described by the free variable FN), and if it
returns a non-NIL value, the description string is printed followd by
the items in the value in the standard describe format.

Example:  To include the types used by a function in the describe, the entry
("types:  " (GETRELATION FN '(USE TYPE) T) would suffice.

--Ron
-------
 5-DEC-79 12:36:17-PST,254;000000000001
Date:  5 DEC 1979 1236-PST
From: KAPLAN
Subject: New <NEWLISP>FILEPKG - change to ADDTOFILEKEYLST
To:   TEITELMAN, LISP
cc:   GOLDMAN at USC-ISIE

I made the promptstring and explainstring both include "list" along
with "file".

--Ron
-------
 6-DEC-79 21:07:36-PST,605;000000000001
Date:  6 DEC 1979 2107-PST
From: TEITELMAN
To:   LISP


i fixed errortypelst so thatif a file wont open error occurs
when no version was specified,it will try the next higher
version. this will fix the problem of having a compilatin
going in a higher fork, doing an exec and trying to
compile something and gettting a file wont open error
on bcompl.scratch.
i also fixed bcompl so that it does not ave undo informaton
when it is  ctually compiling (since it is compiling from
the file anyway). this shuld save some space when
compilng laage files with lots of clisp.

warren


-------
12-DEC-79 22:46:33-PST,907;000000000001
Date: 12 DEC 1979 2246-PST
From: TEITELMAN
Subject: new loadfns featre
To:   KAPLAN
cc:   lisp


if VARS is a list and (FNTYP VARS ) is true, i.e. VARS is
a lambda expresson, then instead of clling the editor to
match the paatern, loadfns will invoke that function (aplying
it to two arguments, the first and second elements in
the expression being considered, but you can ignore the argument
if you want).

if
(a) the result returned is NIL, loadfns will restore the file pointer
and do a skread - i.e. you are free to do whatever you want to
with file pointer

(b) resule returned is non-nil but atom, e.g. T, loadfns
will reset file pointer, do a READ, and use that as
the expressin (and then either add it to donelst, evaluate
it etc depending on value of LDFLG)

(c) a list - the result is used as the expression. the file pinter
in this case is not reset.

warren
-------
15-DEC-79 17:24:20-PST,342;000000000001
Date: 15 DEC 1979 1724-PST
From: KAPLAN
Subject: ADDMAPBUFFER
To:   TEITELMAN
cc:   LISP

The manual says that it returns T if successful.  That should be changed to
"non-NIL".  

I had corrected LMMAC to obey the manual's description, but that led to
bug in pmapping.  I have reverted to the earlier definition.

--RON
-------
17-DEC-79 21:43:44-PST,620;000000000001
Date: 17 DEC 1979 2143-PST
From: KAPLAN
Subject: SELECTC - SELECT on constant
To:   LISP
cc:   TEITELMAN

This function lies somewhere between SELECTQ and SELECT (which previously
existed but wasn't documented).  With SELECTC, the selection keys are
evaluated when called from interpreted code, just like SELECT.  Unlike
SELECT, the keys are also evaluated at compile-time to form a SELECTQ.

The form of a selection clause is either 
1.  an atom or list of atoms, whose values are treated as the keys.
2.  a list of lists, the elements of which are forms whose values are treated
as the keys.

-------
17-DEC-79 22:40:30-PST,464;000000000001
Date: 17 DEC 1979 2240-PST
From: TEITELMAN
Subject: compile
To:   LISP, KAPLAN, KAY, BURTON, WILLIE-SUE, HTHOMPSON
cc:   LEWIS at BBND


the first expression in a compiled file will now contain in addition
to an indication whether file was bcompled, tcompled, recompiled,
brecompiled, and if latter, which functions, (this is alredy i system),
an indication of what sysout/makesys, by including its name and
sysoutdate/makesysdate.

warre

-------
17-DEC-79 23:50:59-PST,467;000000000001
Date: 17 DEC 1979 2350-PST
From: KAPLAN
Subject: SELECTC again
To:   lisp

Description is now:

SELECTC is like SELECTQ except that it evaluates the key positions of its
arguments to obtain the actual keys for a selectq-type comparison.

This evaluation is done at compile-time to produce a SELECTQ form--the
keys are in a sense compile time constants.

Note that the argument syntax for SELECTC differs from the
undocumented function SELECT.
-------
14-JAN-80 22:07:41-PST,426;000000000001
Date: 14 JAN 1980 2207-PST
From: TEITELMAN
Subject: NLEFT
To:   LISP
cc:   MASINTER, LEWIS at BBND


(NLEFT L N TAIL) where TAIL is non-NIL and NOT a tail
of L will now generate an error. this was thesouce
of a nasty bug in reset logic. i feel if user specifies
TAIL, means he expects it to be a tail of L. if
he isnt sure, should say (TAILP TAIL L),


new macros with blklibarydef for nleft

warren
-------
21-JAN-80 20:32:13-PST,133;000000000001
Date: 21 JAN 1980 2032-PST
From: TEITELMAN
To:   LISP


existence of (getdummyvar)  for use under
i.s. translation

-------
15-FEB-80 00:15:23-PST,1842;000000000001
Date: 15 FEB 1980 0015-PST
From: TEITELMAN
To:   LISP

getdummyvar



larry reported a serious problem in current loadup which is that any
iteraive statement containing a COLLECT which does not
translate into a mapcar, e.g. a collect with a WHILE or a BIND etc.
does not dwimify correctly.

(1) there is a new loadup which I believe fixes the problem. Hoever,
the fix was not straightforard and it is possible i may hve introduced
a new problem. if anything develops while i am away, you can simply

(2) repair the fix in the current byte.sav by remproving the
I.S.OPR property from fcollect (thereby causing it to translate
using the (SETQ $$VAL (NCONC1 $$VAL body)) translation.

the problem stemmed from fcollect, which is the nly i.s.opr in
the world which both evaluates its argument,
and also defines an i.s.type. the problem is that
it used to be handled by a kluge to take into account the fact that
there wasnt anyay to compute the i.s.type so as to use a dummy
variable, and also compute an expressionwhich bound the
same dummy variable. similar i.s.oprs for inside used
to do something like (SUBST (GENSYM) 'VAR exp) where
exp included the BIND. but in fcollects case, this didnt work
because the BIND and the i.s.type had to be handled separately.

I had fixed this up in general but not handled the fcollect case
correctly.

In case any ofyou wish to use the new faciliy, which is somewhat cleaner,
thre is now a functon called GETDUMMYVAR
which is to be called from inside of an i.s.opr. It first
takes variables from the list ($$TEM1 ... $$TEM6) and then uses
GENSYM. If its argument is T, it ALSO effectively binds the
variable, i.e. puts it in the progvars list. To see how it is used,
look at the i.s.opr def for fcollect, and also for inside, outof etc.

warren




-------
18-MAR-80 07:14:44-PST,449;000000000001
Date: 18 MAR 1980 0714-PST
From: KAPLAN
Subject: New filepkg type property:  WHENUNFILED
To:   TEITELMAN, MASINTER, GOLDMAN at ISIE
cc:   LISP

<NEWLISP>FILEPKG allows for a new filepkg type proprty WHENUNFILED.
Parallel to WHENFILED, its valu is a list of functions that will be applied
to name, type, and file whenever an item named name of type type is
removed from file by the function DELFROMFILES (or DELFROMFILE).

--Ron
-------
18-JUL-80 12:02:37-PDT,1533;000000000000
Date: 18 JUL 1980 1202-PDT
From: KAPLAN
Subject: New FILEPKG on <NEWLISP>
To:   TEITELMAN
cc:   LISP

I changed the way the FILES command works so that it puts out an
expression that interprets the arguments at load-time instead of dump-time.
In particular, this means that the load-time compile.ext will be used, so
that the appropriate choice between COM and DBYTE will be made.

The format of the command is checked at dump-time, by the function MAKEFILESCOMS,
to make sure that there is no striking error.

The expression put out on the file is of the form
(FILESLOAD . arguments to the FILES command), where FILESLOAD is a new
function that interprets the command.

Another change:  The ARRAY command will now report that it contains
variables (as per a request by Larry).

This request raises another issue about the ARRAY command, however:  why have
it at all.  It seems to me that the VARS command should be smart
enough to know that if the user asks for a variable with an array value to
be dumped, he does not want to see #123456 on the file.  The VARS command
itself should be able to convert to what the ARRAY command current does
in case the value is an array.  (Then, for backward compatibility, we could
make ARRAY just be a synonym for VARS, and eventually have it drop from
the documentation.)

This proposed cleanup must be implemeneted in PRETTY (I think in PRETTYVAR1).
If you go along with this, let me know and I will make the appropriate
cleanups in FILEPKG.

--Ron
-------
15-JAN-81 22:36:28-PST,837;000000000001
Date: 15 JAN 1981 2236-PST
From: MASINTER
To:   LISP


Date: 17 Oct 1978 2205-EDT
From: LEWIS at BBN-TENEXD
Subject: set a/c link
To:   bobrow at MAXC2
cc:   YONKE, VITTAL, masinter at MAXC2, TEITELMAN at PARC-MAXC2

Danny,

It is now written and will be in the next lisp.mac (alice currently
has a hold on the file for a bug fix).
I made one change.  The fns take a 3rd arg, FLG.
If FLG=non-nil then NEWFRAME will be released if the change succeeds.
eg, if you want to do the smash and release all the stack pointers,
put still catch things if the smash fails, you could say

(if not (RELSTK (SETALINK FOO FUM T)) then (SMASHLINKERROR FOO FUM))

or some such.

Daryle

p.s. A test case I was using was setalink[foo;fum] followed by
setclink[fum;foo].  How's that for a case of lisp incest?
-------
-------
15-JAN-81 22:37:19-PST,6301;000000000000
Date: 15 JAN 1981 2237-PST
From: MASINTER
To:   LISP

Masterscope now notes which functions use which iterative statementnew features in Masterscope:


operators. The command language allows "AS [A] CLISP WORD" as a 
modifier to USE. Examples:
	. SHOW WHERE ANY USE collect AS A CLISP WORD
	. WHICH CLISP WORDS ARE USED BY MYFN
Valid synonyms: CLISPWORD = I.S.OPR = CLISP WORD
----------------------------------------------------------------------
The USE of record FIELDS has been split into FETCH of those fields
and REPLACE, with USE AS A FIELD the union of those.

E.g.
	. WHO FETCHES FOO
will give the list of functions which do a (fetch FOO --) while
	. WHO REPLACES FOO
will give a list of the functions which do a (replace FOO --).
----------------------------------------------------------------------
the <set>
	LIKE <pattern>
will treat <pattern> as a edit pattern if it has alt-modes in it...e.g.
	. SHOW WHERE FOO CALLS ANY LIKE /$
will print out all of the places where a function whose name begins
with a "/" is called.
---------------------------------------------------------------------
the <set>
	FIELDS OF <records> 
denotes all of the record fields of <records>,  e.g.
	. WHO USES ANY FIELDS OF BRECORD
returns the list of all functions which do a fetch or replace with any of
the field names declared in the record declaration of BRECORD.
	. WHO USES ANY FIELDS OF ANY RECORDS ON ACOMP
gives the functions which use any field of any record on ACOMP.
---------------------------------------------------------------------
Masterscope knows more about blocks declarations:
You can talk about sets of things in blocks declarations. I.e.,
a <set> may also be:
	<blockword> [ON <files>] [OF <functions>]
where <blockword> is one of ENTRIES, LOCALVARS, SPECVARS, LOCALFREEVARS,
GLOBALVARS, BLKFNS, BLKAPPLYFNS. For example:
	ENTRIES ON MASTERSCOPE 
means all of the entries of all of the blocks on the file Masterscope.
	ENTRIES OF MSPARSE 
means the entries of the block which contains MSPARSE (MSPARSE could be
the block name or one of the actual functions).

The words OF and ON in this syntax may be followed by <sets>, e.g.
	ENTRIES OF ANY USING THE FIELD X
For GLOBALVARS, SPECVARS, etc, the "ON" phrase will also
find the ones that are in the fileCOMS, e.g.
	GLOBALVARS ON MASTERSCOPE
means all of the GLOBALVARS of any block plus those dumped with the
GLOBALVARS prettydef command.
---------------------------------------------------------------------
In addition, Masterscope contains a fairly comprehensive checker for
blocks declarations (as well as a few other anomolous conditions).
The command:
	. CHECK <files>
will (a) analyze all of the functions on the file(s) given, if necessary.
(b) read the blocks declaration and check for
  Things not properly declared ENTRIES (e.g. if no one in the block
calls a function, and it isn't an entry (or a BLKAPPLYFN) there is no
way to get to it).
  Variables declared improperly (checks LOCALFREEVAR declarations to make
sure vars are bound above where they are used, for the deep-bound system,
checks SPECVARS to see if they are used below where they are bound, for the
shallow system).
  Variables used freely and not declared (often an error).

Note that Masterscope checks for various problems even in the absence of 
BLOCKS declarations

Suggestions for additional checks are welcome.
---------------------------------------------------------------------
The EDIT command can be followed by a - and a list of edit commands,
for example:
	. EDIT WHERE MYFN CALLS RPLACA - (R RPLACA FRPLACA)
--------------------------------------------------------------------
Note that there are two forms of the EDIT command:
	. EDIT [WHERE] <set> <verbs> <set> [- <edit commands>]
and
	. EDIT <set> [- <edit commands>]
The latter just calls EDITF on each element of <set>. For example:
	. EDIT WHERE ANY CALLS Y
will edit the expressions where Y is called.
	. EDIT ANY CALLING Y
will just call EDITF on the functions that call Y.
----------------------------------------------------------------------
Masterscope allows a command of the form:
	. FOR <variable> <set> <clisptail> 
which will execute the iterative statment:
	(FOR <variable> IN '(elements of <set>)  <clisptail>)
For example:
	. FOR X CALLING Y DO (PRINT X)
will print on separate lines the names of the functions which call Y
	. FOR X ON MYFILE AND BINDING Z DO (UNSAVEDEF X)
will call UNSAVEDEF on the functions on the file MYFILE which bind the
variable Z.
----------------------------------------------------------------------
The command
	. COMPONENTS <set>
will print out a list of the "connected components" of <set> (or everybody
if you don't give a set). The connected components are such that
if functions are in different components then there is no way to get
from one to the other, nor do they call common sub-functions or
do they have common callers.
----------------------------------------------------------------------
Questions with more than one question element in them, for example
	. WHO USES WHO FREELY
	. WHICH FNS ON MYFILE CALL WHO NOT @ GETD
work much better now.
----------------------------------------------------------------------
Relative clauses:
another way of saying a <set> is via a "relative clause", introduced
by one of the relative pronoun words THAT, WHICH, or WHO, i.e. a <set>
may also be:
	<rel.pro> <verbs> <set>
	<rel.pro> IS/ARE <set>
e.g. 
	. EDIT WHERE X USES ANY THAT ARE BOUND BY Y
	. FOR X THAT BINDS Z DO (PRINT Z)
	. WHICH FUNCTIONS WHICH BIND Z OR ARE CALLED BY Y
	...ARE CALLED SOMEHOW BY X
---------------------------------------------------------------------
subject/verb inversion:
you can ask questions of the form
	. DOES <set> <verb> <set>
	. IS <set> <set>
e.g.
	. DOES X BIND Y
	. IS FOO CALLED SOMEHOW BY Z
As usual DOES=DO, ARE=IS
--------------------------------------------------------------------
ALL masterscope commands may now be followed by the phrase
"OUTPUT filename" to have the results of the command printed on the
given file. For example,
. DESCRIBE THE FUNCTIONS ON MYFILE OUTPUT LPT:
or
. WHO ON MYFILE CALLS WHO LIKE /$ OUTPUT UNDOABLE.LIST
-------
25-JAN-81 23:01:30-PST,416;000000000001
Date: 25 JAN 1981 2301-PST
From: KAPLAN
Subject: New FILEPKG
To:   teitelman, masinter, lisp
cc:   goldman at ISI

HASDEF now takes a SOURCE argument.

If the OPTIONS to GETDEF is or contains a string, that string will be returned
if not definition is found.  The caller can thus determine whether a
definition was found, even for types for which NIL/NOBIND are acceptable
definitions.

--Ron
-------
26-JAN-81 10:46:38-PST,277;000000000001
Date: 26 Jan 1981 10:46 PST
From: Teitelman at PARC-MAXC
Subject: Re: New FILEPKG
In-reply-to: KAPLAN's message of 25 JAN 1981 2301-PST
To: KAPLAN
cc:  masinter, lisp, goldman at ISI

Does this mean you are ready for me to release a new system and netlisp?

warren

 2-FEB-81 14:34:12-PST,281;000000000001
Date:  2 FEB 1981 1434-PST
From: KAPLAN
Subject: <NEWLISP>LMMAC
To:   TEITELMAN, MASINTER
cc:   LISP

I copies Vittal's version to <NEWLISP>  I also added to it a PDP-10
version of the function ALLOCSTRING.  This should be documented in the
next manual.

--Ron
-------
 6-FEB-81 00:16:36-PST,590;000000000001
Date:  6 FEB 1981 0016-PST
From: KAPLAN
Subject: <NEWLISP>FILEPKG
To:   TEITELMAN, MASINTER
cc:   LISP

Bugs in HASDEF/GETDEF fixed.

There is a change in the interpretation of the SOURCE argument, which
should be documented:

If source is the atom ?, it is interpreted as either 0, T, or FILE.

Most functions (e.g. EDTIDEF, GETDEF) default the source argument to ?, so
that NIL gives the behavior as currently described.

However, HASDEF defaults source to 0, the current definition.  This
also gives the currently expected behavior for that function.

--Ron
-------
 9-FEB-81 10:30:11-PST,1317;000000000001
Date: 9 Feb. 1981 10:29 am PST (Monday)
From: Teitelman.PA
Subject: moveitem
To: lisp



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

Date:  8 FEB 1981 2346-PST
From: KAPLAN
Subject: MOVEITEM problem
To:   VANBUER at USC-ECL
cc:   MASINTER, TEITELMAN

In a recent message to Teitelman, you complained about the behavior
of MOVEITEM.  In particular, you found that if the latest version of the
function was in core, it would ignore that definition and retrieve an
older definition from a file, clobber the in-core def with that
one, and move the older one to the new file.

This is how the function behaves when you specify a particular file
for the FROMFILE argument.  By specifying that file, you are indicating
that the definition you want is NOT the in-core definition, but rather
the one from that file.  If, however, you don't specify a file, you are
indicating that you want either the current in-core def, a saved
definition, or one from some file known to WHEREIS.  Thus, if you hadn't
specified a FROMFILE in your call, you would have gotten what you
expected.

I don't think this is a bug in the logic of MOVEITEM.  Perhaps a
caveat in the manual about the significance of the FROMFILE argument
is in order.

--Ron
-------
------------------------------------------------------------

 9-FEB-81 10:31:44-PST,367;000000000001
Date: 9 Feb. 1981 10:31 am PST (Monday)
From: Teitelman.PA
Subject: moveitem
To: lisp


Date: 9 Feb 1981 09:13 PST
From: Masinter at PARC-MAXC
Subject: Re: MOVEITEM problem
In-reply-to: KAPLAN's message of 8 FEB 1981 2346-PST
To: KAPLAN
cc: VANBUER at USC-ECL, MASINTER, TEITELMAN

minor note: MOVETOFILE is the "new" name for MOVEITEM. 

Larry



24-FEB-81 11:34:40-PST,793;000000000001
Date: 24 Feb. 1981 11:34 am PST (Tuesday)
From: Teitelman.PA
Subject: manual
To: lisp


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

Mail-from: Arpanet host SU-SCORE rcvd at 17-DEC-80 2353-PST
Date: 17 Dec 1980 1415-PST
From: CSD.DEA at SU-SCORE (Doug Appelt)
Subject: A comment on the INTERLISP Manual
To: TEITELMAN at PARC-MAXC2

	Warren,

	A SCORE user pointed out the following problem with the
INTERLISP manual's description of the ARCTAN2 function.  The
manual's description is logically correct, however it requires the
user to assign the Y coordinate to the variable X and the X coordinate
to the variable Y.  Perhaps in the future, renaming these variables
could eliminate some confusion.

						- Doug
-------
------------------------------------------------------------

12-MAR-81 22:25:55-PST,1383;000000000001
Date: 12 March 1981 10:25 pm PST (Thursday)
From: KAPLAN.PA
Subject: Compile time constants
To: Lisp

This probably ought to be documented in the manual.
---------------------------

Date: 12 MAR 1981 2000-PST
From: MASINTER.PA
Subject: new CONSTANTS
To:   Yonke at BBND, Lewis at BBND
cc:   LispCore^

I think I have a new implementation of CONSTANTS which is reasonable.

The function CONSTANTS is on MISC (unfortunately, MACHINEINDEPENDENT,
which contains the CONSTANTS macro, is too late for bootstrapping
purposes). 

(CONSTANTS VAR1 VAR2 (VAR3 FORM3) VAR4)

define VAR1, ... VAR4 to be "constants": the compiler, when it
encounters a (free) reference to a constant will compile instead
  (CONSTANT VAR1)
  (CONSTANT VAR2)
  (CONSTANT FORM3)

That is, variables which appeared as an atom in a call to CONSTANTS
will merely get wrapped in a "CONSTANT" call.

Variables which appear in the CONSTANTS call as (atm form) will
get compiled as if the user had said (CONSTANT form) instead of atm.

The CONSTANTS file package command
	(CONSTANTS var1 var2 (var3 form) var4)

is equivalent to

  (DECLARE: EVAL@COMPILE
	(VARS var1 var2 (var3 form) var4)
	(P (CONSTANTS var1 var2 (var3 form) var4)))


Note that CONSTANTS are no longer DONTCOPY as the default.

Larry
------
------------------------------------------------------------

30-MAR-81 21:02:11-PST,3836;000000000001
Date: 30 MAR 1981 2102-PST
From: MASINTER
Subject: formerly <NEWLISP>TRYHARDER.TXT
To:   Lisp


i have removed the automatic spelling correctionfor movd, putd, getd,
setq etc on typein. instead i have replaced it with a new feature
which i ae been working on and which is very neat.

the feature looks much like the ? feature in that it is expliitly
involked after the fact, and is not always guaranteed
to be able to do anything. it is invokved via the old $ command
which is still used to specify a reexecution 
following an error so that you dont have to specify the target.
if an object to be substituted is also not specified,
e.g. user justtypes $ , or $ IN event spec, it means
"try harder".

the p.a. looks in the indicated event and begins processing it.
if it can find a form with quoted arguments, such that
car of the form has the property TRYHARDER on it, and 
one of the elements of this value apples, it will
perform the indicated transformation.

for example, on the propety list of GETPROPLIST is
the property ((GETPROPLIST ATM)). this may seem circular,
but in the case f the GETPROPLIST on the proprty, this
means that ATM (the argument to getproplist) is supposed to
have a property list, so that the system will try to coerce
the quoted argument to be such an atom, by spelling correction
against userwords. e.g.if i type
GETPROPLIST(FOOO) or (SETPROPLIST 'FIE (GETPROPLIST 'FOOO))
and then type $, the system will correcct FOOO to FOO.

here is a more interesting example:

on property list of GETPROP is
((GETPROPLIST ATM) (OR (MEMB PROP (PROPNAMES ATM)) (MEMB PROP SYSPROPS)))

this says to try to fix the first argument if quoted)
to be an atom with a property lit, and try to fix the second
argument so that it is either one of theproperties on
the list (PROPNAMES is simply (MAPLIST (GETPROPLIST X) (FUNCTION CAR)(FUNCTION
CDDR)))  and if that fails, then spelling correct against SYSPROPS.


here is another example:
on property list of SETQ is value ((BOUNDP XSET)).

this says that if the use types $, then the variable that
was set should (have been) bound at the time, i.e. not
a new variable. (for thi reason, before checking any of
the predicates, the system undoes the indicated event, and then
undoes that if it doesnt make any change). thus
if yu type SETQ(FOO --)  and then SETQ(FOOO --) and
notice that the syste didnt type (FOO RESET), you just
type $ and it unsets FOOO and fixes it to be FOO.

one fnal example:

on property list of EDITF is an expression like
(SOME FILELST (FUNCTION (LAMBDA (FL) (MEMB FN (FILEFNSLST FL]
in this case, i you type EDITF(MUMBLLE) and system
doesnt know abut MUMBLLE< thouh it is in one of the files
it knows abut, and you type $, it will correct MUMBLLE.

notice that the information on tryharder is in  declarative
form so thatit can be used first to check to see if th condition
already holds, and then to make it hold. i debated separating
thatout into two different expressions, but so far havent done so.
currently, tryharder knows about GETPROPLIST, GETD,
BOUNDP, MEMB, OR , and SOME, whic in fact covers a wide variety
of spelling correction situations.

the thing i like about this is that there are a lot of
places in the system where spelling correction is built in
because an error is going to occur anyway, but for something
like GETD(FOOO), NIL might in fact be a reasonable thing to
return. only the usr knows if he mistyped, so that being able
to quickly say tryharder seems like a win. the feature is
also useful for those cases where the system may not want
to try a really involved correction, e.g. mapping through
all of filelst to do a spelling correction, unless the user
expliitly instructs it to do so knowing thatit will succeed.


warren
-------
17-APR-81 22:37:52-PST,369;000000000001
Date: 17 APR 1981 2237-PST
From: MASINTER
Subject: fixes in EDIT, LOADFNS
To:   LispCore^, Lisp

I fixed the problem in EDITLOADFNS? which caused the system
to (SHOULDNT) if you did LOADFROM({PHYLUM}xxx) and then tried
to edit a function on xxx.

I fixed a glitch whereby LOADCOMP didn't load in
(DECLARE: EVAL@COMPILEWHEN --) expressions.

Larry
-------
10-MAY-81 23:29:44-PDT,1450;000000000001
Date: 10 MAY 1981 2329-PDT
From: KAPLAN
Subject: WORDDELETE terminal class
To:   lispcore^, yonke at BBND
cc:   lisp

I have implemented an extension to terminal tables so that a WORDDELETE
character may be defined.  This will wipe out to the first non-OTHER
character preceding the first non-SEPR by printing the first-ch delete
message and as many nth-char delete messages as needed.

The syntax classes of the various characters are determined from the readtable
given to the current read-function.

I made ^W be the WORDDELETE character inthe ORIG termtable.  In effect, this
then replaces the current, kludgy implementation of word-delete
as an immediate read macro.  It does have one unfortunate
side-effect, since ^W currently has another function:  when ^W is typed
as the first character to a READ, it causes the following  expression
to be evaluated before it gets placed on the history list.  In order to
get this facility, you must now type ^VW to suppress the word-delete function.

Perhaps in INterlisp-D we should use one of the unmarked keys as word-delete.
Suggestions?

But perhaps it is also more reasonable to get the lispx function
of ctl-W imlemented in some other way, perhaps as a lispx history command.
Comments?

Of course, individual users can change the default by doing a SETSYNTAX in
their intializations.

This will be in the next loadup (not the one Beau mentioned).

--Ron
-------
11-MAY-81 23:24:53-PDT,1656;000000000001
Date: 11 MAY 1981 2324-PDT
From: KAPLAN
Subject: Change to * FILEPKGCOM and WHEREIS
To:   TEITELMAN
cc:   LISP

I changed the basic WHEREIS function to bring it into alignment with
the one in the WHEREIS package.  Specifically, the simple WHEREIS now
has an extra argument FN which, if given, is a function that will be applied
to each file containing NAME.  In the case, WHEREIS will return NIL
instead of the list of files.

This change means that code doesn't have to be written
differently depending on whether the WHEREIS package is loaded.

A second change:  The fact that the * FILEPKGCOM always does a form-feed
has been a singularly unappreciated feature, to the extent that most of
us have redefined it.  Taking the bull by the horns, I fixed it so
that it puts out the formfeed only if the second element of the comment
is a *.  (* FOO) will just skip a few lines, but (* * FOO)will turn the
page.  File comments are therefore more similar to ordinary comments.

We also introduced a varialbe LAMBDAFONTLINELENGTH, to hold the linelength
for comments in the lambda font.  THis variable is set in the
fontdefs.  (This is temporary, since we are heading towards a variable-
pitched font world.

A final thing about the * command:  We removed the DECLARE: expressions that
surround the comments, in the interests of cleaning up the way files look.
It was argued that not that much structure is involved in that, and
eventually recompile can be changed to simply suppress copying comment
expressions.

This message has gone to LISP for the manual; I hope it also helps you track
what's going on.

--Ron
-------
12-MAY-81 20:04:46-PDT,793;000000000001
Mail-from: Arpanet host BBNG rcvd at 12-MAY-81 2004-PDT
Date: 12 May 1981 2300-EDT
From: VITTAL at BBNG
Subject: Re: I have forgotten what this is all about; can you illuminate?
To:   Masinter at PARC-MAXC
cc:   vanMelle at PARC, Yonke at BBND, Hartley at BBND,
cc:   Lewis at BBND

Larry and Bill:

There are some JSYS differences between TOPS20 releases that require
knowing what release you are running.  There is no way to find out
from TOPS20 what release is being run, so the TOPS20.RELEASE file
came into being.  If I remember right, one of the primary places
that required knowing that information was in the implementation
of the USERNAME and DIRECTORYNAME functions.

The value in the file should be just a number; it is read with the
NIN jsys.  

John
-------
12-MAY-81 21:02:17-PDT,2819;000000000001
Date: 12 MAY 1981 2102-PDT
From: MASINTER
Subject: Current release has CHARCODE included
To:   lisp

CHARCODE

The facilities in this file make it possible to gain the efficiency
that comes from dealing with character codes instead of character atoms
without losing the symbolic advantages of the latter.

Two functions (with appropriate macros, etc.) are provided:

charcode[c]  Nlambda that returns the character code structure specified
	by c.  If c is a 1-character atom or string, the corresponding character
	code is simply returned.  Thus (CHARCODE A) is 65, (CHARCODE 0) is 48.
	If c is a list structure, the value is an image of c with all the
	leaves replaced by the corresponding character codes.  E.g.,
	(CHARCODE (A (B C))) is (65 (66 67)).

	charcode permits easy specification of certain peculiar character
	codes:
	  A multi-character atom or string whose first character is ^ is
	  interpreted as the control-character corresponding to its second
	  character.  Thus, (CHARCODE ^A) is 1, the code for control-A.

	  The following key words are mapped into the indicated codes:
		CR	13
		LF	10
		SPACE or SP	32
		EOL	31
		ESCAPE or ESC	27
		BELL	7
		BS	8
		TAB 	9
		NULL	0
		DEL	127

	Finally, charcode maps NIL into NIL.  This is included because
	some character-code producing functions sometimes return NIL
	(e.g. NTHCHARCODE); a test for that value can be included
	in a charcode list along with true character-code values.

Charcode of symbolic arguments can be used wherever a structure of
character codes would be appropriate.  For example
	(FMEMB (NTHCHARCODE X 1) (CHARCODE (CR LF SPACE)))  or
	(EQ (BIN FOO) (CHARCODE ^C))

There is a macro for charcode which causes the character-code structure
to be constructed at compile-time.  Thus, the compiled code for these
examples is exactly as efficient as the less readable
	(FMEMB (NTHCHARCODE X 1) (QUOTE (13 10 32)))
	(EQ (BIN FOO) 3)

The second function in this file is a selection function similar to
SELECTQ, except that the selection keys are determined by applying
charcode (instead of QUOTE) to the key-expressions:

selcharq[e;clause1...clausen;default]  Nlambda like selectq.  If the value of
	e is a character code or NIL and it is EQ or MEMB to the result
	of applying charcode to the first element of a clause, the remaining
	forms of that clause are evaluated.  Otherwise, the default is evaluated.
Thus
	(SELCHARQ (BIN FOO)
		  ((SPACE TAB) (FUM))
		  ((^D NIL) (BAR))
		  (a (BAZ))
		  (ZIP))
is exactly equivalent to
	(SELECTQ  (BIN FOO)
		  ((32 9) (FUM))
		  ((4 NIL) (BAR))
		  (97 (BAZ))
		  (ZIP))

Furthermore, selcharq has a macro such that it always compiles as
an equivalent selectq.

-----
Comments and suggestions to Ron Kaplan
-------
12-MAY-81 21:21:48-PDT,117;000000000001
Date: 12 MAY 1981 2121-PDT
From: MASINTER
Subject: Current release contains SCRATCHLIST:
To:   Lisp


-------
22-MAY-81 17:37:54-PDT,894;000000000001
Date: 22 May 1981 17:38 PDT
From: Masinter at PARC-MAXC
Subject: new Interlisp-10 loadup
To: "@[parc-maxc]<netlisp>InterlispSites.dl"
cc: LispCore^, DHARE@SRI-CSL
Reply-To: Masinter

There is a new loadup on [parc-maxc]<netlisp>netlisp.sav;142

Fixes problem reported by several sites with HPRINT on hash arrays.
This release also fixes a minor problem HOSTNUMBER on hosts
with high imp numbers. HOSTNUMBER() returns a number in
accordance with the new 96-bit leader standard.
(HOSTNUMBER fixes courtesy Wilber@SRI-AI.)

IMPORTANT NOTE:

In the past, it was usually the case that Interlisp-10 loadups were
tested at PARC for at least a few weeks before releasing a Netlisp.
However, our Interlisp-10 usage has been diminishing. Thus, this
system is relatively untested; you should proceed with caution
(e.g., release the system at first only to your pioneers.)

Larry

10-JUN-81 08:25:02-PDT,9278;000000000000
Date: 10 June 1981 8:24 am PDT (Wednesday)
From: Masinter.PA
to: Lisp
Subject: f.y.i., to appear in SIGART

Interlisp-D: Further steps in the flight from time-sharing

The Interlisp-D Group
Cognitive and Instructional Sciences
Xerox Palo Alto Research Center

The Interlisp-D project was formed to develop a personal machine implementation
of Interlisp for use as an environment for research in artificial intelligence and
cognitive science [Burton et al., 80b].  This note describes the principal
developments since our last report almost a year ago [Burton et al., 80a].

Principal characteristics of Interlisp-D

Interlisp-D is an implementation of the Interlisp programming environment
[Teitelman & Masinter, 81] for the Dolphin and Dorado personal computers.  Both
the Dolphin and Dorado are microprogrammed personal computers, with 16-bit
data paths and relatively large main memories (~1 megabyte) and virtual address
spaces (4M-16M 16 bit words).  Both machines have a medium sized local disk,
Ethernet controller, a large raster scanned display and a standard Alto keyboard
and "mouse" pointing device.  

Both the internal structure of Interlisp-D and an account of its development are
presented in [Burton et al, 80b].  Briefly, Interlisp-D uses a byte-coded
instruction set, deep binding, CDR encoding (in a 32 bit CONS cell) and
incremental, reference counted garbage collection.  The use of deep binding,
together with a complete implementation of spaghetti stacks, allows very rapid
context switching for both system and user processes.  Virtually all of the
Interlisp-D system is written in Lisp.  A relatively small amount of microcode
implements the Interlisp-D instruction set and provides support for a small set of
other performance critical operations.  The at one time quite large Bcpl kernel has
been all but completely absorbed into Lisp, for the reasons outlined in [Burton et
al, 80b].

Interlisp-D is completely upward compatible with the widely used PDP-10
version.  All the Interlisp system software documented in the Interlisp Reference
Manual [Teitelman et al., 78] runs under Interlisp-D, excepting only a few
capabilities explicitly indicated in that manual as applicable only to Interlisp-10. 
The completeness of the implementation has been demonstrated by the fact that
several very large, independently developed, application systems, such as the
KLONE knowledge representation language [Brachman, 78], have been brought
up in Interlisp-D with little or no modification.  Interlisp-D is in active use by
researchers (other than its implementors) at both Xerox PARC and Stanford
University and is now approaching the level of stability and reliability of
Interlisp-10.

Current performance

The performance engineering of a large Lisp system is distinctly non-trivial.  We
have invested considerable effort, including the development of several
performance analysis tools, on the performance of Interlisp-D and, as a result,
seen its performance improve by nearly a factor of five over the last year. 
Although relative performance estimates can be misleading, because of variation
due to choice of benchmarks and compilation strategy, the overall performance of
Interlisp-D on the Dolphin currently seems to be about twice that of Interlisp-10
on an otherwise unloaded PDP KA-10.  Although this level of performance
makes the Dolphin a comfortable personal working environment, we have
identified a number of improvements which we anticipate will further improve
execution speed by between 20% and 100%.

Machine independence

Another major thrust has been to reduce the dependencies on specific features of
the present environment, so as to facilitate Interlisp-D's implementation on other
hardware.  Dependencies on the operating system have been removed by
absorbing most of the higher (generally machine independent) facilities provided
by the operating system into Lisp code.  Gratuitous dependencies on attributes of
the hardware, such as the 16-bit word size, have been removed and inherent
ones isolated.  In addition to an abstract desire for transportability, our sharing of
code with other Interlisp implementation projects provides a on-going motivation
for this effort.

Extended functionality

The principal innovations in Interlisp-D, with respect to previous
implementations of Interlisp, involve the extensions required to allow the
Interlisp user access to a personal machine computing environment.

Network facilities

While network access is a valuable facility in any computing environment, it is
of particular importance to the user of a personal machine, as it is the means by
which the shared resources of the community are accessed.  Over the last year,
Interlisp-D has incorporated both low level Ethernet access and a collection of
various higher level protocols used to communicate with the printing and file
servers in use at PARC.  It is now straightforward to conduct all file operations
directly with remote file servers.  This both allows the sharing of common files
(e.g., for multi-person projects, such as the construction of Interlisp-D itself),
permits a user to move easily from one machine to another, and eliminates any
constraints of local disk size.  We have also begun to investigate the possibility
of paging from a remote virtual memory elsewhere on the network.  This would
not only allow completely transparent relocation of a user's environment from
one machine to another, but would open up a variety of interesting schemes for
distributing a computation across a set of machines.

High level graphics facilities

Interlisp-D has always had a complete set of raster scan graphics operations
(documented in [Burton, 80b]).  More recent developments include a collection of
higher level user graphics facilities, akin to those found in other personal
computing environments.  The most important of these is the Interlisp-D window
package.  This facility differs in spirit from most other window systems in that,
rather than imposing an elaborate structure on programs that use it, it is a self
consciously minimal collection of facilities which allow multiple programs to
share the same display.  Although some mechanism is necessary to adjudicate a
harmonious sharing of the display, we feel that higher level display structuring
conventions are still an open research question and therefore should not yet be
incorporated into a mandatory system facility.  The window package does provide
both interactive and programatic constructs for creating, moving, reshaping,
overlapping and destroying windows, in such a way that a program can be
embedded in a window in a completely transparent (to that program) fashion. 
This allows existing programs to continue to be used without change, while
providing a base for experimentation with more complex window semantics in the
context of individual applications.

One such existing application is a display based, structural program editor.  This
editor, in contrast to the character orientation of most modern display based
program editors, is the result of marrying display techniques (selection and
command specification by pointing, incremental reprinting, etc) with the
structure orientation of the existing Interlisp editor.  Indeed, the two editors are
interfaced so that the considerable symbolic editing power of the existing editor
remains available under the display based one.  Although our initial experience
has been positive, the user interface is under continued revision as we gain
further experience with this style of editing.

Future plans

The area in which we anticipate most future development of Interlisp-D is the
personal computing facilities, such as graphics and networking, and their
integration into Interlisp's rich collection of programming support tools.  While
radical changes to the underlying language structures are made difficult by our
desire to preserve exact Interlisp compatibility, we also expect some language
extensions, including some form of object oriented procedure invocation.

One of the great strengths of Interlisp has been the many contributions made by
its active, critical user community.  We are hopeful that the recent commercial
availability of Interlisp-D to other sites, and the consequent growth of its user
community, will be a similar source of long term strength and, in the short term,
significantly accelerate the pace with which Interlisp evolves away from its
time-shared origins into a personal computing environment.

REFERENCES

Brachman, R. et al.
KLONE Reference Manual.  BBN Report No. 3848, 1978.

Burton, R. et al.
Overview and status of DoradoLisp.  Proceedings of the 1980 Lisp Conference,
Stanford, 1980a.

Burton, R. et al.
Papers on Interlisp-D. Xerox PARC report, SSL-80-4, 1980b.

Teitelman, W. et al.
The Interlisp reference manual.  Xerox PARC, 1978.

Teitelman, W. and Masinter, L.
The Interlisp programming environment.  IEEE Computer, 14:4 April 1981, pp.
25-34.

The members of the Interlisp-D group are Beau Sheil, Bill van Melle, Alan Bell,
Richard Burton, Ron Kaplan and Larry Masinter.

12-JUN-81 09:38:49-PDT,1552;000000000000
Date: 12 June 1981 9:27 am PDT (Friday)
From: Masinter.PA
Subject: New (untested) Interlisp-10: [PARC-MAXC]<NETLISP>NETLISP.SAV;143
To: InterlispSites^
Reply-To: Masinter

(note: you can now send mail to InterlispSites^@parc-maxc from other network
sites to have mail redistributed to all sites.)

There is a new (and poorly tested) loadup on
[PARC-MAXC]<NETLISP>NETLISP.SAV;143.
(PARC users will find the equivalent loadup on <SUBSYS>LISP.SAV;143). 

This loadup purports to fix:

* Problem with HPRINT of arrays (different problem than the previous
  problem of HPRINT on hash-arrays)>

* Problem with CLISPIFY((MAPC X (FUNCTION(LAMBDA (Y Z) --)))
  (it doesn't do the transformation to a for because the lambda variables
  might be reset).

* Problem with DWIMIFY((~(X~=NIL)))

* recompile when GENNUM is high dropping functions


Things not fixed:

* [CMP.COHEN@UTEXAS-20;7 May 1981 2000-CDT] "LOAD of files with {
	instead of ( at top level".

* [CSD.GREINER@SU-SCORE] "HASH Lispusers package files bigger now" 

* [APPELT@SRI-AI] "BQ NLAMBDA still dwimifies"

* [??] "NAME<cr> causes infinite loop"

* [Kay@parc-maxc] "broken puttable"

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

Query (reply to Henry Sowizral <HENRY at RAND-AI>):

"Would you know who I could contact to learn about making small
Interlisps? i.e. INTERLISP with as much taken out as possible
to free up core? (I assume some people out there have already
tried)."

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

11-JUL-81 23:30:25-PDT,1601;000000000000
Date: 11 JUL 1981 2329-PDT
From: MASINTER at PARC-MAXC
Subject: BACKQUOTE
To:   Sussman at BBNA
cc:   LispDiscussion^, InterlispSites^

On [parc-maxc]<NETLISPUSERS>BQUOTE.COM (and <Lispusers>BQUOTE) is
a version of the "backquote" macro for Interlisp. 

This is similar to the facility of the same name in other
common lisp dialects as follows:

|'form is equivalent to 'form, except that, in the body
of form, an element preceded by a "," is evaluated, and
an element preceded by ",," is evaluated and spliced in.

For example, |'(A ,B ,,C D ,,E) is equivalent to
(CONS 'A (CONS B (APPEND C (CONS 'D E]

There are a couple of parts to the implementation:

| is given a read macro, such that |'form reads in
  as (BQUOTE form). (the readmacro is in T, FILERDTBL
  and EDITRDTBL). During the READing of form (but
  not outside a |' context), "," is given a read macro
  such that ,X reads in as (UNBQUOTE X).

BQUOTE has a macro property to expand out its argument
into the appropriate nest of CONSes and APPENDs, looking
for UNBQUOTEs.

BQUOTE has an entry on PRETTYPRINTMACROS so that BQUOTEd
expressions will prettyprint with |'.

Rational: |' has been implemented in such a way that it
doesn't conflict with the use of | as the "changechar";
since "|" has heretofor been a SEPR, this means that it
should be possible to enable BQUOTE and not worry about
files made without "|" preceeded by a "%".

The read macro doesn't expand the form into CONSes and
APPENDs because it is important that functions which
use backquote prettyprint reasonably.

Larry

16-JUL-81 09:28:25-PDT,793;000000000000
Date: 16 Jul 1981 09:24 PDT
From: Masinter at PARC-MAXC
Subject: BQUOTE
To: LispDiscussion^, InterlispSites^
CC: CSD.JJF at SU-SCORE, csd.greiner at SU-SCORE, csd.dea at SU-SCORE,
 csd.smith at SU-SCORE
Reply-To: Masinter

There is (as of yesterday morning) a revised version of BQUOTE &
BQUOTE.COM on [parc-maxc]<LISPUSERS> and <NETLISPUSERS> respectively
with some slight extensions and fixes. 

Extended character set (LMLisp and MacLisp compatibility):

	,@ means the same as ,, (splice in using APPEND)
	,.  means to splice in using NCONC.

Minor fixes for some obscure cases, e.g., |'(... %, ...).

I intend to include this in the standard Interlisp-10 system, at which time the
character conventions will be more difficult to change. Comments appreciated.

Larry
12-AUG-81 16:13:33-PDT,7889;000000000000
Date: 12 Aug 1981 16:11 PDT
From: Masinter at PARC-MAXC
Subject: Re: Interlisp version 27-Nov-79 requested
In-reply-to: <10Aug81 150951 MR05@CMU-10A>
To: Mike.Rychener at CMU-10A (A110MR05)
cc: InterlispSites^, Gripe at cmu-20c
Reply-To: Masinter

(I'm sending this out to everyone on InterlispSites^ since
some of the information has been slightly revised, and some of you
may not have seen this.)

I will add your name to the InterlispSites^ distribution list
for future messages about Interlisp-10 releases.

To get a current Interlisp-10:

The lisp files are stored on [parc-maxc]<netlisp>.
All files are available for FTP from PARC-MAXC, using
account ANONYMOUS password <yourname>.  The only
files you absolutely need are <NETLISP>BOOT.SAV
and <NETLISP>NETLISP.SAV (which you should install
as <LISP>BOOT.SAV and SYS:LISP.EXE respectively).

Other files of interest:
<NETLISP>*.*;0
<LISP>*.;0
<LISP>*.MAC;0
<LISP>MESSAGE.TXT
<NETLISPUSERS>*.*;0
<HELPSYS>*.*;0

Some of these are explained as follows (excerpt from letter that
goes out with tapes):


Numbers in parenthesis denote chapters in the Interlisp Reference
Manual:

Many of these files are Lisp files, i.e. they consist of sequences
of LISP expressions, and are intended to be read by the Interlisp
function LOAD, using an appropriate readtable (14). Some of the files
are .MAC files, i.e. are PDP-10 assembly language programs
intended to be assembled with the MACRO assembler. The Lisp
files all begin with an expression of the form
(FILECREATED date --), and all end with the word STOP.
Finally, there is also a .SAV file which contains a complete
core image (makesys) for the current Interlisp system. 


<LISP>MESSAGE.TXT
		internal documentation messages about changes to the
		system which have occured since the last edition
		of the manual.

<NETLISP>MESSAGE.TXT: message files about proposed Interlisp
		extensions in the future

 LISP.MAC, ATHASH.MAC, GC.MAC and SWAP.MAC
		  PDP-10 assembly language files which implement
		  the main body of the machine dependent part of
		  Interlisp-10. All of the SUBRS, mechanism for
		  function call, the garbage collector, common
		  run-time routines used by the garbage collector,
		  handling of the spaghetti stacks, the Interlisp-10
		  code swapper are all in these files.

 FNS/VARS	This file can be used as in index for finding functions
		  on the LISP files which are part of the standard
		  released Interlisp system; it contains, for each
		  file in the standard system the value of the
		  fileCOMS and fileFNS.

 INIT.LISP	initialization file which is used here at PARC; among
		  other things, it sets up FILERDTBL to ignore
		  font control characters as described above.

 BOOTSTRAP, BASIC, MISC
		  contain the various low level, machine
		  independent, functions that are written in LISP,
		  e.g. APPEND, STRPOS, LOAD, PUTPROP, DEFINE, etc.

 BRKDWN	implements BREAKDOWN (21).

 WTMISC	defines additional general purpose functions, such as
		  RESETSAVE, LVLPRINT,  as well as redefining some
		  of the functions in BOOTSTRAP, BASIC, and MISC. 

 ADVISE	implements the ADVISE package (section 19).

 LMMAC, ASSEMBLE, MAC
		Interlisp-10 implementation-dependent routines.

 SWAP	Interface to the Interlisp-10 code swapper. (3).

 LOADUP	contains the functions which automate the loading of a new
		  interlisp, as well as a number of low level,
		  machine dependent functions.

 DATATYPE	implements some of the functions for user datatypes
		  (section 3) and a few others (HARRAYP,
		  conversion of type names to type numbers).

 CODEFORMAT	routines which know about format of PDP-10 compiled
		  code.

 COMPILE	the user interface to the Interlisp compiler, e.g. the
		  functions that compile, or recompile a file or
		  collections of files (18).

 COMP, LAP	the actual Interlisp-10 compiler, i.e. the programs that
		  given a lisp expression produce a sequence of
		  PDP-10 machine instructions (18).

 10MACROS	Interlisp-10 specific macros (18)
 MACROS	Machine independent macros (18).

 PRETTY, COMMENT the prettyprint package (14).

 EDIT, WEDIT	the Interlisp editor (9).

 BREAK	the Interlisp break package (15).

 HELPDL	contains functions that are invoked when an error occurs
		(but not the error correction machinery - see
		DWIM below), that search the stack and determine
		whether or not to go into a break, print a
		message etc. (16).

 ARITH	various arithmetic and trigonometric functions, e.g. SQRT,
		SIN (13).

 LOADFNS	implements the functions LOADFNS and its confederates,
		LOADFROM, LOADEFS etc. (14).


 FILEPKG	the Interlisp file package (14).

 HIST	contains the programmer's assistant (22).

 UNDO	functions associated with saving undo information, and
		undoing the corresponding operations (22).

 DWIM, WTFIX, CLISP, DWIMIFY
		implements DWIM and CLISP (17, 23).

 CLISPIFY	contains the package that converts ordinary Interlisp
		into CLISP (23).

 RECORD	The Interlisp record package (23).

 MATCH	The pattern match compiler (23).


 FFILEPOS	implements fast file search which uses the Boyer-Moore
		algorithm.

 MASTERSCOPE	The Masterscope system (20);

MASTERSCOPE.SYNTAX is an additional (online) documentation file.

 HELPSYS	the package that allows the user to interrogate the
		on-line Interlisp manual (section 20).

 ASSIST	contains ASKUSER, GAINSPACE & a few others.

 UTILITY	contains DIRECTORY (interface for searching file TENEX
		file system name space) and a few others (21).

 HPRINT	HPRINT (21).


 EDITA	the EDITA package (21)

The following two files are the only files which are necessary in
order to run Interlisp on a Tenex or TOPS-20.

 BOOT.SAV	This file must be on the <LISP> directory.

 LISP.SAV	File which contains the Interlisp system.

 The following files are necessary in order for HELPSYS (21) to work.

 *LISP.TTY	the Interlisp reference manual in machine readable form.

 HELPIDX, HELPADRF
		  The HELPSYS Data base.

Installing and running Interlisp

The file LISP.SAV should be on directory <SUBSYS>. On TOPS-20
systems, it is conventional to name this file LISP.EXE. It is
probably a good idea to use the same version number as appears on
the DUMPER tape when storing this file so that it is clear which
version of Interlisp you are running. Note that if you RENAME a
LISP.SAV from one directory to another or even change version
numbers, that SYSOUT's on that LISP will become confused. Some
sites have chosen, therefore, to put the LISP.SAV on <LISP> and put
an "indirect" on <SUBSYS> which merely runs the appropriate version
of LISP.SAV. There is a program MAKE-INDIRECT.SAV which makes 
these "indirect" files.

The file BOOT.SAV must be on directory <LISP>. Should you want to
make HELPSYS available at your site, the helpsys files should be
either on the directory <HELPSYS> or on the <LISP> directory
(HELPSYS will look for them in both places). Finally, the  file
INIT.LISP is a file containing S-expressions suitable for loading
by LOAD, and, if found on the directory <LISP>, is loaded
automatically (silently) each time a user starts up a fresh
Interlisp (i.e. not when a sysout is started). The INIT.LISP file
can be used, for example, to change defaults for various Interlisp
packages to be more suitable for the particular site or user
community. For example, at PARC, we use the INIT.LISP file to
enable some font change machinery for use with our printer (and in
fact the PARC INIT.LISP file is on your tape). Note that Interlisp
will run without <LISP>INIT.LISP. Furthermore, each individual user
can also have an INIT.LISP file on his own directory to establish
his own defaults, which will be loaded after the <LISP>INIT.LISP
file. 
18-AUG-81 14:40:02-PDT,432;000000000001
Date: 18 AUG 1981 1439-PDT
From: KAPLAN.PA
Subject: SHH:  New LISPXMACRO
To:   LISPCORE^
cc:   TEITELMAN, LISP

I've installed a new LISPXMACRO named SHH.  It is just like the E
command, except that the evaluation or application is done quietly--no
entry on the history list and not undoable.

SHH thus substitutes for the quirky ^W read macro, which now conflicts
with the terminal word-delete function of ^W.

--Ron
15-SEP-81 10:35:27-PDT,526;000000000001
Date: 15 Sept. 1981 10:28 am PDT (Tuesday)
From: Masinter.PA
Subject: Re: Compiler version on Dolphin
In-reply-to: Your message of 14 SEP 1981 2216-PDT
To: KAPLAN
cc: MASINTER, LispCore^, Lisp

I have disabled the COMPVERSION check (in all systems) because the
compversion message is wrong, not sensitive to compilermode, and doesn't
differentiate between the "compiler" version and the "system" version.

At some later date I may reinstall a mechanism for properly checking compiler
vs. system version.

Larry
21-SEP-81 14:33:13-PDT,184;000000000001
Date: 21 Sep 1981 14:33 PDT
From: Masinter at PARC-MAXC
Subject: I.S.OPRS
To: Lisp, Goldman@ISI
cc: Masinter

Next release will have I.S.OPRS dumped in a EVAL@COMPILE.

Larry
22-SEP-81 10:41:32-PDT,355;000000000001
Date: 22 Sept. 1981 10:41 am PDT (Tuesday)
From: Masinter.PA
To: LISP

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

From: LEWIS at BBND
Message-ID: <[BBND]10-Aug-81 14:52:24.LEWIS>

Main changes are addition of compile time constants. Also, fixed
several little bugs and some new optimizations were added
(eg, selectq of literals and (SYSTEMTYPE)).

Daryle
28-SEP-81 18:55:36-PDT,1246;000000000001
Date: 28 Sep 1981 18:54 PDT
From: Masinter at PARC-MAXC
Subject: Re: lisp software, <LISPUSERS> packages
In-reply-to: DONC's message of 4 Sep 1981 1719-PDT
To: Don.Cohen <DONC at USC-ISIF>
cc: InterlispSites^, LispDiscussion^
Reply-To: Masinter

Warren forwarded your inquiry about Lisp packages to me. 

New packages for <LISPUSERS> are actively solicited. Minimal
requirements are that the file be editable and compilable in a
"standard" Interlisp (e.g., all declarations which need be are in
DECLARE: EVAL@COMPILE's, including possibly (RESETSAVE
DWIMIFYCOMPFLG T), no special file package commands which
aren't explicitly imported, etc.), and that the file be accompanied
by a text file which describes its use. The text file should include
the name and net address of anyone who should get mail about
the use of the package. For example, you might submit EVALHOOK,
EVALHOOK.COM and EVALHOOK.TTY. 

We will put the file on <LISPUSERS> at PARC and elsewhere.
I will include it in the list I am putting together of <LISPUSERS>
files which are generally available. (Until then, you might just look,
using FTP as ANONYMOUS at [parc-maxc]<LISPUSERS> for things
which you do not already have at your local site.)

Larry
28-SEP-81 19:09:46-PDT,2083;000000000001
Date: 28 Sept. 1981 7:09 pm PDT (Monday)
From: Masinter.PA
Subject: Files and status
To: InterlispSites^
cc: LispDiscussion^
Reply-to: Masinter

I have been doing some shuffling of files in the last week or so,
and thought I might warn anyone attempting to FTP files from
PARC-MAXC about the current status:

FILES MOVING:
We have abandoned at PARC the special compiler and local
microcode for Interlisp-Maxc, because our local use of Interlisp-10
has diminished to the point where it was no longer worth the
effort to recompile all system files both for <NETLISP> and for
local use. There was thus no reason to keep separate copies of
files on the <NETLISP> directory, and I have been
moving/recompiling files to <LISP> and to <LISPUSERS>.

	former location		current location

	<NETLISP>*.COM		<LISP>*.COM
	<NETLISP>NETLISP.SAV	<LISP>NETLISP.SAV
	<NETLISPUSERS>*.COM	<LISPUSERS>*.COM

(We are still using some special Maxc-only features in LISP.MAC,
so that you should NOT retrieve [parc-maxc]<SUBSYS>LISP.SAV
and will not need <LISP>MAXC*.*.)

LOADUP STATUS:
We are currently testing a version <LISP>NETLISP.SAV;144. I have
found in this version several small glitches, to the point that I
would NOT recommend retrieving this version. I will send out
a message again when there is a new system in which I have
more confidence. 

FILE REORGANIZATION:
For those that load up their own systems: I have reorganized the files
which formerly were in "filegroups" so that they could be compiled
independently. For those who run their own loadups, it may be
necessary to alter your loadup procedure, as:

	PRETTY.COM -> PRETTY.COM, COMMENT.COM
	EDIT.COM -> EDIT.COM, WEDIT.COM
	WTFIX.COM -> WTFIX.COM, DWIMIFY.COM, CLISP.COM

[n.b. to LispDiscussion: you might consider altering your compilation
proceedures to no longer BCOMPL those files together; if you use
LOADUP, I also have altered versions of LOADUP.LISP. When
retrieving files, look on <NEWLISP> first, then on <LISP>, as some
of these changes are only in the <NEWLISP> files.]
29-SEP-81 15:29:03-PDT,482;000000000001
Date: 29 Sept. 1981 3:29 pm PDT (Tuesday)
From: KAPLAN.PA
Subject: ECHOCHAR, ECHOMETA, UPARROW --> INDICATE
To: LISP

At least for the non-pdp10 implementations, ECHOCONTROL has been modified
to use INDICATE instead of UPARROW.  For meta characters (128-255),
INDICATE means prefix with #.  ECHOMETA coerces characters into the meta
range.  The function ECHOCHAR takes char codes with no coercion--it is called
by ECHOCONTROL and ECHOMETA after coercion to do the work.

 9-DEC-81 09:17:09-PST,10966;000000000000
Date: 9 Dec. 1981 9:12 am PST (Wednesday)
From: Masinter.PA
Subject: New version of Interlisp-10 (release 145)
To: InterlispSites^
cc: LispUsers^

This message announces a new version of Interlisp-10, version 145.
This version is available to Arpanet sites as:
	[PARC-MAXC]<LISP>NETLISP.SAV;145. 

Please forward as appropriate to your users.

(Xerox users will find a version on <SUBSYS>LISP.SAV;145.) 

Sources and .COM files are also found on [PARC-MAXC]<LISP>.
Note that we have discontinued using PARC-specific .COM files, so that
the need for a separate NETLISP and NETLISPUSERS directories have
vanished. You should once again obtain all files from <LISP> and
<LISPUSERS>, although <NETLISP>MESSAGE.TXT may be of some interest.)

This release includes a number of important bug fixes and
improvements, as well as support for features to enable Interlisp
programs to be written so that they may be more easily ported to
other implementations of Interlisp (specifically, Interlisp-D,
Interlisp-Jericho and Interlisp-VAX.)

Note that most of these changes are not specific to Interlisp-10;
they appear in Interlisp-D, -Jericho and -Vax.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(SYSTEMTYPE)						[Function]

The function (SYSTEMTYPE) is defined in all implementations to
return the type of the currently running system. In Interlisp-10,
it returns either the atom TOPS20 or TENEX. Programs which need to
perform different actions depending on the type of system they are
running under can write

(SELECTQ (SYSTEMTYPE)
	((TENEX TOPS20) (* Interlisp-10 version) --)
	(VAX (* Interlisp-VAX version) --)
	((D ALTO) (* Interlisp-D version) --)
	(JERICHO (* Interlisp-Jericho version) --)
	--)

All Interlisp compilers, including Interlisp-10, will actually
perform the selection at compile-time (for the "target" system.)
This means that, although the selection looks like it is run-time,
it is actually handled at compile time.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(COMPILEMODE)						[Function]

The function (COMPILEMODE) is defined in all implementations to
return the type of the system being compiled for. This differs from
(SYSTEMTYPE) in that one can perform cross-compilation, e.g., run
the Interlisp-D compiler under Interlisp-VAX. Note also that
(COMPILEMODE) for Interlisp-10 is the atom PDP-10, rather than
TENEX and/or TOPS20.

This sometimes occurs, e.g., in the fileCOMS for a file, for
example:
(DECLARE: EVAL@COMPILEWHEN (EQ (COMPILEMODE) (QUOTE PDP-10))
		(FILES (SYSLOAD FROM VALUEOF LISPUSERSDIRECTORIES)
			CJSYS]


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
10MACRO						[Property]
MACRO						[Property]
VAXMACRO					[Property]
DMACRO (ALTOMACRO)				[Property]
JMACRO						[Property]
COMPILERMACROPROPS				[Variable]

Another way of conditionally compiling for different systems is to
use different macro properties. The Interlisp-10 compiler (and
other Interlisp compilers) now search for a number of properties
(as determined by the variable COMPILERMACROPROPS) rather than a
single one. The property MACRO should be reserved for
machine-independent macros. If you have macros which are specific
for a single implementation (e.g., Interlisp-10 macros which
generate ASSEMBLE code), you should use the
implementation-dependent macro name. In Interlisp-10, this is the
atom 10MACRO.

The packages EXPANDMACRO, MACROTRAN, ASSEMBLETRAN have all been
modified to be compatible with this change.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(LINELENGTH N FILE)				[Function]

The notion of line length is now file-specific. Every file has its
own individual line length.  The linelength for T is set from the
operating system via the function (SETLINELENGTH) {executed at
every (RESET) and when starting an Interlisp-10 sysout}. The line
length for disk files is initially set to be the value of
FILELINELENGTH when a file is opened for output.

This change was motivated primarily by multiple-window systems
where each window wants to have its own notion of the length of a
line, but is definitely an improvement in the semantics of
LINELENGTH. Unfortunately, it is necessary to examine existing uses
of the function LINELENGTH to ensure that they will continue to
operate correctly. Since the FILE to LINELENGTH, if unsupplied,
defaults to the current output file, most existing uses of
LINELENGTH will continue to work unchanged.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(ARRAY SIZE TYPE INIT)					[Function]

The ARRAY function in Interlisp-10 has been extended to accept a
TYPE argument as allowable in other Interlisp implementations. In
particular, TYPE can be any "specification" which is allowable in a
datatype declaration:
	(BITS n)
	POINTER
	FIXP
	FLOATP

There are not actually any new array types in Interlisp-10; that
is, the ARRAY function returns an array which will "hold" the
values specified. This allows code to be written which takes
advantage of the new features of the other Interlisp
implementations but will still run in Interlisp-10.

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(DEFPRINT TYPENAME FUNCTION)			[Function]

The interpretation of DEFPRINT function has been extended
(compatibly) so that the user's function gets passed a second
argument, FILE. If output is being directied to a file, the full
name of the file will be passed. (If output is for one of the
internal printing functions, e.g., NCHARS, the FILE argument will
be NIL.) The value returned from the users DEFPRINT function is
interpreted as follows:
  NIL - print the standard #nnnnn for this object
  a list - If the car is non-NIL, print it using PRIN1.  Then, if
	the CDR is non-NIL, print it using PRIN2.
	(The non-NIL CDR test is a change. It means the
	user doesn't have to return (PACK) to avoid
	PRIN2 printing.]
 anything else - no additional printing (beyond what the user
	function did) is performed.

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(ECHOCONTROL CHAR MODE)				[Function]

The function ECHOCONTROL returns and will accept as its MODE
argument the atom INDICATE (instead of UPARROW) to mean "indicate
the character as appropriate". This change was made in order to
handle reasonably the printing of characters in extended ranges,
namely, the 8-bit character codes in other Interlisp
implementations.)

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(SKIPSEPRS FILE RDTBL)					[Function]

Advances the file pointer of FILE until a non-SEPR character in RDTBL is
peeked at. Value is that non-sepr, or NIL if there are no non-seprs left on the
file.

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
BREAKCHECK and NLSETQ interaction

We have fixed the interaction with NLSETQ and BREAK so that it is
guaranteed that no break will occur (unless HELPFLAG is !BREAK) and
no error message will be printed (unless NLSETQGAG is NIL) under an
NLSETQ.

This change removes the necessity of re-binding HELPFLAG to ensure
this behavior, e.g., (RESETVARS (HELPFLAG) (RETURN (NLSETQ --] can
be re-written back as (NLSETQ --].
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(FINDFILE FILE NSFLG DIRS)				[Function]

The FINDFILE function has been modified slightly. If the DIRS
argument is supplied, FINDFILE will no longer first look on the
connected directory. The connected directory will be searched if and when the
atom T is found in the list. NIL in the DIRS-list still means the "login"
directory. (Note: FINDFILE is a "super" INFILEP; it attempts
spelling correction, unless NSFLG is T, and will scan the given
DIRS or the directories on the global variable DIRECTORIES.
This mechanism may be used in lieu of or in addition to the
directory-path feature of TOPS-20; many system packages when
scanning for files use FINDFILE or its SPELLFILE equivalent.)

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Font profile change

The entries on the variable FONTPROFILE no longer need the "extra
cell" documented in the manual.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
New (versions of) LISPUSERS packages, on [PARC-MAXC]<LISPUSERS>

Site maintainers should check to see if they have the latest versions of the
following LISPUSERS packages. Unfortunately, some of the version numbers have
been reset, so that the most reliable way of checking is to look at the
FILECREATED date, or at least the creation-date of the file on our <LISPUSERS>
directory. Files recently updated or released include:

BQUOTE (new package, see .TTY file), DECL, PERFORMTRAN (new package),
ALL, COMMENT, REMIND

All other packages have been recompiled using a somewhat improved PDP-10
compiler; it is probably also worth retrieving new .COM files for all packages.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
GREET implementation change

GREET no longer uses the GREETDIRECTORY/GREETFILE/GREETEXT
mechanism to determine the "name" of the greet file. Instead, GREET calls
a single function, GREETFILENAME, which can be advised or redefined if the
user wants to modify the behavior of GREET. 

(GREETFILENAME USER) is called twice, once with USER=T and once with
USER=USERNAME. In the standard system, (GREETFILENAME T) returns
<LISP>INIT.LISP, while (GREETFILENAME 'user) returns <user>INIT.LISP.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
FNS/VARS file

Unfortunately, there is no FNS/VARS file for this loadup of Interlisp-10.
We will attempt to provide a cross reference file in the near future.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Special loadups

For those sites which make special loadups, please be advised that the
"filegroups" (PRETTY COMMENT), (EDIT WEDIT), (DWIMIFY WTFIX CLISP)
have been split up. If you were formerly explicity loading (or excluding)
PRETTY.COM, you will have to explicitly load (or exclude) both PRETTY.COM
and COMMENT.COM to have the same effect.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Various fixes:

LOADCOMP? remembers more reasonably which files have been
LOADCOMPed. Many minor fixes to the file package, break package,
clispify, record. 

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
A few reported bugs have not been fixed yet:

(EXPT 16.0 16) still returns wrong result (Interlisp-10 only).

Masterscope cannot analyze expressions beginning with "with".
	does not see field names used in conjunction with change-words.
	SHOW PATHS has problems with extremely long function names.

If there are other bugs which have been reported and have not been fixed,
please remind us.

-- The Interlisp Maintainers 
	[consisting currently of various people at Xerox, BBN, and ISI].
 9-DEC-81 09:54:46-PST,1550;000000000000
Date: 9 Dec. 1981 9:40 am PST (Wednesday)
From: Masinter.PA
Subject: Subject: New version of Interlisp-10 (release 145) ADDENDUM
To: InterlispSites^
cc: LispUsers^

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Compiler

This version of Interlisp-10 contains an improved compiler. In particular,
the compiler performs some "constant-folding". For example, simple numeric
expressions consisting only of constants will be computed at compile time.
This is particularly useful in expressions which get generated via macros.
[These optimizations are also performed by the Interlisp-D (and thus -VAX)
compilers and, I believe, the Interlisp-Jericho compiler.]

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(CONSTANTS . vars)			[File package command]

The user can now declare variables as constants (in all Interlisp 
implementations). The file package command (and function) CONSTANTS
resembles the VARS file package command in format, but the value
of the variable will actually be used in-line in the code generated by
the compiler. This allows users to declare variables as compile-time-constants
without having to explicitly wrap a CONSTANT around its use.

This feature should be used with some caution, since functions must
which use a constant must be recompiled when the value of the constant
changes. If there is a Masterscope data base of the users functions, Masterscope
will warn the user about which functions need recompilation when a
CONSTANT is reassigned at the top level.


11-DEC-81 21:56:50-PST,340;000000000000
Date: 11 DEC 1981 2156-PST
From: MASINTER
Subject: DWIMIFY etc.
To:   kaplan, lisp
cc:   masinter

I fixed it so that even if DFNFLG=PROP that DWIM will unsave function
definitions. The test there was just wrong; often I define a new
function in ABC for immediate use, but since DFNFLG=PROP it gets
put on the proplist. 

Larry
28-DEC-81 21:45:13-PST,325;000000000001
Mail-from: Arpanet host KESTREL rcvd at 28-DEC-81 2145-PST
Date: 28 December 1981  21:41-PST (Monday)
From: WESTFOLD at KESTREL
To: MASINTER@PARC
Cc: WESTFOLD
Subject: Editor bug in LISP 145

(BK n) and (NX n) don't work.
The problem is that (EDIT* C2) in EDITCOML has been dwimified to
(ITIMES EDIT C1) !

steve
28-DEC-81 22:31:09-PST,280;000000000001
Date: 28 DEC 1981 2231-PST
From: MASINTER
Subject: Re: Editor bug in LISP 145
To:   WESTFOLD at KESTREL
cc:   MASINTER

In response to your message sent  28 December 1981  21:41-PST (Monday)

Thanks for the bug report. I have fixed it; will be in next
release.

Larry
 4-JAN-82 15:32:29-PST,131;000000000000
Date:  4 JAN 1982 1532-PST
From: KAPLAN
Subject: Change to ADDTOCOMS, ADDTOFILE: NEAR and LISTNAME are args now
To:   LISP


 5-JAN-82 21:31:39-PST,365;000000000000
Date:  5 JAN 1982 2131-PST
From: KAPLAN
Subject: I added RESETTOPVALS in MACHINEINDEPENDENT
To:   MASINTER, LISP

which is like RESETVARS except that it uniformly sets the top-value cell
in both deep and shallow.  The body is a PROGN body, not a PROG body.
COmpiles open.

I also distributed this as appropriate in COMPILE, and put the macro in MACROS.

11-JAN-82 12:38:23-PST,3905;000000000001
Date: 11 Jan. 1982 12:31 pm PST (Monday)
From: Masinter.PA
To: Lisp, LispCore^

COPYRIGHT

The system now has a facility for automatically inserting a
copyright notice near the front of files, right after the
FILECREATED expression, specifying the years it was edited and the
copyright owner.  The format of the copyright notice is:

(* Copyright (c) 1981 by Foo Bars Corporation)

Once a file has a copyright notice then every version will have a
new copyright notice inserted into the file without user intervention. 
(The copyright information necessary to keep the copyright up to
date is stored at the end of the file.).

COPYRIGHTFLG					[Variable]
COPYRIGHTOWNERS				[Variable]
DEFAULTCOPYRIGHTOWNER			[Variable]

The variables COPYRIGHTFLG, COPYRIGHTOWNERS, and
DEFAULTCOPYRIGHTOWNER control the operation of the
COPYRIGHT facility.

If COPYRIGHTFLG=NIL (default), the system will preserve old
copyright information, but will not ask the user about copyrighting
new files.

If COPYRIGHTFLG=T, then when a file is made, if it has no copyright
information, the system will ask:

filename copyright owner:

The potential responses are controlled by the list COPYRIGHTOWNERS. 
COPYRIGHTOWNERS is a list of entries of the form

	(KEY OWNERSTRING) 

where KEY is used as a response to ASKUSER and OWNERSTRING
is a string which is the full identification of the owner.  In addition,
there are three other possible responses the user can make (even if
COPYRIGHTOWNERS is NIL)

(1) Type a left-square-bracket. The system will then prompt for
an arbitrary string which will be used as the owner-string

(2) Type a right-square-bracket, which specifies that the user
really does not want a copyright notice.

(3) Type "NONE" which specifies that this file should never have
a copyright notice.


If the user does not respond in DWIMWAIT seconds to the copyright
query, the value of DEFAULTCOPYRIGHTOWNER will be used instead.

For example, if COPYRIGHTOWNERS has the value

	((BBN "Bolt Beranek and Newman Inc.")
	 (XEROX "Xerox Corporation"))

then for a new file FOO the following interaction will take place:

	Do you want to Copyright FOO? Yes
        Copyright owner: {user typed ?}
	one of:
	BBN - Bolt Beranek and Newman Inc.
	XEROX - Xerox Corporation
	NONE - no copyright ever for this file
	[ - new copyright owner -- type one line of text
	] - no copyright notice for this file now

	Copyright owner: BBN

Then "Foo Bars Corporation" in the above copyright notice example
would have been "Bolt Beranek and Newman Inc."

Any year the file has been edited is considered a "copyright year" and
therefore kept with the copyright information.  For example, if a file
has been edited in 1981, 1982, and 1984, then the copyright notice
would look like:

(* Copyright (c) 1981,1982,1984 by Martin D. Yonke)

Implementation notes

The copyright information for a file is stored on the property list
of the file, under the COPYRIGHT property, which is a list of the form
(OWNER year1 year2 ...). To remove all current copyright information
about a file, call (REMPROP FILE 'COPYRIGHT).

If COPYRIGHTFLG=NEVER, the system will neither prompt for new
copyright information nor preserve old copyright information.

Copyright information included via the previous <LISPUSERS>COPYRIGHT
package will be preserved (i.e., the copyright facility looks at the 
COPYRIGHTOWNER and COPYRIGHTYEARS property of a file.)


= = = = = = = = = = = = = = = = = = =

In addition, there is available on <LISPUSERS>COPYRIGHT & .COM an 
extension of the copyright facility: if you load in this file, then copyright
notices will be printed as

(*                      Copyright (c) 1981, 1982, 1984
                                    by
                           Larry M. Masinter                                    *)
11-JAN-82 20:58:08-PST,425;000000000000
Date: 11 Jan. 1982 8:55 pm PST (Monday)
From: vanMelle.PA
Subject: Common Lisp
To: LispDiscussion^
cc: InterlispSites^
Reply-To: vanMelle

For those interested in Common Lisp:

In November, I attended a meeting about Common Lisp. Larry Masinter and I
have prepared a report on that meeting and on the Common Lisp effort more
generally, which can be found on
[PARC-MAXC]<NETLISP>COMLISP.REPORT.

Bill van Melle
17-JAN-82 13:38:27-PST,333;000000000001
Date: 17 JAN 1982 1338-PST
From: MASINTER
Subject: BQUOTE
To:   Goldman at ISIF
cc:   masinter, Lisp

I fixed BQUOTE's read macro not to say "FIRST". Since | was previously
a sepr, this should not affect existing files.

There are still a couple of outstanding problems with BQUOTE, but...

one thing at a time.

Larry
25-JAN-82 10:30:04-PST,755;000000000000
Date: 25 Jan 1982 10:28 PST
From: Masinter at PARC-MAXC
Subject: new COMP & .COM on <NEWLISP> fixing handling of constants
To: Lewis@BBND
cc: Lisp, Goldman@ISIB, Masinter

Daryle--

I went in to look at what was going on and wound up fixing the problem
in the PDP-10 compiler. It is now the case if you say

(CONSTANTS (VAL1 (PLUS 1 2))(VAL2 (STKNTH 0 T)]

that VAL1 will compile as 3, and compiling VAL2 will complain.

I think it could be fixed so that VAL2 would compile as if you had said
(CONSTANT (STKNTH 0 T)), but that would require even more major surgery.

I also fixed what appeared to be a bug in that there was a (CADR (QUOPP --))
in one of the functions which was obviously wrong (QUOPP not returning a
list). 

Larry
17-FEB-82 19:41:22-PST,308;000000000000
Date: 17 FEB 1982 1941-PST
From: KAPLAN
Subject: New I.S.OPRs:  largest and smallest
To:   LISP

Returns the value of I.V. that provides the greatest/smallest value of
the body form.  $$EXTREME is always bound to the current
greatest/smallest value, $$VAL to the value of I.V. from which it
came.

18-FEB-82 16:22:02-PST,562;000000000001
Date: 18 FEB 1982 1622-PST
From: KAPLAN
Subject: New definition format for FILEPKGCOMS
To:   LISP

The definition of a FILEPKGCOMS is now
a list of the form ((COM . props)(TYPE . props)), where
props are the various attributes of the name thought of as a
filepkg command or type.

Properties not mentioned are assumed to have NIL values.

This is the kind of object that GETDEF returns and that PUTDEF
accepts.

The functions FILEPKGCOM and FILEPKGTYPE allow for the setting
of individual properties without redefining the whole thing.

--Ron
24-FEB-82 23:14:58-PST,663;000000000000
Date: 24 FEB 1982 2314-PST
From: MASINTER.PA
Subject: (EOL CR), (EOL CRLF)
To:   LispCore^
cc:   lisp

I fixed it in Interlisp-10 so that the EOL mode is settable on
a per-file basis, as one of the MACHINE.DEPENDENT.PARAMETERS using
a (EOL type) element in the list. (I was in search of why I couldn't
load files directly from Phylum using PUPFTP, and it was because 
Interlisp-10 was trying to gobble a LF after a CR and gobbled too
much.)

Is there any good reason why Interlisp-D shouldn't support this too?
I imagine the EOL mode should be read/settable via GETFILEINFO, and
perhaps #EOLCHARS should be a GETFILEINFO parameter too...

Larry
 1-MAR-82 14:11:31-PST,1847;000000000000
Date: 1 Mar 1982 13:09 PST
From: Masinter at PARC-MAXC
Subject: Re: MAPHASH problems in Interlisp??
In-reply-to: KINI's message of 23 Feb 1982 1604-PST
To: Vittal Kini <KINI at USC-ISIB>
cc: InterlispSites^

(I'm cc:ing InterlispSites^ on the response because this problem is not widely
known.)

Vittal: 

(1) You have unfortunately run into one of the more subtle problems with
MAPHASH in Interlisp-10: if a garbage collection which MOVES STORAGE
occurs during the middle of a MAPHASH, it is possible for the hash
pointers to move around, and for entries to be missed and for some entries
to be visitied twice. This is the only situation in which MAPHASH will
omit items or present them twice (note that "rehashing" actually copies the
original array into another one, so that if a rehash occurs because of overflow,
you may get outdated information but not any duplicates.)

(2) The problem is that if a reclaim needs to increase the size of one of the
contiguous areas (such as array space or string pointer space), it may actually
move around pages of atoms. It isn't that atoms get compacted but rather that
other spaces have to increase which causes the atoms to get moved around.

(3) The way that I worked around this problem when I ran into it was
	(a) MAPHASH down the array, collecting a list of the "keys"
	(b) MAPC down that list, performing the operation

This guarantees that no string/array/pname garbage collection will occur during
MAPHASH.

There are some proposals for fixing this problem in Interlisp-10 (e.g., marking the
array that it is being maphashed, and if so marked, not rehashing during a
reclaim but fixing it the next puthash) but so far (for the last 4 years) no
progress on fixing it.

This bug is not present in other Interlisp implementations, as far as I know. 

Larry
 1-MAR-82 17:33:20-PST,714;000000000000
Mail-from: Arpanet host USC-ISIF rcvd at 1-MAR-82 1732-PST
Date:  1 Mar 1982 1732-PST
From: Steve Crocker <Crocker at USC-ISIF>
Subject: Re: MAPHASH problems in Interlisp??
To: Masinter at PARC-MAXC, KINI at USC-ISIB
cc: InterlispSites^ at PARC-MAXC
In-Reply-To: Your message of 1-Mar-82 1309-PST

An alternative strategy is not to use MAPHASH at all.  An auxiliary
list may be kept, suitably updated whenever items are added to or deleted
from the table.

If this sounds ridiculously expensive, I submit that it competes with the
proposed solution for some frequencies of MAPHASHing, adding, deleting and
accessing elements.

It would be interesting to see the crossover point.

Steve
-------
 2-MAR-82 15:58:11-PST,465;000000000000
Mail-from: Arpanet host USC-ISIB rcvd at 2-MAR-82 1557-PST
Date:  2 Mar 1982 1557-PST
From: Dave Dyer       <DDYER at USC-ISIB>
Subject: Re: MAPHASH problems in Interlisp??
To: Masinter at PARC-MAXC, KINI at USC-ISIB
cc: InterlispSites^ at PARC-MAXC
In-Reply-To: Your message of 1-Mar-82 1309-PST


 Interlisp-VAX shares exactly the same problem, except
that GC is much less frequent and therefore less likely to 
occur in a critical interval.
-------
15-APR-82 10:17:52-PST,1243;000000000001
Date: 15 Apr 1982 10:17 PST
From: Masinter at PARC-MAXC
Subject: WITH construct in record package
To: Lisp, LispCore^
cc: Goldman@ISIF, Masinter

This feature has been in the system for a while, but there were a few minor
problems which prevented me from advertising it. I fixed them a couple of
months ago:

(WITH <record-name> <record-instance> . <forms>)  	[special form]

The WITH construct can be used to talk about the fields of a record as if they
were variables within a lexical scope.  <record-name> is the name of a record,
and <record-instance> is an expression which evaluates to an instance of that
record. The expressions in <forms> are evaluated in a way where references to
variables which are field-names of <record-name> are implemented via
field-fetches and SETQs of those variables are implemented via
field-replacement. 

For example, given 
	(RECORD RECN (FLD1 FLD2))
	(SETQ INST (CREATE RECN FLD1 _ 10 FLD2 _ 20))

Then the construct

(with RECN INST
	(SETQ FLD2 (PLUS FLD1 FLD2]

is equivalent to
 (replace FLD2 of INST with (PLUS (fetch FLD1 of INST) (fetch FLD2 of INST]

Note that the substitution is lexical: this operates by actually doing a substitution
inside <forms>.

Larry
18-APR-82 16:19:24-PST,655;000000000000
Date: 18 APR 1982 1619-PST
From: MASINTER
Subject: Masterscope expanding macros
To:   Kaplan
cc:   lisp, masinter

I fixed it so that masterscope expands any macros of MSMACROPROPS,
initially = (MACROS). 

It works for OPENLAMBDA too (I think the PDP-10 compiler works
for OPENLAMBDA too). I moved the code for macro expansion to
the file MACROS (rather than DWIM). New entry

(MACROEXPANSION form macroprop)
     given the macro property "macroprop", MACROEXPANSION does
     the expansion.

(GETMACROPROP fn props)
     (maybe this should be renamed?) It actually just returns 
     the first property of "fn" out of props.

Larry
18-MAY-82 09:46:33-PDT,715;000000000000
Date: 18 May 1982 9:43 am PDT (Tuesday)
From: Sannella.PA
Subject: Interlisp Manual Revision -- request for comments
To: InterlispSites^
cc: LispDiscussion^, LispUsers^
reply-to: Sannella.PA@parc-maxc

Greetings!

We am working on a completely new version of the Interlisp reference
manual.  We are updating the text, rewriting and extending some of
the sections, changing the manual's overall organization, and reformatting
the entire manual. I am coordinating this effort.

If you (or any of your users) have online files of manual errors or other
material, I would greatly appreciate it you could send them to me. 

Thank you for your assistance.

Michael Sannella
<Sannella.pa@parc-maxc>

12-JUN-82 15:22:27-PDT,1243;000000000000
Date: 12 JUN 1982 1522-PDT
From: KAPLAN.PA
Subject: New FILEPKG command:  INITVARS
To:   lispcore^, lisp

I have added a new filepkg command to the system.  It is already
included in BYTE.SAV and ABC, and will appear in any D loadups made
Friday or after.

INITVARS is used for initializing variables--setting their values only
when they are currently NOBIND.  A variable value defined in an
INITVARS command will not clobber the current value.  This means that
re-loading files to work on some aspect will not change the variable values.

The format of an INITVARS command is just like VARS.  The only difference is
that atomic elements in the argument of the command will not cause the
current core value to be dumped; instead they will define NIL as the
initialization value.

Thus, (INITVARS FOO (FUM 2)) is the same as (INITVARS (FOO NIL)(FUM 2)).

INITVARS should be used instead of VARS for almost all variables in system
files.  It also should be used instead of (ADDVARS (FOO)) when the purpose
is merely to insure that the value is NIL.

INITVARS puts out an RPAQ? command on the file instead of RPAQ.  This is
a new function that I also added to the system, and which should also
be documented.

--Ron
13-JUN-82 23:12:15-PDT,1502;000000000001
Date: 13 June 1982 11:12 pm PDT (Sunday)
From: JonL.PA
Subject: Re: New FILEPKG command:  INITVARS;  also RPAQ? etc.
In-reply-to: KAPLAN's message of 12 JUN 1982 1522-PDT
To: KAPLAN
cc: lispcore^, lisp

One thing that has to be considered about this feature is how to load "patch"
files so that the INITVARS vars *do* get reset;  the LISPM people have some
trivial little thing to override the non-reSETting nature of a CommonLisp 
DEFVAR when a "patch" file is loaded, and I don't remember exactly how it
works, but I'm sure almost any little trick will do once the problem is faced.

Re RPAQ? (which looks equivalent to the MacLisp SETQ-IF-UNBOUND), I've
often wanted yet a third version of SETQ which does the setqing only if the
value is non-null (but returns the value obtained regardless).   See example
below.
I've also heard lots of other people complain about  Lisp's lack of "pronouns" a la
the "IT" of lispx;  SETQ-if-non-null catches some high percentages of these
cases.  Lack of "pronouns" means that you often see code like
       (IF (GET X 'FROBULATE) THEN (PRINT (GET X 'FROBULATE)))
where you'd like to write
       (IF (GET X 'FROBULATE) THEN (PRINT it))

Example use of SETQ-IF-VALUE-NON-NULL:
    (COND 
      ((SETQ.IFNN  WHATTODO  (FIND.MORE.WORK))
         (CARRYON.ANEW  WHATTODO))
      ((ASKUSER ...if I should just try "polishing-up" the old some more ...)
         (POLISHUP.OLD  WHATTODO))
      (T (GO AROUNDLOOP)))



             

22-JUN-82 20:58:20-PDT,462;000000000000
Date: 22 JUN 1982 2058-PDT
From: ROACH
Subject: PUTASSOC
To:   LISP

    In my prejudiced opinion, PUTASSOC should be able to take NIL for
its alst argument and should return the new alst as its value.  I have
written a similar function in MACLISP and quite often I build an alist
from scratch, i.e. NIL.  So long as PUTASSOC is used for effect, my semantics
is upwards compatible with Interlisp's.  It isn't too late to fix this guy.
				Kelly Roach
28-JUN-82 23:00:44-PDT,389;000000000000
Date: 28 JUN 1982 2300-PDT
From: KAPLAN.PA
Subject: New function:  FILECHANGES
To:   SANELLA, LISP

(FILECHANGES filename type) returns the list of changes in the
filecreated expression of filename.  If type is NIL, this will
be an alist whose elements are of the form (type . changes).
If type is a filepkgtype, then the value will be
just the changes (if any) for that type.

 2-JUL-82 23:05:39-PDT,205;000000000000
Date:  2 JUL 1982 2305-PDT
From: MASINTER.PA
Subject: little known feature in ? handling
To:   lisp, lispcore^

Just as ?= in typin prints out args of current function, 
?^ will attempt to PF it.

 4-JUL-82 15:43:27-PDT,5056;000000000000
Date:  4 JUL 1982 1543-PDT
From: MASINTER
Subject: Summary of Interlisp system changes
To:   Kaplan, Masinter, Lisp

Compatibility with other Interlisp implementations:

(SYSTEMTYPE)							[Function]
 Returns one of TOPS20, TENEX, D, JERICHO, VAX. Most implementations
have a compile-time optimization for (SELECTQ (SYSTEMTYPE) --)

(COMPILEMODE)							[Function]
	Returns one of PDP-10, D, JERICHO, VAX. For EVAL@COMPILE
    conditionalization. Not the same as SYSTEMTYPE to allow 
    cross-compilation.

COMPILE.EXT							[Variable]
	Be sure to reference compiled files via a PACKFILENAME with
	COMPILE.EXT rather than binding the ".COM" extension into your
	program.

	(the FILES file package command is another way of referencing
	files without explicitly naming compile-extension).

	e.g.,
	(LOAD (PACKFILENAME 'NAME FOO 'EXTENSION COMPILE.EXT]
	rather than (LOAD 'FOO.COM]

- - - - - - - - - - -
BQUOTE: 	A "BACKQUOTE" facility

This is similar to the facility of the same name in other common lisp dialects as
follows:

(BQUOTE FORM) is like  to (QUOTE FORM) except that, in the body
of FORM, an element preceded by a "," is evaluated, an element preceded by ",@"
is evaluated and spliced in using APPEND and an element preceded by ",." is
spliced in, using NCONC.

For example, (BQUOTE (A , B ,@ C D)) is equivalent to
	(CONS (QUOTE A)
		(CONS B (APPEND C (QUOTE (D].

As a shorthand, (BQUOTE form) can also be typed in as |'FORM. In this case,
the comma forms are automatically parsed without following them with spaces,
e.g., |'(A B ,C) reads in as (BQUOTE (A B , C)). This format is also recognized
on files. Vertical bar was chosen since it normally is treated as a separator in
files. 

Vertical-bar, both in typein and in files, has also been "overloaded" to introdoce
HPRINT-format expressions. This facility makes it possible, although not
particularly convenient, to type in circular lists and arbitrary other data
structures.
- - - - - - - -
ARRAY types expanded

The ARRAY function now accepts any
"type" which is legal in datatypes, and coerces it into the next "enclosing"
ARRAY type. Since the low-level system only allows arrays of type FIXP,  or POINTER,
 types are coerced. However, this allows programmers to specify more exactly
what they intend.


- - - - - - - - - - - - - - - - - - - - - -
Masterscope expands MACRO definitions

When it encounters a macro which has no template and is not otherwise defined
or is a NLAMBDA.

Masterscope only looks at MACRO properties (and not 10MACRO, DMACRO, etc.)
in the theory that the machine-dependent properties are more likely "optimizers".
Also, this avoids the problem of Masterscope having to worry about those
properties which are really part of the compiler, and which contain calls to
internal compiler functions.

------------------------------------------------------------
WITH construct in record package:

(WITH <record-name> <record-instance> . <forms>)  	[special form]

The WITH construct can be used to talk about the fields of a record as if they
were variables within a lexical scope.  <record-name> is the name of a record,
and <record-instance> is an expression which evaluates to an instance of that
record. The expressions in <forms> are evaluated in a way where references to
variables which are field-names of <record-name> are implemented via
field-fetches and SETQs of those variables are implemented via
field-replacement. 

For example, given 
	(RECORD RECN (FLD1 FLD2))
	(SETQ INST (CREATE RECN FLD1 _ 10 FLD2 _ 20))

Then the construct

(with RECN INST
	(SETQ FLD2 (PLUS FLD1 FLD2]

is equivalent to
 (replace FLD2 of INST with (PLUS (fetch FLD1 of INST) (fetch FLD2 of INST]

Note that the substitution is lexical: this operates by actually doing a substitution
inside <forms>.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
New FILEPKG command:  INITVARS

INITVARS is used for initializing variables--setting their values only when they
are currently NOBIND.  A variable value defined in an INITVARS command will
not clobber the current value.  This means that re-loading files to work on some
aspect will not change the variable values.

The format of an INITVARS command is just like VARS, except that the atomic
form does not make sense; all elements are lists (var defaultvalue).

INITVARS puts out a RPAQ? command on the file instead of RPAQ.  This is
a new function that has been added to the system in this release.  Hence,
INITVARS will not load into older releases.
- - - - - -
Change to FILE, FILECHANGES properties and FILECREATED expression on
files:

The file package now keeps better track of what changes are made to a file to
disambiguate from changes to items of different file package types. For example,
if you change the FOO record, the change will get posted in a (RECORDS --
FOO --) section. Changes to a FOO function will appear in a separate (FNS --
FOO --) section.
 4-JUL-82 15:47:27-PDT,795;000000000000
Date:  4 JUL 1982 1547-PDT
From: MASINTER
Subject: 10MACROS vs MACROS
To:   Lisp
cc:   kaplan, masinter

The Interlisp-10 compiler now looks at a list of properties for
macros; the list, COMPILERMACROPROPS, is initialized to (10MACROS MACROS).
This list is distinct from the list MACROPROPS, which are all "potential"
macro properties which should be saved by the (MACROS --) file package
command.

10MACRO should be used for macros only appropriate for Interlisp-10.
(Interlisp-D has DMACRO, Interlisp-Jericho has JMACRO and Interlisp-VAX
has VAXMACRO.) MACRO should be used for "implementation independent"
macros.

System facilities for dealing with macros (e.g., EXPANDMACRO, MACROTRAN,
MASTERSCOPE, etc.) have been upgraded to deal with the multiple
macro properties.

 4-JUL-82 15:49:38-PDT,239;000000000000
Date:  4 JUL 1982 1549-PDT
From: MASINTER
Subject: lispx feature remoed
To:   Lisp

The facility where, after the user typed a single ? on a line
and waited for a while, and then the system responded "beats me"
has been removed.

 4-JUL-82 15:50:52-PDT,243;000000000000
Date:  4 JUL 1982 1550-PDT
From: MASINTER
Subject: CLISPIFYENGLISH removed
To:   lisp

The system will no longer attempt to turn Lisp into Clisp-English,
even if CLISPIFYENGLSHFLG is T.

DWIMIFY of clisp-english is still supported.

 4-JUL-82 15:51:49-PDT,204;000000000000
Date:  4 JUL 1982 1551-PDT
From: MASINTER
Subject: ARRAYORIG
To:   lisp

A dummy "ARRAYORIG" function supplied which in Interlisp-10 returns 1.
The ORIG argument as supplied to ARRAY originally.

 4-JUL-82 15:48:04,81;000000000001
Date: SUN  4 JUL 82 15:48
From: reminder
Subject: bug in EXPT fixed 28-Dec-81
14-JUL-82 04:39:35-PDT,802;000000000000
Date: 14 JUL 1982 0438-PDT
From: MASINTER.PA
Subject: CLEARCLISPARRAY
To:   lisp
cc:   lispsupport

(CLEARCLISPARRAY name - -)			[Function]

Clears the clisp translation for all forms beginning with "name".
(In interpreted definitions only, and only if CLISPARRAY translation
feature has not been disabled.)

CLEARCLISPARRAY is used as the file package WHENCHANGED function
for the type MACROS, so that when a macro is edited or redefined,
the "cache" of its macro translation will be discarded.

Sometimes, a macro translation can depend on more than merely
the body of the macro, and the user may want to call CLEARCLISPARRAY
directly. For example, if a computed macro calls a function,
and the function is edited, the system currently does not know
enough to clear the array.

16-JUL-82 22:52:30-PDT,659;000000000000
Date: 16 JUL 1982 2252-PDT
From: KAPLAN.PA
Subject: Property list of NIL
To:   MASINTER, SANELLA, LISP

Date: 16 JUL 1982 1555-PDT
From: ROACH
Subject: PROPERTIES
To:   KAPLAN

     The way section 7 of the manual starts, any litatom can have a 
property list.  When you read the fine print, you see that NIL's property
list can never be anything but NIL.  You can GETPROP and REMPROP from
NIL and you can even (SETPROPLIST NIL NIL).  Why not be honest and admit
that because of the way NIL is implemented, NIL does not have a property
list?
				Kelly



Why is it that NIL has a NIL property list.  Doesn't seem
at all necessary to me.
18-JUL-82 17:06:32-PDT,167;000000000000
Date: 18 JUL 1982 1706-PDT
From: KAPLAN
Subject: IMPORT is now an option for the FILES command and FILESLOAD function
To:   LISP

It means to call CHECKIMPORTS.
20-JUL-82 22:47:44-PDT,562;000000000000
Date: 20 Jul 1982 22:47 PDT
From: Masinter at PARC-MAXC
Subject: CLISPIFY of ENGLISH
To: Raim.EOS
cc: Lisp, VANBUER@USC-ECL, Masinter

The ability to CLISPIFY code and produce 'english' has been removed as one of
the 'standard' packages in Interlisp. It is now available as a separately loadable
file CLISPENG. The source for this file is on [parc-maxc]<lisp> (although it may
move to <lispusers>, please check there). I don't know if I have an Interlisp-D
version of a compiled file, but it is simple enough to BCOMPL in a default
feature.

Larry
 8-AUG-82 23:46:57-PDT,213;000000000000
Date:  8 AUG 1982 2345-PDT
From: KAPLAN.PA
Subject: PRINTDEF, CHANGEFONT now have an additional FILE argument
To:   LISPCORE^
cc:   SANELLA, LISP

This required a change to OUTPUTDSP in LLDISPLAY.

--Ron
