Re: The rest of xVARs

[Dmitry Antipov <dmantipov@yandex.ru>]

On 08/08/2012 12:30 AM, Stefan Monnier wrote:

>> Should we also try to get rid of INTERNAL_FIELD, (B|K)VARs
>> but provide (B|K)SET macros similar to (F|W)SET?
>
> BVAR and KVAR were introduced for a different need: these fields are
> exported as Lisp vars, so they can be let-bound, and in the concurrency
> branch this will require special treatment both for reads and for writes
> (basically, while it's a single field, it can contain various values:
> one per thread).

We're very, very far from the full-featured Lisp threads; for me, even
a new GC looks simpler and more realistic :-). (I don't believe that we
will have multithreaded buffer processing in the foreseeable future,
but rather believe in a kind of implicit, i.e. invisible for Lisp,
concurrency like thread-per-buffer (sometimes) or thread-per-frame).

I can't continue without solving (B|K)VARs issue, and X = B->field/
BSET(B, field, X) is enough for my purposes; so I'm voting for doing
it so unless there is a plan to merge something from the concurrency
branch which can conflict with this. IIUC, real support for per-thread
values is not ever designed anyway.

> I dislike the current BVAR/KVAR mostly because it receives a field name
> as parameter (so it looks like a variable, while it's only a field
> name).  Maybe we can use TGET (foo->bar) and let the concurrency branch
> make the "bar" field into a different type than Lisp_Object.

So you should hate DEFUN which receives function pointer, Lisp_Subr name
and even a comment as parameters :-). I dislike it too, but consider them
as the smallest possible evil rather than a nightmare.

Dmitry