[no subject]

[David Chapman <Zvona at MIT-AI>]

I have had a lot of problems with sectionization in interfacing
the PA to Zwei also.  Here is a partial analysis and a suggested
partial solution.
    Compile Buffer Changed Functions is not very smart about figuring out
    what needs to be compiled.  For example, enter a fresh editor buffer,
    type 

    (defun foo (x) (- x 2))
    (defun bar (y) (+ y 2))

    then do Compile Buffer Changed Functions.  No functions are
    compiled.  
This seems to be because the buffer is not sectionized initially,
so the text of the defuns is in a buffer node, not a section
node.  The buffer has no inferiors, so nothing happens.  There
ought to be a special case check when the buffer has no inferiors
that would first sectionize the buffer.
    Then do Evaluate Buffer, then C-N
    Rubout 4, and Compile Buffer Changed Functions compiles bar.
That is because Evaluate Buffer sectionized it.
    But then do M-< C-U C-K (defun quux (z) (- z 5)) and Compile
    Buffer Changed Functions, and it claims to compile foo. 
Because quux went into foos section-node.

There are a variety of related lossages, all of which depend on
the fact that **sectionization is not kept up-to-date**.  There
is a fix for this, namely completely incremental sectionization.
All buffer modification goes through three functions, namely
insert insert-interval and delete-interval.  Now if these were
made to check for parens in column 0, they could insert, delete,
and merge sections automatically, and the buffer structure would
be up-to-date.  KMP and I actually wrote much of this code, but
eventually decided that it was too drastic a change to make when
we could work around the problem.  

There is another whole class of lossages related to the paren in
col 0 hack and supra-defun list structure.  Consider

(eval-when (compile load)
(defun foo (x) (bar x))

(defun bar (y) (quux y)))

This thing gets three sections.  Now if you change the eval-when
line to

(eval-when (compile load eval)

and do m-X Compile Buffer Changed Functions, you get a read eof
error.  And if you modify bar, you get a read close-at-top-level
error. 

I don't see any easy solution for this one given that the paren in
col 0 hack is required for efficiency.  It is not clear what the
right thing is in any case.  One possibility would be to check
for this sort of situation and errset out the read errors.  This
has the bug that the supradefun information may be required to
make the contained functions compile properly.  An alternative
would be to somehow make contained defuns be in the section of
their containing list (by modifying the col 0 paren heursitic).
This has the disadvantage that if you modify one of the contained
defuns, you have to recompile all of them.  

Perhaps the best solution would be to have a table of the forms
that typically occur at supradefun level and their argument
positions.  Then you could know that the cddr of an eval-when is
an unordered list of forms for evaluation, and thus save
recompiling all the subforms when one is modified.  

Probably this is more trouble than it is worth.  But I think that
incremental sectionization *is* a worthwhile hack.