obarray

obarray

[Emanuel Berg]

Anyone knows what that is?

> Symbol table for use by `intern' and `read'.
> It is a vector whose length ought to be prime for
> best results.
> The vector's contents don't make sense if examined
> from Lisp programs; to find all the symbols in an
> obarray, use `mapatoms'.

*laughter*

-- 
Emanuel Berg, programmer-for-rent. CV, projects, etc at uXu
underground experts united:  http://user.it.uu.se/~embe8573

Re: obarray

[Juanma Barranquero]

On Sun, Dec 15, 2013 at 1:54 AM, Emanuel Berg <embe8573@student.uu.se> wrote:
> Anyone knows what that is?

What is that you don't understand in its description?

>> Symbol table for use by `intern' and `read'.
>> It is a vector whose length ought to be prime for
>> best results.
>> The vector's contents don't make sense if examined
>> from Lisp programs; to find all the symbols in an
>> obarray, use `mapatoms'.

I think it's pretty clear: is a symbol table for (most) symbols. It is
implemented as a vector, of prime length because of the way the
hashing is done, and it does not make sense to examine it from lisp
*as a vector*, because its elements are not symbols, but have a more
complex structure (basically, they implemente some kind of hash
table). So the way to process all elements of that symbol table is to
use mapatoms; looping over the vector won't give the symbols stored in
the table.

    J

Re: obarray

[Emanuel Berg]

Juanma Barranquero <lekktu@gmail.com> writes:

> I think it's pretty clear: is a symbol table for
> (most) symbols. It is implemented as a vector, of
> prime length because of the way the hashing is done,
> and it does not make sense to examine it from Lisp
> *as a vector*, because its elements are not symbols,
> but have a more complex structure (basically, they
> implemented some kind of hash table). So the way to
> process all elements of that symbol table is to use
> mapatoms; looping over the vector won't give the
> symbols stored in the table.

Well, that description was a lot better.

So it is a hash table of symbols: variables, constants,
:keywords, functions, ...?

And when you do `defvar', is the symbol name inserted
into this data structure based on some property -
perhaps the name itself, or type (if a "symbol" isn't
atomic)?

Is the value inserted as well or do they use some sort
of pointer scheme?

-- 
Emanuel Berg, programmer-for-rent. CV, projects, etc at uXu
underground experts united:  http://user.it.uu.se/~embe8573

Re: obarray

[Michael Heerdegen]

Hi,

> So it is a hash table of symbols: variables, constants,
> :keywords, functions, ...?
>
> And when you do `defvar', is the symbol name inserted
> into this data structure based on some property -
> perhaps the name itself, or type (if a "symbol" isn't
> atomic)?
>
> Is the value inserted as well or do they use some sort
> of pointer scheme?

That's all described very well in

  (info "(elisp) Creating Symbols")


Michael.

Re: obarray

[Juanma Barranquero]

On Sun, Dec 15, 2013 at 2:37 AM, Emanuel Berg <embe8573@student.uu.se> wrote:

> So it is a hash table of symbols: variables, constants,
> :keywords, functions, ...?

symbols. Symbols are primitive objects with some properties (pointer
to value and function, which can be null, a property list, etc.). Look
at the code for details

> And when you do `defvar', is the symbol name inserted
> into this data structure based on some property -
> perhaps the name itself, or type (if a "symbol" isn't
> atomic)?

As the description says, it is "intern" and "read" which do insert
("intern") symbols into the standard obarray. It is possible to use
other obarrays (that's what the OBARRAY arg of `intern' is for), or
have non-interned symbols.

> Is the value inserted as well or do they use some sort
> of pointer scheme?

As said above, the symbol object has a slot for the variable value and
another one for the function value, IIRC.

    J

Re: obarray

[Emanuel Berg]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> That's all described very well in
>
>   (info "(elisp) Creating Symbols")

Yes, that's true. The Elisp manual is great. Thank you,
all of you who wrote and/or provided feedback to that
great book. I'm actually reading it cover to cover as
we speak. But I haven't gotten that far.

I managed to print it after getting the info system to
work. Apparently I had to add "non-free" to the Debian
repos for the emacs24-common-non-dfsg to show up on
aptitude search. Non-Debian-free-software-guidelines! I
thought the GNU Emacs people were the
fanatics... perhaps I should switch team!

Speaking of the manual, is this correct?

> Ordinary text terminals have no way of generating
> non-ASCII control characters, but you can generate
> them straightforwardly using X and other window
> systems.

Remember this method in Linux:

