guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unified name properties


From: Dirk Herrmann
Subject: Re: Unified name properties
Date: Tue, 26 Sep 2000 11:54:09 +0200 (MEST)

On 25 Sep 2000, Marius Vollmer wrote:

> [...]  I really think that for most uses,
> being able to identify a primary name is useful.  For example, when
> printing on object via `write', you probably don't want to print all
> the different ways you can get areference to it.  CAR should just
> print as
> 
>     #<primitive-procedure car>
> 
> The "car" string would come from its name property.
> 
> [ Or maybe it should print as
> 
>     #<primitive-procedure r5rs:car>
> 
>   indicating its `home' module. ]

You can still get that behaviour by defining a `search order' for names
and using a name searching function that will return the first binding
found.  In fact, I think that avoiding a name property and instead
searching for existing bindings will give us a much more flexible system.

When I for example want to explain the beauty of scheme to friends or
colleagues, I prefer to have the following bindings:

car --> first
cdr --> rest
lambda --> procedure

etc.  This makes it simpler for a beginner to understand the concepts, at
least in a 'half hour introduction to scheme' :-)  Now, assume we wanted
to make such a `beginner mode' a feature of guile.  We could simply do
this by loading a `beginner' module.  Then, (at least I would argue) we
would not want to confuse people getting the following result:

> first
--> #<primitive-procedure car>

Instead I would prefer either to get a list of names, or that the
beginners module, if loaded, would be searched first:

> first
--> #<primitive-procedure first>

But, obviously, this is a matter of taste, and it actually does not mean
that you could not achieve a similar behaviour if a name property existed.
I give this as an example, however, to say that a `name' of an object,
even for basic objects like CAR, is a concept that leaves some room for
interpretation.


> > > 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.
> 
> Yes, but in the second case, we could assume that the user wanted to
> define a variable which happens to get as its initial value a function
> (and probably later assumes different values), while in the second
> case, he wanted to create a new function with a specific name.
> 
> In Scheme, there isn't really any fundamental difference between the
> two cases, but that's how I would interpret the intentions of the
> coder.

What about the following pattern:

(define foo
  (let* ((var #t))
    (lambda ()
      (do-something-with-var))))

Moreover, there are people who just prefer the second form for its
explicity.  I think we should not put any assumptions about a coder's
intention with regards to a `name property' into it.

But, again, whether a name property makes sense or not seems to be a
matter of taste.  I just happen to dislike it :-)

Best regards
Dirk




reply via email to

[Prev in Thread] Current Thread [Next in Thread]