Re: Q: BLV for function slots + BL obarray/hmap for symbol lookup?

[Arthur Miller]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Ok, there you have something interesting. In which way? If you have time
>> to expand on that one. It is already possible to use custo obarray, but
>> we have to tell Emacs which obarray to use. I would like it to sort of
>> happen automatically if there is a buffer local one. Sort of. No idea
>> what would happen if there were more than one local :-). 
>
> I have the impression that your needs are a bit vague ;-)

I didn't want to write too long last time.

I have been experimenting with a little framework last 3 days, and I am
quite sure I need some kind of namespace, buffer local would be perfect
in this case. I don't wish to post any code on a public list atm, untill
I am done with it.

A short sketch is:

I have derived elisp mode, and I setup a sort of a "workbook"
with some predefined environment. There can be several "workbooks" open
at a time, each one is a mini-application, domain specific. User writes
elisp code, but since it is a domain specific, there may (and will) be
lots of variables and functions with same name, so they have to 
be insulated from each other. They also won't do sense in rest of
Emacs, but Emacs will need to be able to read and eval each workbook.

I also don't wish to force prefix usage since it would be very tedious,
and bit contraproductive in context of a simple domain specific
framework. I could impose restriction on one workbook at a time, but
there is still risk of stepping over some Emacs function.

> E.g. which buffer should be used to resolve the "buffer-localness"?
> The one when `intern` is called or the one when the already-interned
> symbol is used?

I am not sure I understand what you mean here. The rule would be same as
for buffer local vars, but they would work on symbol level instead of
variable slot level, at least conceptually. If "local obarray" is
declafed in a buffer, all interning would go to that one, like all
set/qset set's the local vaalue if there is one. The locally interned
symbol would automatically shadow the global one, and in buffers where
there is no local obarray the global one would be used. Maybe obarray is
not needed, maybe we could just somehow "make-local-symbol" instead of
"make-local-variable"? I don't know, I asked because I guess person(s)
who implemented the mechanism probably had the thought themselves and
decided for some reason to go just for variable slot and not entire
symbol. 

> Maybe you'd be interested in the effort to add some kind of namespace
> mechanism by adding some "prefix rewrite" rules used by the reader, so
> you could say that the "f:" prefix maps to "formi-" and then a
> symbol like "f:dable" is read as "formi-dable"?

I haven't been monitoring "the effort", so I can't tell much about it,
but I did initially had thought of doing my own name-mangling. Since the
framework has a luxury of user pressing on a "run" button to run the
workbook, I actually eval the buffer myself, so I can rewrite
declarations myself before I hand them to Emacs for eval. However, the
debugger would see rewritten names. I don't wish that. Also there is
effort of writing pre-processor/compiler whatever, which I am not sure I
wish to invest in.

If there was some mechanism to tell Emacs that symbol is buffer local,
it would come out for free so to say.

I was looking a bit in eval.c and lread.c how bvl work, but I don't
understand it enough so I could hack myself this, so that is why I
asked. Since there is already a way to switch between obarrays, I
thought it might have been an easier route. But any way to tell Emacs
that a symbol is buffer local, and eval respecting this, would work.