problem type: Performance
Subject: Want faster GETPROP
subsystem: microcode

GETPROP could be open coded faster. It is time-critical for a number of user functions. GETPROP would be faster if PUTPROP put new properties on the front of symbols PList instead of the back.

---------------------
subsystem: microcode

TYPENAME is too slow, and is used by TYPENAMEP. Want primitive in microcode which is JNTYPENAMEP [alpha, beta, offset], like DTEST except jumps instead of traps if type doesn't match.

---------------------
subsystem: compiler

Some of the initial constants and global variables can now be expanded inline for faster execution. Do stats on system, and look at GLOBALVAR references of functions which show up in profile.

******************
Date: 12 Feb. 1982 8:53 am PST (Friday)
From: Moran.PA
Subject: CLOSEF problem


CLOSEF doesn't seem to work on the Dolphin in functions that work perfectly
well on Maxc.  My style is the following:

	(LAMBDA (F)...(OUTFILE F)...(PRINTOUT NIL...)...(CLOSEF F)...)

When it gets to CLOSEF, it says that file val-of-F is not open.  However, calling CLOSEALL in the break does close file val-of-F, which really was open and which did indeed get all the printout intended.

Tom
------------------------------------------------------------

Date: 1 March 1982 7:20 pm PST (Monday)
From: Bobrow.PA

The compiler seems to me to be much too verbose.  Cannot there be a flag so that

it only says things when either a) there is a free variable b) an undefined function called

Currently I scan my dribble file for these, which are most useful.  But so little wheat and so much chaff.

***************
Date: 19 March 1982 9:59 am PST (Friday)
From: VanLehn.PA
Subject: HELPFLG bug
To: Lispbug^.pa
cc:  VanLehn
Reply-To: VanLehn

LISPX seems to be rebinding HELPFLG so that SETQ's at top level have no effect.  I can't force errors to break by setting it to BREAK!, which makes debugging under errorsets damn near impossible.

Kurt

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

Date: 19 Mar 1982 1006-PST
From: Neil Goldman <GOLDMAN at USC-ISIF>
Subject: CONSTANT
To: MASINTER at PARC-MAXC

In the macro for CONSTANT, I propose that the evaluation of the form be done under ERRORSET protection, with an error causing the thing to be treated as a DEFERREDCONSTANT, just as is done when the value fails to pass the CONSTANTOK test.

neil
 ********************
