Re: Issue: STACK-LET (Version 1)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Mon, 27 Jun 88 15:40:27 EDT
    From: Scott.Fahlman@B.GP.CS.CMU.EDU

    Is there any reason, aside from compatibility with the current Symbolics
    usage,

Moon has our vote, not me. I usually leave it to him to evaluate what is good
or bad for Symbolics as a company. The extent to which Symbolics usage plays into
this is neither more or less than the extent to which any company offering this
primitive plays into this.

    why you prefer

    (stack-let ((x (list a b c))) ...body ...)

    to

    (let ((x (list a b c)))
      (declare (dynamic-value x))
      ... body )

    Since the idea is to give advice to the compiler about a specific binding,
    it seems to me that a declaration would be more consistent with the rest of
    the language than a new special form.  For example, that's how we handle
    advice about type restrictions.  Also, this would allow one to mix dynamic
    and non-dynamic bindings in the same LET form.

    -- Scott

No really big reason. A couple of little reasons.

 * In implementations where a related facility (eg, Zetalisp's older
   WITH-STACK-LIST and WITH-STACK-LIST* primitives) exists, it's easy to
   write a macro to translate STACK-LET into the other stuff. Whether it's
   easy to add a declaration depends on how declarations are implemented.

 * Since some implementations provide STACK-LET and not the modified LET, I
   thought I'd get stronger support from people who do provide it. People
   always seem to be more likely to vote for things that involve the least
   work on their own part.

 * I was afraid that some people would see this as a hairing up of LET.
   In retrospect, however, I guess you're right. It could be useful for
   DO, PROG, etc. if you had the declaration. Note well, however, that it's
   not useful for any case where the construction form is not lexically
   apparent to the binding form. Eg, 
    (DEFUN F (X) (DECLARE (DYNAMIC-EXTENT X)) ...)
   would violate modularity boundaries to optimize
    (F (LIST 1 2 3))
   although I suppose some argument could be made that in block compilation
   it was ok. By putting it in a STACK-LET form, this issue is made to not
   come up.

 * I sometimes get more results by suggesting something overly conservative
   and letting people suggest that it's not right or not enough than I do by
   suggesting originally the thing in full blown form. The latter strategy
   often gets me not taken seriously, whereas the first strategy offers a
   foot in the door to people who readily grasp the concepts of the stripped
   down proposal and who might after admitting the topic for discussion still
   arrive at the same position as I'd have originally wanted to propose.

In fact, the modified LET is fine with me. My main criterion is to have
something which has the highest likelihood of a yes vote in X3J13.