Re: Lexical byte-compilation warnings cleanup

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> > And the intention is?  The design is?  The reason is?

Check the calling convention used by the new byte-code representation
(used for lexically scoped code) and you'll see that there's no support
for dynamic scoping in it.  Adding such support "natively" would
slow down the common case too much.

We could support dynamically-scoped args in lexically-scoped byte-code
by tweaking the byte-compiler, but then the byte-code that the
byte-compiler needs to generate is the same as the one you get with:

   (defun foo (lexarg)
     (let ((dynvar lexarg))
       ...))

So I prefer to make the extra cost of the separate `let' binding
explicit in the source code.  Especially since it has various beneficial
side-effects:
- simpler byte-compiler.
- slightly more efficient handling of function calls for
  lexically-scoped interpreted code (this is actually less beneficial
  than I thought at first, tho).
- IMNHO better style (I have always found it confusing when dynvars were
  bound as function arguments rather than by a let-binding).
- having a separate `let' often allows you to move it to a better place,
  and/or to add useful code between the function header and the let
  binding (such as the defvar that causes the variable to be
  dynamically bound).

BTW, I have never seen a dynamically-scoped argument used in
Common Lisp.


        Stefan