Re: Try and detect common problems in lexical code

[Stefan Monnier]

>> Another difference is that this probably has a more noticeable
>> performance impact
> Shouldn't the cost be essentially 0 when (defvar) happens "at the toplevel",
> within an empty specdpl stack?  And isn't that the common case (a defvar is
> a toplevel form in a file loaded by a `require')?

specpdl holds all the current dynamic let-bindings, unwind_protects (and
their variants), and the call backtrace info, so it's never really empty
(e.g. `load` itself installs a handful of unwind_protects and
let-bindings on the specpdl stack around the execution of the actual
loaded code).

With the use of lexical binding (especially after byte-compilation), the
specpdl is typically less deep, indeed.  And at the top-level of loading
a file it's usually not terribly deep (unless it's an autoload that
happens in the middle of a deepish recursion).  So there's a chance the cost
won't be significant.

I just wanted to be clear that there is a possibility that the cost can
be above the noise-level in some cases (e.g. files with many defvars
that get (auto)loaded while we're in the middle of a deepish recursion).
I haven't bothered to measure it at all, tho.


        Stefan