control keycode 39 = U+010F  # C-; - get 39 with keycode
                             # then update with
                             # loadkeys <file>
;; and then                             
(define-key input-decode-map [?\u010F] [C-semi-colon])

-- 
Emanuel Berg, programmer-for-rent. CV, projects, etc at uXu
underground experts united:  http://user.it.uu.se/~embe8573

Re: obarray

[Barry Margolin]

In article <87bo0irj13.fsf@nl106-137-194.student.uu.se>,
 Emanuel Berg <embe8573@student.uu.se> wrote:

> Juanma Barranquero <lekktu@gmail.com> writes:
> 
> > I think it's pretty clear: is a symbol table for
> > (most) symbols. It is implemented as a vector, of
> > prime length because of the way the hashing is done,
> > and it does not make sense to examine it from Lisp
> > *as a vector*, because its elements are not symbols,
> > but have a more complex structure (basically, they
> > implemented some kind of hash table). So the way to
> > process all elements of that symbol table is to use
> > mapatoms; looping over the vector won't give the
> > symbols stored in the table.
> 
> Well, that description was a lot better.
> 
> So it is a hash table of symbols: variables, constants,
> :keywords, functions, ...?
> 
> And when you do `defvar', is the symbol name inserted
> into this data structure based on some property -
> perhaps the name itself, or type (if a "symbol" isn't
> atomic)?

Symbols are inserted into the obarray when they're interned. Either by 
calling the intern function explicitly, or implicitly when the symbol is 
seen by the Lisp reader.

This is how Lisp ensures that every time you type a symbol, it refers to 
the same one: the first time you type it, it gets added to the obarray, 
and function times find the symbol in the obarray and don't create a new 
symbol.

> Is the value inserted as well or do they use some sort
> of pointer scheme?

Values are unrelated to whether a symbol is in the obarray. An 
uninterned symbol can have a value.

(setq uninterned-symbol (make-symbol "foo"))
(setf (symbol-value uninterned-symbol) 'bar)

This symbol "foo" won't be in the obarray, but it still has a value.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: obarray

[Michael Heerdegen]

Barry Margolin <barmar@alum.mit.edu> writes:

> Values are unrelated to whether a symbol is in the obarray. An 
> uninterned symbol can have a value.
>
> (setq uninterned-symbol (make-symbol "foo"))
> (setf (symbol-value uninterned-symbol) 'bar)

The last line easier without cl'ish setf:

   (set uninterned-symbol 'bar)  

> This symbol "foo" won't be in the obarray, but it still has a value.

And to answer the next question: "What are uninterned symbols good for"?
They are useful especially when writing macros, as a way to avoid
collisions with already used symbols.  But that doesn't matter here.

All that need to know is that obarray is a thing that holds all
essential symbols (variables), and that it is a valid COLLECTION
argument for `completing-read'.


Regards,

Michael.

Re: obarray

[Emanuel Berg]

Barry Margolin <barmar@alum.mit.edu> writes:

> Values are unrelated to whether a symbol is in the
> obarray. An uninterned symbol can have a value.

OK.

