Re: Unified name properties

[Dirk Herrmann]

On 20 Sep 2000, Marius Vollmer wrote:

> > Why shouldn't an object have several names?  If you do (define foo car),
> > then you might want to get '(foo car) when you ask for the name of the
> > corresponding function object.
> 
> I think it is most helpful when objects have a clearly designated
> primary name (or no name at all).  They might have secondary `aka'
> names in addition, but only one should be the preferred name.
> 
> We might have a second property `secondary-names' or something like
> that if it turns out to be really desirable.
> 
> That is
> 
>     (define goo car)
> 
> should not change the primary name of the `car' object, but it might
> add to the secondary names.

Hmmm.  I don't see why this should be true, or, in other words:  I still
can't see a use for names except for debugging purposes.  Maybe you have
certain uses of 'name in mind, where it was important that there was just
one single name?  (If several names were allowed, it would probably be
better to use `names' instead of `name' to obtain these.)

What is a name of an object anyway?  If a name of an object is determined
by defining that object, we could simply go the other way around and scan
all top-level environments for bindings to the object and thus avoid the
need for a name property completely.  This would probably be the best
solution, since it adds no overhead at all, neither memory nor performance
wise.  And, the functions to scan the environments can easily be put into
a module.

This way, finding the names of an object is somewhat time consuming, but
for debugging this should be allright (maybe with caching).  What this
wouldn't solve is the problem of objects that have no binding in any
environment.

> I don't think giving names to objects is very expensive (but maybe it
> is, we should measure this).  [...]

It seems clear that giving a name to an object itself is not a very time
consuming operation.  However, as for today the guile-user module has 1519
top-level names defined.  If this is (as I have assumed above) all
information about names that we need, why should we add about 3000
redundant cells (for the alist) to guile?

And, your suggestion to lazily compute names:

> [...] The new property mechanism has a way to
> lazily compute values for generics, and this can be used to retrieve
> names that are expensive to find, for example from the debugging
> information coming with compiled code.

would work well with the idea to scan the environments for names.


> I would argue that only this form
> 
>     (define (foo) ...)
> 
> should give a name to the created function, while this
> 
>     (define foo (lambda () ...))
> 
> should not.

Why?  This is a different issue than giving several names to the same
object as above:  In both cases a _new_ object is created, namely a new
function.  Thus, you are not renaming anything.

Am I right to assume that you are thinking of
    (define foo bar)
which actually gives a new name to an already existing object (which
may have had a name before)?


Best regards
Dirk