[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue DYNAMIC-EXTENT-FUNCTION, version 1
- To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Subject: Re: issue DYNAMIC-EXTENT-FUNCTION, version 1
- From: firstname.lastname@example.org (Sandra J Loosemore)
- Date: Wed, 5 Apr 89 08:10:21 MDT
- Cc: Sandra J Loosemore <email@example.com>, firstname.lastname@example.org
- In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 4 Apr 89 16:23 EDT
> Date: Tue, 4 Apr 89 16:23 EDT
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> 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.
Issue COMPILE-ENVIRONMENT-CONSISTENCY talks about situations in which
the compiler is allowed to assume that functions defined in the
compiletime environment retain the same definitions at runtime. I
don't see anything wrong with applying this technique in those
> 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.
I vaguely remembered seeing this in some ancient Symbolics
documentation. It seems a little strange to me to have a declaration
that is only valid in one particular place, but this would indeed take
care of the problem with anonymous lambdas.
> On a sillier note, should we minimize proliferation of names by
> (declare (dynamic-extent-function name))
> (declare (dynamic-extent #'name)) ?
I wouldn't have any strong objection to doing this, but maybe I'm
being silly too. :-)