Subject: SEPRCASE/GETBRK bug
To:   LispCore^
If a character X is defined as a macro in readtable Y, then (SYNTAXP X 'BREAK Y) is NIL, but X is not in (GETBRK Y).  I don't know whether this is a bug or
a feature, but in any case it means that SEPRCASE treats such a char as an alphabetic, and FINDCALLERS and friends will miss when the target atom is preceded by the macro character.

*******************
Date: 8 Apr 1982 1932-PST
Subject: SPECVARS and the compiler.
From: RBATES at USC-ISIB

The manual on page 18.21 states "Whenever bcompl or brecompile encounter a block declaration they rebind retfns, specvars ... to their top level value".  This is NOT true as far as SPECVARS are concerned.  The reason is the function LOCALVARS in COMP seeing that LOCALVARS are T sets SPECVARS to SYSSPECVARS without checking what the current value of SPECVARS is.  This bug has been around since Sept 1976!  These two functions with the coms show off the bug:

(FOO (LAMBDA NIL (PROG (X) (FUM]
(FUM (LAMBDA NIL (NILL X)]
(SETQ BUGCOMS '((FNS FOO FUM)
		(SPECVARS X)
		(BLOCK (FOOBLOCK FOO FUM (ENTRIES FOO]
/Ray
*************
Date: 19 Apr 1982 0956-PST
Subject: DECLARE:
From: RBATES at USC-ISIB

I noticed that DECLARE: don't get compiled away (the function DECLARE: always get called), but DECLARE does get compiled away. This problem has been around awhile.  Also that the example on the end of page 23.16:
	
(FOR X IN Y (DECLARE: (LOCALVARS X)) -- )
	
doesn't work.

/Ray
********************

Date: 19 MAY 1982 1535-PDT
From: KAPLAN
Subject: \TAKEINTERRUPT skeleton on AINTERRUPT

I defined a skeleton for the \TAKEINTERRUPT macro on AINTERRUPT.

It has dummy calls to 2 primitives, one for checking whether \INTERRUPTABLE
is T everywhere above its lowest binding (which is predictably NIL by the
client of \TAKEINTERRUPT).  I can simulate this with a stack
search using a constant stack pointer, but this probably
should be done at a lower level.

The other is a function for calling INTERRUPTED (I called it
\CALLINTERRUPT).  I don't think this can be the same as \CAUSEINTERRUPT.
Maybe it is sufficient simply to branch to the keyboard context here.

I noticed that there are 2 global variables used mark that an
interrupt is pending, \InterruptChar (used in the keyboard handler) and
\INTCHAR, used in INTERRUPTED.  \CAUSEINTERRUPT clears \InterruptChar
and sets \INTCHAR.  I don't quite understand this--is it temporary cause
we haven't committed to WIND?

--Ron
*****************
Date: 28 MAY 1982 0003-PDT
From: KAPLAN
Subject: Bug in BCOMPL/BRECOPILE
To:   MASINTER

I noticed that BRECOMPILE and BCOMPL setup LOCALVARS slightly differently.

BCOMPL initializes it to SYSLOCALVARS.  BRECOMPILE does that only if
LOCALVARS is T.  If it is not T, it sets it to (UNION SYSLOCALVARS LOCALVARS).

Do you understand this?  Which is correct, or are both correct?

If the UNION makes sense, should it also happen for SPECVARS?

--Ron
*****************
Date: 15 JUN 1982 2210-PDT
From: MASINTER.PA
Subject: INSPECT scrolling
To:   lispsupport

If you put up an inspect window, and then change radix (e.g., from RADIX(8) to RADIX(10)), you get inconsistant output when you scroll the window.

Larry
*****************
We need to have an updated suite of tests to give to the technicians for hardware checkout. 

Date: 18 June 1982 9:18 am PDT (Friday)
FROM: MANN
Subject:Runmicrotest.cm/replacement                    

Can you send us a message about Runmicrotest.cm or a suitable replacement to
use in checking out the Dorado's as we discussed the other day. We do need this to do a good verification that the machines we ship run all the
emulators.
*****************
Interlisp-D I believe has never been verified to run the DIsrael Y-FUN test of spaghetti stack operation.

Date: 23 Jun 1982 1332-EDT
From: DISRAEL at BBNG
To: masinter at PARC-MAXC

(1) YY2 is the Interlisp version of the standard fixed point
(recursion) operator in the lambda calculus.  As written in lambda
calculus form, it looks like this: LAMBDA F. (LAMBDA X. F (X X))
(LAMBDA X. F (X X)).  You apply it to a functional - a function that
returns a function as value - and then apply the result to, say a
number. So if you give YY2 the factorial functional  - everyone's
favorite example : LAMBDA FUN. (LAMBDA N. IF N = 0, 1, ELSE TIMES N 
(FUN N-1)) - you get something which when applied to 3 yields 6. It
does this bit of magic by unwinding an internal lambda expression 4
times (in this case). So it simulates recursion by as much iteration as
you need.  Note: the definition of FACTFUN is not syntactically
recursive, and if one defines FACT as (YY2 'FACTFUN), then FACT is also
not recursively defined.

One can actually think of YY2 (never mind why it's called that and not
Y) as the limit (the least fixed point) of an infinite series, starting
with Y-0 (which see) and getting on by applying Yn to G to get Yn+1.  
(Moreover Yn = (G 'Yn) - so every Y is a fixed point of G).

Z is another, slightly unstandard recursion operator - written in lambda
calculus form as follows: LAMBDA F. ((LAMBDA X. F (LAMBDA Z. (X X) Z)) 
(LAMBDA X. F (LAMBDA Z. (X X) Z)).  Again Z of FACTFUN is a
non-recursively defined FACTORIAL applicable to numbers.

(3) As for COMBOY - it's the Y-type recursion operator written out
purely in terms of the two (so-called) primitive combinators. K (LAMBDA
X. (LAMBDA Y. X)) and S (LAMBDA X. (LAMBDA Y. (LAMBDA Z. ((X Z) (Y
Z))))).  But there is a bug in the code: as it stands, it is not
applicable to numbers - only to functions; e.g. not to 3 but to
LAMBDA.() 3 -  and of course TIMES, SUB1, etc. barf at these.

(4) Speaking of combinators; BB is functional composition (in
disguise), SKIAPPLY is function application and SKIAPPLY2 is "APPLY" - 
again in disguise.  (It takes a function and an arg as arguments;
SKIAPPLY takes a function and returns a function which is the argument
function to SKIAPPLY primed for application.  (Baroque, eh??).  WW
takes a function and produces a function which when applied to an
argument, produces a version of a two-placed function whose two
arguments are identified.  (So  SQUARE is WW applied to TIMES.)

(5) F and J are weird functionals of purely theoretical interest
(unlike the others which are, as you'll surely allow, of immense
practical import).  J is a function provably equal to I (LAMBDA X. X);
but which is, unlike I, provably non-normalizable.  I, moreover, is
provably the only fixed point of F.  (I think J, like COMBOY, may
require functions as arguments all the way down.) 


To TEST:

(APPLY* (YY2 'FACTFUN) 3) will do nicely to compute (factorial 3).  (The
same goes for (APPLY* (Z 'FACTFUN) 3).)  You can go (APPLY* (FACTFUN 'FACTORIAL) 3) - where FACTORIAL is the regular recursively defined factorial function.  And, since YY2 (or Z) are fixed point operators (so F = YF) you can go (APPLY* (APPLY* 'FACTFUN (YY2 'FACTFUN)) 3).  ETC...

**************
Date: 27 June 1982 5:53 pm PDT (Sunday)
From: vanMelle.PA
Subject: incompatible changes

incompatible changes for whenever we feel like introducing an incompatible change:

Rearrange InterfacePage so that IFPFaultHi is even-aligned.

Rearrange DataTypeDescriptors so that DTDFREE, DTDCNT0 and DTDNEXTPAGE are all in the same quadword.

Make htfind xor the hiloc of the datum when computing the hash probe.

**************
Date: 30 JUN 1982 0755-PDT
From: SPROULL
Subject: Dolphin experience

[This was a long report on Bob's experience with the Dolphin. I have exerpted the problems which I think are still relevant]

- - - - - - - - - - - - - - - - - - - -
The bad news

My view is that Interlisp is sinking of its own weight, and the
move onto a personal computer has shown the hulk in alarming
vividness. This section presents a brief justification of this view
and offers possibilities for remedies. The problem can be fixed,
but it may be costly.

The problem, as I see it, is that Interlisp has never had a clean
internal structure of the system (as separate from the language):
features and packages have accreted, wired into the existing maze
to create a tighter maze. It's now so bad that a good programmer
who encounters an Interlisp system is at a loss for what to do for
a good long time. Few if any of the "interfaces" in Interlisp
correspond to things he recognizes from other environments. He has
to seek out facilities one by one; his intuition for where to look
is often wrong; and he remains worried about deep interactions
among various parts of the system.

This problem has been made worse by the move onto a personal
computer. I think to a great extent, new facilities are added to Interlisp
using the same rather low standards of interface definition that
have characterized Interlisp so far. For example, while I think the
facilities provided by the Interlisp-D stuff for graphics are
mostly OK, the interfaces can be substantially improved.

I feel the "system" part of Interlisp needs a thorough overhaul. I
favor the "open system" approach in which a very few low-level
primitives are built in, and the rest is done with packages that
can be separated and that have well-defined interfaces.

I realize that an undertaking such as this is a big one. However, I
believe that a great deal of the detailed functionality of
Interlisp can be retained (even much of the code can be retained),
but the interfaces need to be redesigned in light of the tremendous
evolution of the system. It's remarkable that they've remained
useful as long as they have, but they need overhaul. I see two
hopeful signs:

       1. To the extent possible, new work should be done in the
       form of LISPUSERS packages. I'm delighted, for example, to
       see the new editor done in this way. (But I suspect the
       interface between it and the rest of the system could be
       improved if the system were improved.) I think it's
       important that some (perhaps all) of these packages be
       distributed in source-file form so that users can actually
       understand what they do.

       2. The new Common Lisp effort is an opportunity to redesign
       many of these functions. Perhaps a long-range plan might be
       to put Common Lisp up on the Dolphin. Should the Xerox group
       be contributing to the design of Common Lisp, especially in
       those areas where it has the most expertise (e.g., user
       I/O)?

Another approach is to invest some effort in restructuring
Interlisp. I think it might be worth a few days' effort to estimate
the difficulty of this problem and the improvements that could be
reasonably expected.

(long paragraph)

       To summarize, I'd like a complete, consistent "graphics
       package" at the low level. Some of the pieces are there
       (bitblt, line, etc.), but I don't see the structure. It
       appears to be a complex set of stuff with complex
       inter-relations. There is no clear description of what a
       bitmap is, or what a display stream is, or what a window is.
       This needs to be cleaned up.

       More to the present point, however, is that I find the
       manual almost completely lacking is discussion of concepts.
       To pick an example from the current manual, consider the
       file package. What is a "file" from the point of view of
       Lisp? What is its purpose? What does it contain? What is the
       distinction between what is remembered inside the Lisp
       virtual memory and what is retained on the disk? And so on
       and on . . .  While the file package might have once started
       out so simple that none of these questions arose, it's long
       past that point now.

       The new graphics stuff definitely needs a good deal such
       concept documentation. In the manual, old and new, there's
       too much emphasis on functions and not enough on structure
       and concepts.

       The best manual would result from a system restructuring
       The Interlisp language should form a distinct part of the
       manual -- some sections
       of the current manual are salvageable in this respect. If
       the interface between the language and the packages were
       cleaned up, this section would describe the interface. I,
       for one, would benefit enormously from a self-contained
       section that describes the language without reference to any
       of the system stuff.


***********
Date: 8 July 1982 8:25 am PDT (Thursday)
From: VanLehn.PA
Subject: main data space overflow
....
I've tried to find the storage leaks using COUNTDOWN, MAPATOMS and
so forth.  So far, the only circularities I've come across are on LISPXHISTORY.  I need better leak-finding tools.  One would be to do the mark & sweep part of garbage collection, including the freelist as "accessible"  during the mark.  The list that the sweep delivers is therefore all the cons cells that got leaked.  By looking through the ones with atomic cars and cdrs, I could probably figure out from the pnames where the leaks came from.  

4.	Of course, having found all the lost storage, it could be put back on the freelist, saving me a reload (but probably still taking 20 minutes).  Since there is plenty of array space around, the mark & sweep could be written simply, using its own array to hold the mark bits.  I don't see any reason to do the "copy" part of a "stop & copy" since swapping doesn't seem to be a problem on the Dorado (according to temporal intuition and control T).     

5.	If the mark's bit array is the screen bitmap, one could probably learn alot about the storage use and maybe the chronology of the leaks by seeing not only where in vmem the leaks are, but watching the mark propagate out from specific atoms.  A quick calculation has it that marking the current Mds, assuming it's mostly cons cells (95% in my program), would take a 900 by 900 bitmap.

I'd be willing to help code such a tool, or any other.
    
Any tools or diagnostic ideas would be welcomed with extreme enthusiasm.
------------------------------------------------------------
Date:  8 JUL 1982 1155-PDT
From: ROACH.PA
Subject: DEFINEQ and MACROs
To:   LISPSUPPORT
cc:   ROACH


Dear Interlisp Support,

     I think MACROs, DEFINEQ, and the Interlisp compiler interact
incorrectly.  I would like to define macros such as DEFEXPR, DEFFEXPR,
etc. that can appear in files and will expand out into DEFINEQ forms
which go on to be compiled like other DEFINEQ forms.  I've been told
by Ronald Kaplan that this won't work, and in fact, it doesn't.  What
is Interlisp's problem?  I might point out that Maclisp does allow you
to do this sort of thing.  This is a pretty serious deficiency on
Interlisp's part.
     Secondly, instead of compiling expressions in the order in which
they occur, the Interlisp compiler gathers functions definitions into a
separate group from all other expressions.  This is also a bug.  (Again
Maclisp does the right thing.)  Compiled forms ought to load in the
same order in which the uncompiled forms loaded.
     I am hopeful that action will be taken on these problems.
****************
Date: 27 JUL 1982 0935-PDT
From: KAPLAN.PA

. . .

We probably also ought to implement a device info interface that could,
for example, tell how many pages are left on the disk, in an ifs directory,
or in the ifs as a whole.

*****************
00348 00024 UU 
Date: 10 Aug. 1982 8:48 am PDT (Tuesday)
From: VanLehn.PA
Subject: MARKASCHANGED
To: lispsupport
cc:  VanLehn

MARKASCHANGED apparently doesn't inform the compiler that the function
needs to be compiled.  Reference manual doesn't specify whether it does or not. Obviously, it should tell the compiler to recompile.  

*****************
Date: 26-AUG-82 11:46:38 PST
Subject: AWFUL CODE FROM CREATE USING
To: LispSupport


(create FOO using X) when FOO is a RECORD translates as a forest of CONS of 
CARs of CDRs rather than COPY.  Produces awfully large chunks of code that
doesn't even run fast.  Bug?

*****************
------------------------------------------------------------
Date:  8-Sep-82 14:03:40 PDT (Wednesday)
From: Masinter.PA
Subject: Re: RAISE for files

Users want to be able to read a file in lower case as if it were in upper case.

Why don't we put a translation table into READ tables? We already have them for FILEPOS and FFILEPOS etc. This would make a lot of sense. The cost is relatively small.
------------------------------------------------------------
Date:  9-Sep-82 16:18:21 PDT (Thursday)
From: Masinter.PA
Subject: RESETLST vs RESETFORM
To: Bobrow
cc: LispSupport, Masinter.PA

This should be in the manual, or maybe we should fix RESETFORM.

Example: this doesn't work:
(RESETFORM (DEFPRINT 'A 'FOO) stuff)

This is what DOES work:

(RESETLST (RESETSAVE NIL (LIST 'DEFPRINT 'A (DEFPRINT 'A 'FOO)))
	   stuff)
**********************

Date: 10-Sep-82  8:48:59 PDT (Friday)

There sentiment for making TY not elide comments

Date: 14 Sept. 1982 9:41 am PDT (Tuesday)
From: JonL.pa

I've never used TY, but if it does the obvious thing, then one might
expect that TY* would be the command which doesn't elide comments
(e.g., PF and PF*?)
**********************

We need to have an inbound CHAT server so you can CHAT to a machine from a remote terminal over the PUP and NS Ethernet.

We need to handle UNIX filenames better
We need device synonyms and pseudo-devices
We need to be able to delete 1100 {DSK} files without building the whole map

We need to document the facilities for doing Binary i/o for bitmaps, integers, floats.  AOUT/AIN.

Compiler: [14 NOV 1981 1815-PST]  (FUNCTION (LAMBDA --)) expression used
as a value to be stored into a record slot.  The compiler did produce a suitable subfunction, but then compiled as the value of the (FUNCTION --) expression the free varaible NEWVALUE.

We need to fix Sandbarring

Storage management:
   We need to fix the GC so that it collects items which are only held as keys of hash-tables. (CLISPARRAY in particular).

we need unwindprotect

many system functions have Names which can conflicts with user fns

We need to unify the handling of meta, blank keys

we need to clean up GLOBALVARS situation

We need more diagnostics and system tests

We need to fix it so that expanding macros doesn't take so long

* FUNARG  doesn't work
* MASTERSCOPE:
	WHO USES FILE FREE causes funny error messages

----------------------------------------------------------------
Date: 16 SEP 1982 1802-PDT
From: BURTON.PA
Subject: compiler bug

The bind merge optimzation getts carried away with the function
DSPDESTINATION on <LISPCORE>WIND>LLDISPLAY and binds the variable
\INTERRUPTABLE with the variable DS.  The effect is that the 
\DTEST is called in a context that is uninterruptable leading to
a call to RAID when DSPDESTINATION is given a bad argument such as
(DSPDESTINATION 123 (DSPCREATE)).

----------------------------------------------------------------
Date: 20 SEP 1982 1954-PDT
From: SHEIL.PA
Subject: Compiler bug - EVERY

Attempting to compile the expression (EVERY xxx (FUNCTION ATOM)) generates the
compiler warning message (ATOM: Too many args for macro). Code seems to be OK
but the message is distracting, especially if the code has come from a type?
from either a record or DECLtype.

Beau
----------------------------------------------------------------
Date: 24-Sep-82  8:47:08 PDT (Friday)
From: Masinter.PA
Subject: Re: Problem with open leaf files -- and patch
In-reply-to: BOBROW's message of 21 SEP 1982 1517-PDT
To: LISPSUPPORT
cc: Bobrow, Stefik

Danny's patch to FINDOPENFILE seems to get around the immediate problem,
but some more permanent fixes are needed. Ron and I talked about these
problems for a while; I thought I would send out some notes on our
conversation and some additional thoughts.

There are currently three separate problem areas in the current system:

a) 	READ/PRINT given file names which are not fully qualified scans the directory every time, which is TERRIBLY SLOW
b) 	for LEAF files, the file CANNOT BE FOUND by INFILEP/OUTFILEP/FINDFILE if it is already open
c) 	There are a number of inconsistancies having to do with the use of DIRECTORIES and the error mechanism to implement search paths.

Proposals:
a) 	files which are presented to READ/PRINT (i.e., in a context
	where an OPEN file is required) will ONLY scan against the set
	of files which are open with appropriate access.
	
	This is a change from Interlisp-10 semantics, where if you
	do an INFILE(FOO), and then create a NEW VERSION of FOO, and
	then do READ(FOO), you will get a FILE NOT OPEN error.

b) 	we should implement the notion of a "search path" device, e.g.
	{LISPUSERS} and {SOURCES}. The system will support assigning
	search paths to a device (new function), so that one can say
	{SOURCES} = {PHYLUM}<LISPCORE>WIND> , {PHYLUM}<LISPCORE>SOURCES>

	Doing an INFILEP on {SOURCES}xxxx will return a full filename
	of {PHYLUM}<LISPCORE>WIND>xxxx, i.e., the name returned will
	be fully qualified. OUTFILE on {SOURCES} will write on the
	FIRST directory on the search path.

	The general idea here is to take what is currently done via
	the error mechanism and DIRECTORIES and FINDFILE and instead
	build it in in at a lower level. This will allow some more
	rational implementations of the facilities.

	It will also make more logical the link between the "connected"
	directory and the search path; that is, one can either 
	connect to {SOURCES} or to {WIND} or to {LISPUSERS}. It will remove
	the distinction between FINDFILE and INFILEP in the
	non-spelling-correction case.


	Finally, all of this is relatively easily implemented in
	Interlisp-10! Interlisp-10 already supports a (undocumented)
	feature where if you PUTPROP(LISPUSERS DIRECTORIES (<LISPUSERS> <LISP>))
	and attempt to FINDFILE(LISPUSERS:filename), it will in fact
	search those directories.

Comments?
-------------------------
Date: 24-Sep-82  8:49:48 PDT (Friday)
From: Masinter.PA
Subject: Re: Bitmap editor
In-reply-to: SHEIL's message of 21 SEP 1982 1603-PDT
To: SHEIL
cc: burton, lispsupport

I always wanted to do EDITBM on a "window".

One general way of handling this is to have a general "coersion" function
which coerces to "clipped bitmap", with the relatively obvious coersions for
windows/displaystreams/bitmaps/regions....

----------------------
Date: 24 Sep 1982 1538-PDT
From: Friedland
Subject: interlisp d bug
To:   cschmidt, rindfleisch

renamefile on {DSK} doesn't work.  If you have a file
A 100 pages long and a file B 200 pages long and (RENAMEFILE A B), you
end up with a file B 200 pages long, its first 100 being the old A 
and the last 200 being garbage from the old B.  You have to
(DEFILE B) before the renamefile.  This despite what the manual says.

PEter
-----------------------------
Date: 29 SEP 1982 2012-PDT
From: JONL.PA
Subject: Undefined Function

Once in a while, I mistype a DEFINEQ, and wind up with an s-expression
in the definition cell of some litatom which is *almost* what I wanted -- it just lacks the word LAMBDA.  The error message you get when you try to run
such a function is "Undefined Function" -- wouldn't it be better to
reserve that msg for the case of a definition cell which is either NIL or
NOBIND, and print something more informative for the case where it contains
something like ((X) (LIST X (TIMES 2 X)), or (() (PRINT 5)).
----------------------
Date: 29 SEP 1982 2016-PDT
From: JONL.PA
Subject: PUNTing a broken compilation
To:   lispbug^

1) There needs to be an advertised way to do a BCOMPL which ignores errors
  which occur during the compilation of a single funciton, so that a single
  call to BCOMPL will proceed thru the while file, finding perhaps other
  errors before ending.
2) I tried the unadvertised function (PUNT) after one of my macros caused
  a BREAK during compilation, and it appeared as though the then-current
  break window became the normal TTY display stream.
-----------------------------
Date: 30 SEP 1982 1119-PDT
From: SHEIL.PA
Subject: two comments on the RESETFORM macro

Currently, the RESETFORM macro evaluates the resetform (a) outside of errorset
protection and (b) some time (during which an interrupt can occur) before the
resetlst entry for undoing it is made. This could be disasterous if one is 
resetting, for example, a display stream clipping region and the user bombed
you out. [(a) may or may not be a bug or non-feature, depending on how one
reads the manual; (b) is nasty to fix and probably requires interrupt protection]

Also, the RESETFORM macro doesnt do a very good job if one passes it a LAMBDA
expression as the reset function (two copies wind up in the compiled code).
[The motivation for this is for two arg fns like DSPCLIPPINREGION, as
	(RESETFORM ((LAMBDA (X) (DSPCLIPPINGREGION X window)) NEWREG)
		forms)
is much more elegant than
	(RESETLST (RESETSAVE NIL (LIST 'DSPCLIPPINGREGION
					(DSCLIPPINGREGION NEWREG window)
					window))
		forms)
In fact, since I just realized that, it might be worth noting this trick in the
manual for other slow thinkers.]

*** I really want to shift to this notation in DEDIT, so this patch would be
greatly appreciated ***

Beau

PS: From a slightly broader point of view, it would be nice to have a wizard
scrutinize these macros as (a) this is not the first non-feature report for
them (b) they dont look to be as good code as they could be. Last time I
raised this, the discussion quickly expanded to include respecifying the
whole error handling machinery (and thus nothing happened). Perhaps a useful
intermediate step would be to define a few more useful abstractions, such
as CATCH and THROW, which we could start using in our code to replace the
convoluted RESETLST constructions that tend to generate these discussions in
the first place.

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

Date:  1 OCT 1982 1430-PDT
From: SHEIL.PA
Subject: Glitch in RENAME
To:   LISPSUPPORT

If one has a variable FOO which is used in some file BAR and you wish to rename
it to FUM, (RENAME 'FOO 'FUM 'VARS 'BAR) will bomb with complaint "no VARS defn
for FOO" unless FOO has a top level binding.

Beau
*********************
00705 00024 UU 
Date:  1 OCT 1982 1611-PDT
From: SHEIL.PA
Subject: PP and PRETTYPRINT glitches
To:   LISPSUPPORT

Some time ago, PP (and PP* and PPT) had LOCALVARS declarations added so that their variables would not interfere with EVALVs from PRETTYPRINT. Unfortunately, the ERRORSET implementation causes all these to be SPECIAL in Interlisp-D anyway. Pending a more general resolution of this problem, it would be nice if these fns were patched to avoid the fact that (PP X) for example, does absolutely nothing. [Major motivation: This is irritating if you know what is going on but absolutely inexplicable if you dont]. 

Manual note: ARGLIST of PRETTYPRINT does not match manual spec.
*********************
Date:  3-Oct-82 21:05:18 PDT (Sunday)
From: Masinter.PA
Subject: Re: PP and PRETTYPRINT glitches
In-reply-to: SHEIL's message of 1 OCT 1982 1611-PDT
To: SHEIL
cc: LISPSUPPORT

An additional (more general) fix is for the compiler to rename the variables which are auto-SPECVARed because of the ERRORSET hack.
*********************
Date:  3 OCT 1982 2327-PDT
From: KAPLAN.PA
Subject: Clispify/dwimify bug

If (don't ask why) the atoms < and > have top-level values, then
CLISPIFY((LIST (FOO))) is (< (FOO) >) which then doesn't dwimify
back.

As a minimum, this (and all) clisp transformations should not be
performed in environments where they won't dwimify properly.

*********************
Date:  4 OCT 1982 0514-PDT
From: JONL.PA
Subject: MASTERSCOPE Message

If you edit a macro, MasterScope will correctly tell you that
certain functions depend upon it;  but when calling UNSAVEFNS,
it always prints the message "Loading FooFunction", regardles
wof whether it is really loading it, or merely UNSAVEDEFing it.
*********************
Date: 4 Oct. 1982 8:26 am PDT (Monday)
From: Stefik.PA
Subject: Re: Interlisp-D planning

Larry and Bill, - 

	The Lisp features {desired by Mark et al.) were

(1)	Ability to have functions without naming them.
(2)	Ability to hash on strings (or unintered atoms?) for our LOOPS uids.
(3) 	Access to an efficient (say B-tree) database (perhaps cedar?).

Of more immediate importance will be some participation by yous guys in design
reviews of LOOPS, and consulting on performance tuning.  Mark

*********************
Subject: lisp.tasks
* UNBREAK work on internal block functions just like TRACE
* DUMMYFRAMEP definition correction
* compiler optimization NEWOPTFLG=T
* free code deleterefs pointers therefrom

Interlisp-10 problems
* DELFILE BUG
* GETSTREAM
* CALLSCCODE returns duplicate values
* add ALLOCSTRING
* make NCREATE allocate system datatypes too

Date: 6 Oct. 1982 9:44 am PDT (Wednesday)
From: Bobrow.PA
Subject: Re: Interlisp-D planning
In-reply-to: Masinter's message of 5-Oct-82 19:45:57 PDT (Tuesday)
To: Masinter
cc: Stefik, Bobrow, vanMelle

1) Must function call always go through an atom?  Perhaps the name slot on the
stack could be made in the "naked" case to point to the fn data object.  Inspect
macros might allow at least finding out about arguments expected.
One might even have a string in such an object to name it (this would work for
our methods).

2)  The current atom hash table code made available as string hashing would do
quite nicely at this stage for us, I think.  More than 2^16 atoms would be nice,
but is not right, since we want separate name spaces with overlapping names,
and I don't think we need anything but string hashing.  

3) Eventually we might want to use file based indexes for knowledge bases (e.g.
BTrees) when they get too large.  The current Alpine project is NOT planning to
provide a BTree index interface at the moment (I checked with Mark Brown) 
Most of the indexing stuff is done now on the clients side of the Cedar database.

Stats runs show that our GetValue and PutValue are remarkably slow (about 250
microseconds on a Dorado) and take most of the time, as we expected.  Help on
redesign on that would be most welcome.

danny

Date:  4 OCT 1982 0514-PDT
From: JONL.PA
Subject: MASTERSCOPE Message
To:   LISPBUG^

If you edit a macro, MasterScope will correctly tell you that certain functions depend upon it;  but when calling UNSAVEFNS, it always prints the message "Loading FooFunction", regardles of whether it is really loading it, or merely UNSAVEDEFing it.

Date:  4-Oct-82 12:53:41 PDT (Monday)
From: Masinter.PA
Subject: lisp.tasks
To: masinter
cc: , Masinter.PA

* Compiler: [14 NOV 1981 1815-PST]  (FUNCTION (LAMBDA --)) expression used
  as a value to be stored into a record slot.  The compiler did produce a suitable subfunction, but then compiled as the value of the (FUNCTION --) expression the free varaible NEWVALUE.
* Name conflicts with system fns
* EVAL edit macro in editor needs ERSETQ instead of NLSETQ.
* correct handling of meta, blank keys
* periodicallyreclaim be sensitive to mouse events, process suspension.
* Breakcheck problem associated with heavy swapping on first uba or udf.
* improve interface to stats for other things than fn call
* make STACK FULL non-fatal error
* (APPEND circular) bug
* Can create ARRAYs > 2^16. 
* STORAGE) function prints garbage negative numbers in the 3rd column.
* UNBREAK work on internal block functions just like TRACE
* BRKDWNRESULTS print out
* interaction of code which rewrites filemaps and RADIX
* rename low level functions
* memory map diagnostics
* DUMMYFRAMEP definition correction
* Interlisp-10 problems:
   * DELFILE BUG
   * samedir has problems on tops20: directoryname neq filenamefield
   * CALLSCCODE returns duplicate values
   * add ALLOCSTRING
   * make NCREATE allocate system datatypes too
* Code for generating Interpress from Tops-20 and Vax (Troff, Scribe, ...)
* small demo
* LISPXSTATS
* compiler optimization NEWOPTFLG=T
* free code deleterefs pointers therefrom

Misc bugs
	Masterscope recursion with long names
BQUOTE

Date:  6-Oct-82 13:21:14 PDT (Wednesday)
From: Masinter.PA
Subject: questions & comments from Schoen
To: LispSupport
cc: Masinter.PA

document VRAID package; I think as a LispUsers package.

 we should provide FLOUT and READ/WRITEBINARYBITMAP for fast i/o of floatps and bitmaps.

Schoen has a VAXPRINT package (possibly similar to VanBuers) which causes
the vax to hardcopy screen bitmaps. He doesn't know what the Versatec they
use is exactly, but it has 2112 dots across, he says.


Date:  8 OCT 1982 1620-PDT
From: SHEIL.PA
Subject: Lisp task list
To:   MASINTER
cc:   lispcore^

I just spent 15 mins reading it. Very comprehensive; fine job; don't envy
you the task of prioritizing it! A couple of additonal points:

ERRORSET compilation. 
		Possibility of marking the stack rather than introducing
		new function call. If not, the making compiler suppress or
		rename forced new specvars.
Error handling
		Proposal to make ^D work by ^E (incompatible but worth it?)
		Some improvement over current mess.
		Failing that, debugging optimization of RESETLST/SAVE/FORM
Global vars
		If RESETVARSLST is known not to be declared global, lets fix it
		rather than documenting it! Mike Sannella needs some help
		to get new manual to indicate which system params are global
		- maybe he could propose a list derived from the manual and
		we could dispose of this one.
Garbage collection
		Compiled code blocks (pointers therefrom)
		Hash arrays [urgent; current incompatibility + perf problem]
	File package
		Hasdef problems
		Fixing EDIT interfaces to use same.

Beau

Date: 11-Oct-82 16:41:58 PDT (Monday)
From: vanMelle.PA
Subject: CASEARRAY for READ
To: LispSupport

Yet another (perhaps the same) request for (RAISE T) for files...

------------------------------
Mail-from: Arpanet host SU-SCORE rcvd at 11-OCT-82 1414-PDT
Date: 11 Oct 1982 1402-PDT
From: David E. Smith <CSD.SMITH at SU-SCORE>
Subject: lower case
To: vanmelle at PARC-MAXC
Stanford Phone: (415)497-1809

I need a way of forcing interlisp to be case independent for file input as
well as terminal input.  Read macros won't do it because I don't want the
lower case letters to be break characters and "ALWAYS" forces this.  Advising
or rewriting READC presumably wouldn't work either because strings and
characters prefaced by "%" would then get upcased.

How do I do this?  Am I forced to rewrite LOAD and all of its accomplices?
Crufty and/or release dependent solutions will not be sneezed at.  Help!

	-- de2
----------------------------------------------------------------
Date: 12-Oct-82 13:11:06 PDT (Tuesday)
From: vanMelle.PA
Subject: Font assumptions
To: Burton
cc: LispSupport

If you do (FONTSET 'STANDARD) to turn off fonts (e.g., to make a
fontfree file), subsequent calls to the inspector die in a \DTEST of
FONTDESCRIPTOR because DEFAULTFONT is NIL.

I wonder how many other places make such assumptions.

Incidentally, herewith a reminder that \DTESTFAIL desperately needs to
produce a better error message, at least incorporating its second arg
(the intended type).

	Bill

Date: 14-Oct-82 16:36:57 PDT (Thursday)
Subject: Re: Schlumberger URGENT
In-reply-to: Raim.EOS's message of 14 Oct. 1982 10:24 am PDT (Thursday)

Eric (and users in general) should avoid doing (APPLY 'IMAX LST) and
instead write (for X in LST maximum X).

The limit of number of arguments to a function is indeed 80; it is possible
that we could bump it, but there still would be a fixed limit.

Larry


Date: 15-Oct-82 15:05:36 PDT (Friday)
From: vanMelle.PA
Subject: LARGEST/SMALLEST
To: LispCore^

It has been pointed out that these names are confusing, due to the
ambiguity of what you might want the iterative to return.  I propose
that LARGEST be called MAXIMIZING, SMALLEST be MINIMIZING, and that
there also me oprs MAXIMUM and MINIMUM.  Since FIND is a synonym of
FOR, we could thus have:

  (find X in L maximizing (FOO X))
		returns the X for which FOO is largest, and
  (for X in L maximum (FOO X)) 
		returns the largest value of FOO over L.

	Bill


•žGACHA
•ž
z¸