Re: Lexical binding -- do we really need it?

[Kim F. Storm]

Miles Bader <address@hidden> writes:

> address@hidden (Kim F. Storm) writes:
> > Still, I don't see why your arguments justify changing the semantics
> > of `let' (with all the derived changes) rather than introducing a new
> > `llet' for lexical binding.
> 
> This comes down to personal opinion, I think -- I think your suggestion
> is ugly, and I don't want to write my programs that way.  You are of
> course free to always use `llet' if you want, but please don't try to
> make _me_ do it.

I think it is ugly too.  But so is IMHO the requirement for - and
implications of - lexical-binding: t

> 
> In any case, it's still necessary to have a `lexical-binding: t' mode
> because of function arguments -- which will arguably benefit the most
> from lexical binding, and have the fewest `issues' (do you know of any
> code that uses a function argument to bind a global variable in a
> another package?!).

No.

>  [Of course, I suppose you could suggest `ldefun'
> &c., but I think that's simply too horrid for words, and indeed, it
> would probably make the implementation _more_ complex...]

Actually, I don't think there would be any issues if we *always* use
lexical binding for function arguments!  And if there are some (must
be less than 5), they are easily fixed (but hard to find :-)!

Or why don't we take the full step ahead... and make your lexical-binding
the standard binding for let (and defun).  To bind a variable dynamically,
it has to be declared via defvar/defcustom or using a new `dlet' form.

Since your estimate is that this will work for 99% of the existing
code, it might be worth the transitional noise.  The compiler might
help us spot any problems ... as it already barfs on undeclared
variables, so perhaps we just need to take those warnings seriously.

And you can keep the lexical-binding: nil for addition to code which
is too messy (depending in dynamic bindings) to be fixed.