WITH-DYNAMIC-EXTENT

[Barry Margolin <barmar@Think.COM>]

I just read the WITH-DYNAMIC-EXTENT proposal in CLtC-2 (Common Lisp: the
Cleanup Part 2), and I don't like it.  The problem, which is almost
touched on in the Discussion section, is that there may be some consing
going on that the user isn't aware of, and which is required to be of
indefinite extent.  I don't think a vendor who allows programmers to
specify that their objects should have dynamic extent should be forced
to go through their entire system and find all the places where
WITH-INDEFINITE-EXTENT should be added; I wouldn't trust them to be able
to find all of them (I don't think it's a mechanizable process).

I agree that some mechanism for this purpose should be provided.
However, I would prefer a mechanism that is a little more careful than
the current proposal.  Within a WITH-DYNAMIC-EXTENT form, a program
should have to explicitly indicate which objects should have dynamic
extent.  Something like:

(defun and-and-multiply (a b)
  (with-dynamic-extent ()
    (let ((x (dynamic (list a b)))
	  (y (cons nil nil)))
      (setf (car y) (apply #'+ x)
	    (cdr y) (apply #'* x))
      y)))

Here is the full description of my WITH-DYNAMIC-EXTENT and DYNAMIC
forms.  Please bear in mind that I just designed these now, and haven't
thought about them a great deal.

WITH-DYNAMIC-EXTENT			Macro

(WITH-DYNAMIC-EXTENT (&optional (INDICATOR NIL)) &body BODY)

This declares a contour during which the program may allocate objects
whose extent is specified to be within the dynamic lifetime of this
form [this wording is horrible, but you know what I mean].  To specify
which objects may be reclaimed when exiting this form, use the DYNAMIC
macro with a matching indicator.

INDICATOR is not evaluated.  BODY is evaluated as an implicit PROGN.

Value: the values of the last form of the body.

----------

DYNAMIC					Macro

(DYNAMIC FORM &optional (INDICATOR NIL))

The return values of FORM are specified to have the dynamic extent of
the most recent WITH-DYNAMIC-EXTENT form with a matching indicator.
FORM is evaluated, INDICATOR is not evaluated.

If a return value of this form is assigned to a place that is accessed
once the matching WITH-DYNAMIC-EXTENT form is exited, or if this value
is used as the return value of the WITH-DYNAMIC-EXTENT form or one
outside the WITH-DYNAMIC-EXTENT form (e.g. as the value in a throw to an
enclosing catch), the results are undefined.

Value: the values of FORM.

----------

An advantage of the WITH-DYNAMIC-EXTENT in the CLtC-2 proposal is that
it gives the application programmer some control over the internal
consing done by system and/or library routines.  However, I think it
should be the vendors' responsibility to make sure that these don't cons
any more than is necessary, if that is a concern of their customers.  I
don't think we should be providing a mechanism that allows developers to
control "behind the back" consing; it should only allow them explicit
control over the objects that they know about.

I made the indicators unevaluated because I was first thinking that this
would be a purely lexical facility.  Since I dropped that idea, it might
be appropriate to make the indicators be evaluated.

I am not wedded to the name DYNAMIC for the second operator.  Perhaps
DYNAMIC-VALUE would be better.

One problem with my version is that it doesn't provide a way to mark
objects that are bound to variables by macros as dynamic.  For example,
in a WITH-OPEN-FILE form, the OPEN form is not explicit, so it isn't
possible to wrap DYNAMIC around it.  The programmer would have to use
WITH-OPEN-STREAM in order to expose the OPEN call.  (On the other hand,
in most such cases it probably would be OK for the implementation of
such macros to allocate the objects dynamically, so the programmer
wouldn't need to).

                                                barmar