Re: frame-local variables weirdness

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

>     I'd much rather disallow variables that are both buffer-local and
>     frame-local.

> We should not cavalierly disallow the use of features in combination
> just because there is a bug.  Have you tried to fix those other
> problems?  If not, you don't know that it is hard to do so.

The interaction of buffer-local and let-bound variables is already tricky
(and has suffered from several bugs over the years).  When we add
frame-local variables to that, it gets yet nastier so I think we should only
support such a feature if there's a clear need for it.  I don't see it.


        Stefan


PS: As a matter of fact, I don't even see a need for frame-local variables
at all: they *are* used currently, but only because they exist.
The potential benefits of using frame-local variables rather than explicitly
using `frame-parameter' are:
- faster access thanks to caching.
- ability to influence the behavior of code which didn't expect the variable
  to be frame-local.
None of the uses I can see benefit from those.  They'd be just as happy
using explicit calls to frame-parameter, which would also simplify the
specbind and Fsymbol_value code (a piece of code that's pretty complex as
it stands), thus streamlining a heavily used code (especially compared to
the rarely used (mis)feature)).