Re: Lexical bindings (was Re: table.el)

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/address@hidden> writes:

> > Anyway, I still think overloading `let' and relying on a file scope
> > `lexical-binding' variable is a really bad idea.
> 
> Note that the two behaviors end up being the same in a large number
> of cases.

Sure!  This is why I think it makes sense to use different forms to
give the reader of the code (and the byte-compiler) a clear indication
of what is really intended.

>             Also the byte-compiler should be conservative and use
> dynamic binding whenever there's a suspicion that it's what was
> meant (f.ex. if the let-bound variable does not appear to be used).

So what you are saying is that code generated by the byte-compiler may
in some cases behave slightly differently from non-compiled code?

> The first priority is "100% backward compatibility" (otherwise Richard
> will reject it),

Which is a good reason for not messing with the existing `let' semantics.

>                  the second is simplicity (otherwise Richard will
> reject it)

I suppose that includes `simple to use, understand and document'.

>             and "good support for static scoping" only comes after that.

IMHO, the currently planned design doesn't qualify as "good".

> In any case we'd definitely want `slet' (which I prefer to `local')
> so that we can lexically bind variables that some other random package
> has decided to `defvar'.

Are you saying that we would both change the semantics of `let' - and
add `slet' anyway to cather for the remaining odd behaviour of `let' ?

If you don't like `local' I'd suggest `llet' rather than `slet' to 
keep the visual resemblence with `let'.  

BTW, in Danish, `slet' means "bad", whereas `let' means "easy".
I'd guess that's not how you would rate lexical vs. dynamic binding :-)

Summary: Don't mess with `let' at all! Please!