issue DYNAMIC-EXTENT-FUNCTION, version 1

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

Comments on current practice:

This is very different from Symbolics Genera current practice, which
I would describe as follows:

First, if a function A has a DYNAMIC-EXTENT declaration for one of its
parameters F, and a caller of A passes a function B as the argument
corresponding to the parameter F, then B is used in a "downward" way.
Calling a function directly or via FUNCALL or APPLY is a "downward" use
too.  If every use of a function is "downward", then the compiler
implements the function with dynamic extent (provided the function is
not globally named, but is only locally named or not named at all, i.e.
defined with FLET, LABELS, or LAMBDA).  We currently use a different
name for the declaration, instead of DYNAMIC-EXTENT, but that is
unimportant.

Does the compiler committee's model of compilation permit compilation of
one function to be affected by declarations in the current definition of
another function that it calls?  I hope so.

Second, if a function has a SYS:DOWNWARD-FUNCTION declaration in front of
its body, then the function is implemented with dynamic extent regardless
of whether the compiler thinks all uses are "downward".  This feature is
used less often than the first feature, but is still used pretty often.
An example would be

  (funcall (computation-that-returns-a-function)
           (function (lambda (...)
                       (declare (sys:downward-function))
                       ...))
           ...other args...)

Here the function being called is not known at compile time, so there
is no place from which to obtain a DYNAMIC-EXTENT declaration.  In
your proposal, the declaration cannot be made unless the function is
given a name, so this example would have to be rewritten as:

  (flet ((dummy-name (...)
           ...))
    (declare (dynamic-extent-function dummy-name))
    (funcall (computation-that-returns-a-function)
             (function dummy-name)
             ...other args...))

Third, there is a variation of the first feature by which a function can
declare that all of its arguments are used "downward"; this is
especially useful for declaring arguments that are elements of a list
that is the value of an &rest parameter, since there is no parameter
name corresponding to those arguments.  We do this by using * instead of
a parameter name, but I don't see any way to map that into the
DYNAMIC-EXTENT declaration.  However, if we were willing to say that the
&rest list also had to have dynamic extent in this case, then a
DYNAMIC-EXTENT declaration of the &rest parameter would imply downward
use of the functions, since otherwise they would not be OIPs (in the
language of the amended DYNAMIC-EXTENT proposal that we just passed).
So I don't think we need this third feature.

The fact that your proposal is different from Symbolics Genera current
practice doesn't mean the proposal is wrong, after all it is also very
different from the current practices of the two implementations listed
in the proposal.  But we should think hard about dynamic extent for
anonymous lambdas, which can be quite important in practice.

On a sillier note, should we minimize proliferation of names by
replacing

   (declare (dynamic-extent-function name))

with

   (declare (dynamic-extent #'name)) ?

This is a serious proposal, although I suspect that some people
will think it is a stupid idea.