issue DYNAMIC-EXTENT-FUNCTION, version 1

[sandra%defun@cs.utah.edu (Sandra J Loosemore)]

As promised, here's a first cut at this issue.  I'm not particularly
attached to the name DYNAMIC-EXTENT-FUNCTION, but I'm still feeling
too burned out from arguing over what to rename DEFPROCLAIM to want to
waste a lot of time on thinking up alternate names for this one too. :-(


Forum:		CLEANUP
Issue:          DYNAMIC-EXTENT-FUNCTION
References:     Scope and Extent
		Issue DYNAMIC-EXTENT
Category:       ADDITION
Edit history:   04-Apr-89, Version 1 by Loosemore

Problem Description:

  Proposal DYNAMIC-EXTENT:NEW-DECLARATION, passed at the March 89 
  meeting, provides a mechanism for declaring that the values of
  variables have only dynamic (rather than indefinite) extent.  It
  would be useful to have similar functionality to indicate that
  functional bindings may have only dynamic extent.  (For example,
  this would permit compilers to stack-allocate closures.)

Proposal (DYNAMIC-EXTENT:NEW-DECLARATION):

  Introduce a new declaration called DYNAMIC-EXTENT-FUNCTION.  This is
  identical to the DYNAMIC-EXTENT declaration, except that the
  arguments name functions instead of variables.

Rationale:

  This permits a programmer to offer advice to an implementation about
  what functions may be stack-allocated for efficiency.

  It may be difficult or impossible for a compiler to infer this
  same information statically.

Current Practice:

  JonL says that Lucid's compiler can stack-allocate closures, but they
  have no mechanism for programmers to give the compiler permission to
  do so.

  HPCL-I has an UPWARD-CLOSURES declaration that pervasively affects
  all closures created within the scope of the declaration.

Cost to Implementors:

  No cost is forced since implementations are permitted to simply
  ignore the DYNAMIC-EXTENT-FUNCTION declaration.

Cost to Users:

  None. This change is upward compatible.

  There may be some hidden costs to debugging using this declaration (or any
  feature which permits the user to access dynamic extent objects without
  the compiler proving that they are appropriate). If the user misdeclares
  something and returns a pointer into the stack (or stores it in the heap),
  an undefined situation may result and the integrity of the Lisp storage
  mechanism may be compromised. Debugging these situations may be tricky,
  but users who have asked for this feature have indicated a willingness
  to deal with such costs. Nevertheless, the perils should be clearly
  documented and casual users should not be encouraged to use this
  declaration.

Cost of Non-Adoption:

  Some portable code would be forced to run more slowly (due to
  GC overhead), or to use non-portable language features.

Benefits:

  The cost of non-adoption is avoided.

Aesthetics:

  This declaration allows a fairly low level optimization to work
  by asking the user to provide only very high level information.
  The alternatives (sharpsign conditionals, some of which may
  lead to more bit-picky abstractions) are far less aesthetic.

Discussion:

  Loosemore supports DYNAMIC-EXTENT-FUNCTION:NEW-DECLARATION.
-------