[Top][All Lists]
[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
- Unified name properties, Keisuke Nishida, 2000/09/20
- Re: Unified name properties, Keisuke Nishida, 2000/09/20
- Re: Unified name properties, Dirk Herrmann, 2000/09/20
- Re: Unified name properties, Keisuke Nishida, 2000/09/20
- Re: Unified name properties, Marius Vollmer, 2000/09/20
- Re: Unified name properties, Dirk Herrmann, 2000/09/21
- Re: Unified name properties, Keisuke Nishida, 2000/09/21
- Re: Unified name properties, Dirk Herrmann, 2000/09/22
- Re: Unified name properties, Marius Vollmer, 2000/09/25
- Re: Unified name properties,
Dirk Herrmann <=
- Re: Unified name properties, Jim Blandy, 2000/09/28
Re: Unified name properties, Marius Vollmer, 2000/09/20
Re: Unified name properties, Marius Vollmer, 2000/09/20