> (setq uninterned-symbol (make-symbol "foo"))
> (setf (symbol-value uninterned-symbol) 'bar)

That looks backward. It looks like you are setting the
value (i.e. data) to 'bar. But `symbol-value' returns
not only the data for practical purposes, but the
*place* of the data (and those are the same)?

> This symbol "foo" won't be in the obarray, but it
> still has a value.

To me, with the defun I wrote in the beginning of this
thread, I *do* get uninterned-symbol, and that should
only look in obarray - also, the value seems to be not
'bar, but "foo" (?).

-- 
Emanuel Berg, programmer-for-rent. CV, projects, etc at uXu
underground experts united:  http://user.it.uu.se/~embe8573

Re: obarray

[Emanuel Berg]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> The last line easier without cl'ish setf:
>
>    (set uninterned-symbol 'bar)

CL or not, I get the same situation (what I can see),
the symbol *does* end up in obarray, and that second
part (setf or set) - what is that supposed to do? What
I can see it doesn't change the value, either with my
defun or describe-variable (which I trust more), I get
the argument to make-symbol.

> And to answer the next question: "What are uninterned
> symbols good for"?

Professor X...

> They are useful especially when writing macros, as a
> way to avoid collisions with already used symbols.
> But that doesn't matter here.

Macros as in programs writing programs (?). You need to
get at unique symbol and you can't spell it out as you
don't know what in what setting the macro is
executed. I guess you can use `let' in macros, so does
this mean you use this for example when you need a new
global variable? But if it is global, and the name is
generated, how can anyone outside know how to access
it?

> All that need to know is that obarray is a thing that
> holds all essential symbols (variables), and that it
> is a valid COLLECTION argument for `completing-read'.

Yes, it seems to work. I am happy you read my code.

-- 
Emanuel Berg, programmer-for-rent. CV, projects, etc at uXu
underground experts united:  http://user.it.uu.se/~embe8573

Re: obarray

[Emanuel Berg]

Emanuel Berg <embe8573@student.uu.se> writes:

> Macros as in programs writing programs (?). You need
> to get at unique symbol and you can't spell it out as
> you don't know what in what setting the macro is
> executed. I guess you can use `let' in macros, so
> does this mean you use this for example when you need
> a new global variable? But if it is global, and the
> name is generated, how can anyone outside know how to
> access it?

What about - if you want to make sure the locals do not
"shadow" some globals that you don't know of (or are
"dynamic" in nature)? But if you don't know about them,
how can you use them, and (accidentally) get the
locals? So it doesn't make sense either. An example
would help.

-- 
Emanuel Berg, programmer-for-rent. CV, projects, etc at uXu
underground experts united:  http://user.it.uu.se/~embe8573

Re: obarray

[Barry Margolin]

In article <mailman.9279.1387082898.10748.help-gnu-emacs@gnu.org>,
 Michael Heerdegen <michael_heerdegen@web.de> wrote:

> All that need to know is that obarray is a thing that holds all
> essential symbols (variables), and that it is a valid COLLECTION
> argument for `completing-read'.

It's also important to know that not everything in it is a variable. 
Symbols also name functions, and they're also often used as literal 
objects by themselves (e.g. when you see them quoted).  And many symbols 
that are variables are just local variables internal to functions (not 
to be confused with buffer-local variables); these shouldn't show up in 
describe-variable.

That's why the completing-read collection that describe-variable uses 
checks whether the symbol is bound or has a variable-documentation 
property.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: obarray

[Barry Margolin]

In article <87wqj6pva0.fsf@nl106-137-194.student.uu.se>,
 Emanuel Berg <embe8573@student.uu.se> wrote:

> Barry Margolin <barmar@alum.mit.edu> writes:
> 
> > Values are unrelated to whether a symbol is in the
> > obarray. An uninterned symbol can have a value.
> 
> OK.
> 
> > (setq uninterned-symbol (make-symbol "foo"))
> > (setf (symbol-value uninterned-symbol) 'bar)
> 
> That looks backward. It looks like you are setting the
> value (i.e. data) to 'bar. But `symbol-value' returns
> not only the data for practical purposes, but the
> *place* of the data (and those are the same)?
> 
> > This symbol "foo" won't be in the obarray, but it
> > still has a value.
> 
> To me, with the defun I wrote in the beginning of this
> thread, I *do* get uninterned-symbol, and that should
> only look in obarray - also, the value seems to be not
> 'bar, but "foo" (?).

uninterned-symbol is an interned symbol. Its *value* is the symbol foo, 
which is not interned; foo shouldn't show up in the function you wrote 
earlier in the thread; unless you happen to have interned some other 
symbol by that name -- it would probably be clearer if I'd done:

(setq uninterned-symbol (make-symbol "something-you-have-never-typed"))

Now try your function and see if something-you-have-never-typed shows up.

The value of the symbol something-you-have-never-typed would then be bar.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: obarray

[Michael Heerdegen]

Emanuel Berg <embe8573@student.uu.se> writes:

> Michael Heerdegen <michael_heerdegen@web.de> writes:
>
> > The last line easier without cl'ish setf:
> >
> >    (set uninterned-symbol 'bar)
>
> CL or not, I get the same situation (what I can see),
> the symbol *does* end up in obarray, and that second
> part (setf or set) - what is that supposed to do? What
> I can see it doesn't change the value,

(symbol-value uninterned-symbol)

==> bar

Note that we are not speaking about the symbol uninterned-symbol, which
is in obarray, but about its value, which is another symbol that is not
in obarray, has name "foo", and now a value of bar.  We made that
uninterned symbol the value of another interned symbol because we can't
refer to an uninterned symbol directly in a program.

> either with my defun or describe-variable (which I trust more), I get
> the argument to make-symbol.

Sorry, I didn't follow this part.


Regards,

Michael.

Re: obarray

[Michael Heerdegen]

Emanuel Berg <embe8573@student.uu.se> writes:

> What about - if you want to make sure the locals do not
> "shadow" some globals that you don't know of (or are
> "dynamic" in nature)? But if you don't know about them,
> how can you use them, and (accidentally) get the
> locals? So it doesn't make sense either. An example
> would help.

Read the elisp manual about macros, especially this node:

  (info "(elisp) Surprising Local Vars")

But I guess you don't need this for your stuff.

Re: obarray

[Emanuel Berg]

Barry Margolin <barmar@alum.mit.edu> writes:

> And many symbols that are variables are just local
> variables internal to functions (not to be confused
> with buffer-local variables); these shouldn't show up
> in describe-variable.

As in what you get with `let', `labels', and the defun
parameters?

> That's why the completing-read collection that
> describe-variable uses checks whether the symbol is
> bound or has a variable-documentation property.

Of course, in describe-variable, they define a variable
as:

- in obarray (always)
- is bound (`boundp') *and* is not a :keyword
  (`keywordp'), *or*
- has variable-style documentation (definition 1)

Then, "v", in the interactive string, a variable is
"[a] symbol that is `custom-variable-p'." (2)

For my purposes, (1) is better, which makes sense since
my defun implements a (small) subset of
describe-function (instead the difference is how the
data is communicated with less noise, faster).

But: Why is (2) used in the interactive string? Is
there an advantage to (1) in this setting, *or* is this
something that just "is"? If (1) is a sensible
definition, is it all the same uncommon (as there is no
`is-variable-p' or the like, to encapsulate it, *and*
there is no way to get it into the interactive string
without this sort of big workaround)?

I don't say we should change describe-variable for
aesthetic purposes (surest way to break functional
code) but it is interesting if this is something that
"happened" or if anyone can see something beneath.

-- 
Emanuel Berg, programmer-for-rent. CV, projects, etc at uXu
underground experts united:  http://user.it.uu.se/~embe8573

Re: obarray

[Emanuel Berg]

Barry Margolin <barmar@alum.mit.edu> writes:

> uninterned-symbol is an interned symbol. Its *value*
> is the symbol foo, which is not interned; foo
> shouldn't show up in the function you wrote earlier
> in the thread; unless you happen to have interned
> some other symbol by that name -- it would probably
> be clearer if I'd done:
>
> (setq uninterned-symbol (make-symbol
> "something-you-have-never-typed"))

OK, get it, thank you.

> Now try your function and see if
> something-you-have-never-typed shows up.
>
> The value of the symbol
> something-you-have-never-typed would then be bar.

Is there a way to confirm this? How can I access a
symbol's value, if the symbol isn't in the obarray? If
it isn't in the obarray, where is it? Is there a buffer
and/or "scope" (i.e. form or process) local/temporary
object array or anything of the like?

-- 
Emanuel Berg, programmer-for-rent. CV, projects, etc at uXu
underground experts united:  http://user.it.uu.se/~embe8573

Re: obarray

[Emanuel Berg]

Michael Heerdegen <michael_heerdegen@web.de> writes:

>> CL or not, I get the same situation (what I can
>> see), the symbol *does* end up in obarray, and that
>> second part (setf or set) - what is that supposed to
>> do? What I can see it doesn't change the value,
>
> (symbol-value uninterned-symbol)
>
> ==> bar
>
> Note that we are not speaking about the symbol
> uninterned-symbol, which is in obarray, but about its
> value, which is another symbol that is not in
> obarray, has name "foo", and now a value of bar.  We
> made that uninterned symbol the value of another
> interned symbol because we can't refer to an
> uninterned symbol directly in a program.

Right. Chrystal clear. This answers most of the
questions in my previous post, I think, although don't
hesitate to elaborate (as always). I'm very
appreciative of this.

-- 
Emanuel Berg, programmer-for-rent. CV, projects, etc at uXu
underground experts united:  http://user.it.uu.se/~embe8573

Re: obarray

[Emanuel Berg]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Read the elisp manual about macros, especially this
> node:
>
>   (info "(elisp) Surprising Local Vars")

Right, I'm reading the Elisp manual cover to cover.
This reference is useful to other/future readers of
this thread, though.

It would be cool to write a program that wrote a
program. Lisp has a background in AI (from the 50s),
though I don't know if it was a lucky coincidence that
the lists worked so well, as search (in particular),
but also the transformation of data structures, are so
central in AI.

> But I guess you don't need this for your stuff.

Well, I need food and shelter. This, I *want*!

-- 
Emanuel Berg, programmer-for-rent. CV, projects, etc at uXu
underground experts united:  http://user.it.uu.se/~embe8573

Re: obarray

[Barry Margolin]

In article <87txeaxb4l.fsf@nl106-137-194.student.uu.se>,
 Emanuel Berg <embe8573@student.uu.se> wrote:

> Barry Margolin <barmar@alum.mit.edu> writes:
> 
> > uninterned-symbol is an interned symbol. Its *value*
> > is the symbol foo, which is not interned; foo
> > shouldn't show up in the function you wrote earlier
> > in the thread; unless you happen to have interned
> > some other symbol by that name -- it would probably
> > be clearer if I'd done:
> >
> > (setq uninterned-symbol (make-symbol
> > "something-you-have-never-typed"))
> 
> OK, get it, thank you.
> 
> > Now try your function and see if
> > something-you-have-never-typed shows up.
> >
> > The value of the symbol
> > something-you-have-never-typed would then be bar.
> 
> Is there a way to confirm this? How can I access a
> symbol's value, if the symbol isn't in the obarray? If
> it isn't in the obarray, where is it? Is there a buffer
> and/or "scope" (i.e. form or process) local/temporary
> object array or anything of the like?

You can access it the same way you can access the contents of arrays and 
lists -- by getting to it from some other variable (or cons cell or 
array element) that references it. That's what the variable 
uninterned-symbol is for.

(symbol-value uninterned-symbol) => bar

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: obarray

[Michael Heerdegen]

Barry Margolin <barmar@alum.mit.edu> writes:

> > Is there a way to confirm this? How can I access a
> > symbol's value, if the symbol isn't in the obarray? If
> > it isn't in the obarray, where is it? Is there a buffer
> > and/or "scope" (i.e. form or process) local/temporary
> > object array or anything of the like?

No.  They are just existing in memory, and will not be garage collected,
as long as they can be referenced from Lisp.  There is also no array of
all existing strings, of all window configurations, etc.  So you can't
tell Lisp to give you a complete list of all currently existing strings,
window configurations, or (uninterned) symbols.  There is just no need
to organize those objects in a user visible structure.

OTOH, an uninterned symbol can be used like any other symbol: it can be
set, used to hold a function, etc.

> You can access it the same way you can access the contents of arrays and 
> lists -- by getting to it from some other variable (or cons cell or 
> array element) that references it. That's what the variable 
> uninterned-symbol is for.
>
> (symbol-value uninterned-symbol) => bar

Of course, this is not very useful, it was just a demonstration, not a
realistic use case.  When using uninterned symbols in macros, you can
"paste" these symbols in the expansion code which will be evaluated at
run-time.  So, programs _can_ contain uninterned symbols; you can really
_use_ uninterned symbols in code.  Not in code read from a file or
buffer, but in code generated by macros.  This way, you avoid that you
accidentally use a symbol that is already "in use" (e.g. in the code the
macro transforms).


Regards,

Michael.

Re: obarray

[Emanuel Berg]

Michael Heerdegen <michael_heerdegen@web.de> writes:

>> Is there a way to confirm this? How can I access a
>> symbol's value, if the symbol isn't in the obarray?
>> If it isn't in the obarray, where is it? Is there a
>> buffer and/or "scope" (i.e. form or process)
>> local/temporary object array or anything of the
>> like?
>
> No.  They are just existing in memory, and will not be
> garage collected, as long as they can be referenced
> from Lisp.  There is also no array of all existing
> strings, of all window configurations, etc.  So you
> can't tell Lisp to give you a complete list of all
> currently existing strings, window configurations, or
> (uninterned) symbols.  There is just no need to
> organize those objects in a user visible structure.

OK.

> OTOH, an uninterned symbol can be used like any other
> symbol: it can be set, used to hold a function, etc.
>
>> You can access it the same way you can access the
>> contents of arrays and lists -- by getting to it from
>> some other variable (or cons cell or array element)
>> that references it. That's what the variable
>> uninterned-symbol is for.  (symbol-value
>> uninterned-symbol) => bar
>
> Of course, this is not very useful, it was just a
> demonstration, not a realistic use case.

Yes :)

> When using uninterned symbols in macros, you can
> "paste" these symbols in the expansion code which
> will be evaluated at run-time.  So, programs _can_
> contain uninterned symbols; you can really _use_
> uninterned symbols in code.  Not in code read from a
> file or buffer, but in code generated by macros.
> This way, you avoid that you accidentally use a
> symbol that is already "in use" (e.g. in the code the
> macro transforms).

Yes, this much I understood, only it was hard to
visualize in practice. So: the macro accept code *as
arguments* (code that isn't evaluated) and transforms
that code? Then I get it. I thought the macro just
produced new code, in what case I can't see how it
could be useful because either no one knows about the
macro so no one will use any symbols it may setup, *or*
the macro knows about itself so any references to what
is setup locally will be correct.

-- 
Emanuel Berg, programmer-for-rent. CV, projects, etc at uXu
underground experts united:  http://user.it.uu.se/~embe8573

Re: obarray

[Michael Heerdegen]

Emanuel Berg <embe8573@student.uu.se> writes:

> Yes, this much I understood, only it was hard to
> visualize in practice. So: the macro accept code *as
> arguments* (code that isn't evaluated) and transforms
> that code?

Exactly.  Although, let's better say it accepts expressions (it must not
be valid code as such), and transforms them into code without evaluating
them before.  For example:

       (dolist (i '(1 2 3))
       		(message "%s" i))

The expressions (i '(1 2 3)) and (message "%s" i) are "arguments" to the
macro `dolist' in this call.  These are not evaluated, but transformed
into code.  You can see the transformed code with `macroexpand':

 (macroexpand '(dolist (i '(1 2 3))
		(message "%s" i)))

==>                

(cl--block-wrapper
 (catch '--cl-block-nil--
   (let
       ((--dolist-tail--
	 '(1 2 3))
	i)
     (while --dolist-tail--
       (setq i
	     (car --dolist-tail--))
       (message "%s" i)
       (setq --dolist-tail--
	     (cdr --dolist-tail--))))))

A macro call with the above arguments will first generate (expand) the
code to an expression like that, and will then execute it.

In the above case, the macro expanded to code that introduces another
variable, --cl-block-nil--.  In our case, it's an interned (!) symbol.
You can see why this isn't good when you try to evaluate

(dolist (--dolist-tail-- '(1 2 3))
  (message "%s" i))

Now you by coincidence use the symbol in the expression to be
transformed that the macro introduces as new variable.  They collide,
and

(dolist (--dolist-tail-- '(1 2 3))
  (message "%s" i))

doesn't work when evaluated.  So, it would be more correct to use an
uninterned symbol instead of '--dolist-tail--, then such a collision
could never happen.  They used a quite exotic name for the symbol so
such a collision is unlikely, but strictly speaking, the implementation
of dolist is not correct.

Defining `dolist' correctly is a good exercise for learning how to write
macros.


Regards,

Michael.

Re: obarray

[Emanuel Berg]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> They used a quite exotic name for the symbol so such
> a collision is unlikely, but strictly speaking, the
> implementation of dolist is not correct.

I agree, might as well do it fool-proof. If things can
go wrong, sometime they will.

-- 
Emanuel Berg, programmer-for-rent. CV, projects, etc at uXu
underground experts united:  http://user.it.uu.se/~embe8573

Re: obarray

[jack-mac]

Concerning uninterned symbols, you might try the following:

M-x ielm RET
*** Welcome to IELM ***  Type (describe-mode) for help.
ELISP> (setq foo1 'foo)
foo
ELISP> (set foo1 "one")
"one"
ELISP> foo1
foo
ELISP> (symbol-value foo1)
"one"
ELISP> foo
"one"
ELISP> (unintern foo1)
t

ELISP> (setq foo2 'foo)
foo
ELISP> (set foo2 "two")
"two"
ELISP> foo
"two"

ELISP> (symbol-value foo1)
"one"
ELISP> (symbol-value foo2)
"two"

; And now, for the fun:

ELISP> foo1
foo
ELISP> foo2
foo
ELISP> (eq foo1 foo2)
nil

We now have two symbols almost identical called "foo"...

To understand what happened, you must refer to the 'read' function.
When I type the 16 characters contained in "(setq foo2 'foo)", 
the reader has a lot of intense thinking activity.

I'll try to be brief (and will skip some elementary steps), 
which leads to something more or less like this:

Reader: Hey! I just read a character "(". 
I recognize it since I've already seen that before.
It's what human beings (my creators/gods) call a left parenthesis.
Let me check the syntax table. Hum... it seems it's the beginning of a list.
So I should prepare to build such a list. Hence, I need a first single cons cell.
Hey, Allocator, could you please give me just one cons cell?
Allocator: Let me check. Yes, I've plenty of them (or, at least, one available).
So, I can give it to you for free without calling my friend, Garbage collector.
I just need to remove it from my free cells list and here it is.
Reader: Ok. Thank you for this fresh new cons cell.

Now, I should prepare to read what to put in this pretty cons cell.
Let me see. The character "s".  
Hum. Let me check the syntax table. That might be the beginning of a symbol.
Let me put it at the beginning of a string buffer.
Let's look forward. Oh! an "e"! That confirms it could be a symbol.
I'd rather collect it in the string buffer with the previous "s" I just found.
And now a "t" and a "q"! I knew it! It's definitely the beginning of a symbol.
I already have 4 characters in my string buffer.
Let's continue. Oh! What a pity! a character " ", a space, as THEY call it!
That breaks my quest for a symbol, since spaces are known to be separators 
(at least in this context).
So, now, let's look back. I got these 4 characters "s" "e" "t" "q" in my string buffer.
I know it must be a symbol. But which one?
I already know it's a symbol named "setq", but I need to find its identity, 
its address, otherwise I won't be able to ask it to do its job.
Hmmm. Where is the symbol named with these 4 letters "s" "e" "t" "q".
I'm pretty sure it's stored somewhere... 
Oh! I remember! It's probably stored in the obarray.

Hey, Obarray, could you please tell me if you know of a symbol called "setq"?
Obarray: Hum... Wait a minute, I need to do some searching.
Whoa! What a mess here... This array is really huge!
If I must parse all my atoms and ask politely each of them 
whether its name is exactly this string "setq",
it will last for (almost) an eternity.  
Maybe I should hash this string.
Hey, Hasher, could you please tell me the hash code for this string "setq"?
Hasher: Sure! its hash code is "Z0RG1U8".
Obarray: Thanks a lot! 
Now, let's have a look at the right bucket with this hash code and this string.
You are lucky, caller! I got a (really old) symbol in there just called "setq" 
and it's address is " 'setq ".
Reader: Oh! Thank you! 
Obarray: but, be careful, some pretend it's a special form...
Reader: Oh! Thanks for the warning! I don't really know yet what to do with it,
probably some sort of evaluation. I'll see that later.

Now I should store this address.
Hey, Pretty cons cell, could you please store this address inside the contents 
of your address register?
Pretty cons cell: What?! You speak like a dinosaur! 
Do you want me to store it inside my 'car' stuff?
Reader: Oh! Sorry. Yes, please.
Pretty cons cell: Ok! I won't forget it and you can rely on me to remind it to you
whenever you need it until I'm asked to replace it by something else, of course!
Reader: Thank you!

Let's erase my input string buffer and continue. 
The next character is an "f". 
Hum. It's not a dot. So I will probably need another cons cell.
Hey, Allocator, could you please give me another cons cell?
Allocator: What? Again? But what have you done with the last one I just gave you?
Reader: Oh! I keep it for the moment, but I need a new one.
Allocator: Ok. I see. Here is the address of another one, but don't loose it!
Reader: Oh! I won't! Thank you!

Hey, First cons cell, could you please insert this address into the contents of your decrement... errr... I mean, into your "cdr"?
First cons cell: you want me to replace this brave old "nil" in my "cdr" by this address?
Reader: Yes, please.
First cons cell: Ok. Done.
Reader: Thanks a lot.

Now let me store this "f" inside my input string. 
And a "o", and another "o", and now a "2".
Yes, it's still valid for a symbol's name (since they all have this symbol syntax)
and now a "space" separator, according to the syntax table.

Hey, Obarray, could you please tell me if you know of a symbol called "foo2"?
Obarray: Wait a minute, I need to do some searching.
[snip]
Nope! I have a "foo1", but no "foo2". 
Reader: Oh! What am I going to do with this symbol name belonging to no symbol?
Obarray: Do you want me to create one for you?
Reader: Oh yes, please.
Obarray: Ok. Hey, Allocator, could you please create a symbol named "foo2"?
Allocator: Sure. I just need a few contiguous cells and here it is!
Obarray: Thank you for this address! 
Hey, Caller, here is your fresh new symbol.
Will you want to have the ability to find it again later?
Reader: Oh yes, please.
Obarray: So, I'd rather store it inside my array and tag it with its hash code. 
Ok. It's now stamped as "interned".
Reader: Thank you so much.

Ok. The next character is a "'". Let me have a look at the syntax table.
Oh! Oh! This one is a macro-character! That is quite special...

Author's note: Though I must admit how fascinating is this story,
we'll just skip some small steps and have a look a little further...

[snip]

This ")" character is a separator. It ends up the string buffer.
Hey, Obarray, could you please tell me if you know of a symbol called "foo"?
Obarray: Wait a minute, I need to do some searching.
Hum... How strange! I thought I had the vague feeling I created such one earlier.
Let me check again. 
No, sorry! I have a "foo1" and a "foo2", but no "foo" interned.
Reader: Never mind! Could you create and intern one for me, please?
Obarray: No problem. Here it is!
Reader: Thank you so much!
Hey, Second second cons cell, could you please store this address inside your "car"?
Second second cons cell: Ok. Done.

Reader: Now, let me return back to this separator character ")".
Oh! It means that the second list I started to build earlier is finished.
It contains 2 linked cons cells, with pointers to symbols respectively
named "quote" and "foo".
Now, let me return back to my previous list. 
Hey, Third cons, could you please store inside your "car" the address 
of this second list?
Third cons cell: Ok. Done.
So, this first list now contains 3 linked cons cells, with a pointer 
to the symbols respectively named "setq" and "foo2", and a pointer 
to a cons whose 'car' points to the symbol named "quote" 
and whose 'cdr' points to a cons whose 'car' points to a symbol named "foo"
and whose 'cdr' points to a special location, a symbol named "nil".
This could be printed (for THEM) as "(setq foo2 (quote foo))".
Ok. Now I can return a pointer to this fresh list (I mean, 
to the first cons cell of this list) and give it back to my caller.
Yeah!

Evaluator: Well, thank you, Reader, for this beautiful list.
Let me have a look at its first element.
Hey, First cons cell, could you tell me what is the contents 
of your address register?
First cons cell: Oh! No! You too?! Anyway, my "car" is a pointer 
to the symbol named "setq".
Evaluator: Thank you!

Hey, Symbol named "setq", could you please give me the contents
of your 'symbol-function'?
Symbol named "setq": It's (a pointer to) a subr named "#<subr setq>".
Evaluator: Hey, Subr "setq", could you please tell me if your 'subr-arity' 
ends up with the symbol 'unevalled ?
Subr "setq": Yes! How did you know that?
Evaluator: I suspected it. So you are a special form! 
Thus I won't evaluate your arguments.
Subr "setq": which are?
Evaluator: Hey, First cons cell, what is your second element?
First cons cell: You mean my 'cadr'? It's (a pointer to) the symbol named "foo2".
Evaluator: Thank you. And your third element?
First cons cell: It's (a pointer to) a cons.
Evaluator: Ok. Hey, Subr "setq", could you please compute with the symbol "foo2"
and this cons?
Subr "setq": No problem. 

I first need to evaluate this second argument.
Hey, Evaluator, could you please evaluate this list "(quote foo)"?
[snip]
Evaluator: I got your result: it's a pointer to the symbol named "foo".
Subr "setq": Ok. Thank you. Let me check the first argument.
Hey, Symbol named "foo2", are you a variable?
Symbol named "foo2": Sure! Why? 
Evaluator: Could you please store inside your 'symbol-value' the symbol named "foo"?
Symbol named "foo2": Ok. Done.
Evaluator: Well. It seems I just finished my job. And the result is a pointer
to the symbol named "foo"!

And now, just for the fun:

(progn
  (setq foo1 'foo)
  (set foo1 "one")
  (unintern foo1)
  (setq foo2 'foo)
  (set foo2 "two")
  (eq foo1 foo2))
=> t

Re: obarray

[Barry Margolin]

In article <87lhzkp4cx.fsf@nl106-137-194.student.uu.se>,
 Emanuel Berg <embe8573@student.uu.se> wrote:

> Michael Heerdegen <michael_heerdegen@web.de> writes:
> 
> > They used a quite exotic name for the symbol so such
> > a collision is unlikely, but strictly speaking, the
> > implementation of dolist is not correct.
> 
> I agree, might as well do it fool-proof. If things can
> go wrong, sometime they will.

It's a tradeoff. If you use uninterned symbols, debugging the macro is 
harder because you can't easily get the value of the temporaries.

The name they chose is so unlikely that a collision will only happen if 
someone is doing it deliberately. We don't worry about such internally 
malicious code.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: obarray

[Emanuel Berg]

Barry Margolin <barmar@alum.mit.edu> writes:

> It's a tradeoff. If you use uninterned symbols,
> debugging the macro is harder because you can't
> easily get the value of the temporaries.

OK.

> The name they chose is so unlikely that a collision
> will only happen if someone is doing it
> deliberately. We don't worry about such internally
> malicious code.

I agree a collision is extremely unlikely but on the
other hand, you do really have to spend time debugging
`dotimes'?

-- 
Emanuel Berg, programmer-for-rent. CV, projects, etc at uXu
underground experts united:  http://user.it.uu.se/~embe8573