Re: Specifiers

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

> Note that this is mostly theoretic: in practice, one would rarely want
> to use different locus types for a single variable.

Until you get bug-reports.  The situation changes significantly if you
disallow combining different locus types: it's still not great
performancewise, but it's much more sane.

>> - what about `let'?  This one is really fun!

> `let' temporarily makes a locus-free binding.  The locality gets
> restored at the end of let.  This is not different to the current
> interaction of buffer-locality and let.

The current `let' behavior does not create temporarily
a locus-free binding.  E.g.

   (let ((default-directory "toto"))
     (with-current-buffer "newbuf" default-directory)

does not return "toto".

>> what does
>>   (let ((var val)) .. (make-local-variable 'var locus) ..)
>> do?  how 'bout
>>   (make-local-variable 'var foo) .. (let ((var val)) .. (setq var foo)?
>> or
>>   (make-local-variable 'var foo)..(let ((var val))..(select-other-foo..)var)?

> It gets messy.  But this messiness is nothing new:

There is something new about it, which is that as you add more types of
loci, it gets more and more difficult and costly to react to
locus-changes (e.g. set-buffer, select-window, select-frame, setq
major-mode, ...).

> The problem is that we already have buffer-locality and frame-locality
> and terminal-locality.

Indeed, that's a problem.  But frame-locality is on the way out.
Buffer-locality is here to stay, I think.

As for terminal-locality it is both less clean (because it's not really
developped, e.g. no equivalent to local-variable-p), and less
problematic because it cannot be combined with buffer-locality or
frame-locality and it is automatically local to all terminals rather
than only some, so it basically doesn't have global bindings, and it
only applies to predefined variables.

> And the behavior of all those is currently inconsistent.  The approach
> I proposed would make them consistent.

Show me a patch, so I can shoot holes through it.
Or better, don't bother: you'd be wasting your time.

> Adding something functionally similar to the existing localities but
> incompatible is not really helping keeping things simple.

You're looking for a simplicity akin to a 17-dimension "unifiying theory
of physics".  You may end up with a single very powerful and orthogonal
set of features, but I do not believe you'll get something simple.

> And as long as not more than one locality was introduced, there would
> be no speed impact for the list-based implementation.

I do not know what you're referring to here.


        Stefan