Do we have to worry about the names of generic functions?

Do we have to worry about the names of generic functions?

[Andy Wingo]

Hi,

I have a question for people, the answer to which will hopefully lay to
rest a lot of namespace-related debate. That question is, do we have to
worry about the names of our generic functions?

I've been trying to think of reasons for worry, and arguments against
the reasons, if I can find them. They're discussed below. Feel free to
add any that I missed, or correct anything that's unfair.

* Generics clobber the namespace.

I was inclined to believe this, but now I'm not so sure.

Consider a generic, `output'. I assert that x.output() in Python does
not clobber the namespace. x.output is syntactic sugar for referencing
the output field of x, and () means to invoke the returned object. If
output is a bound method, that means it will be invoked as output(x) --
exactly the same as (output x) in guile. The only difference regards
field lookup, which can be viewed as a limited version of multi-method
dispatch.

Although the name `output' is available to the world, the fact that it
is specialized restricts its validity to a certain subset of objects.
This subset is similar to python's "set of objects that have a field
named `output'".

To put it another way: what's the difference between (output x) and the
more smalltalk-like (x 'output)? The argument above leads to the
conclusion that there is no difference, and therefore that generics do
not clobber namespaces.

Is there a hole in that argument?

* Dispatching a generic with many methods might be inefficient.

If this is a problem, it should be solved in GOOPS.

* Using generics might be less readable.

This is indeed a problem. It can be solved by making generic names more
descriptive, or more commonly to make variable names more descriptive.
After all, x.output() doesn't tell you much, either.

* It's not obvious, when you read code, that you're calling a generic.

Hm. Well the short names of most of them is a clue ;) But seriously, I
don't know what to do here. JScheme has java-dot notation, where calling
java methods is done like (.uglyMethodName x), which is ugly but more
obvious. Some naming convention would be good here, I think...

* Conclusion

So, I haven't yet decided about naming generics. The debate comes up in
the context of g-wrap, a FFI-generating library. It exports some generic
functions as part of its API, and it's odd to see a library export
symbols like `visible?' and `add-item!'. All input on this issue is
appreciated.
-- 
Andy Wingo <wingo@pobox.com>


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Do we have to worry about the names of generic functions?

[Paul Jarc]

Andy Wingo <wingo@pobox.com> wrote:
> Consider a generic, `output'. I assert that x.output() in Python does
> not clobber the namespace.

Agreed, because that name exists only within "x.".

> If output is a bound method, that means it will be invoked as
> output(x) -- exactly the same as (output x) in guile.

Not exactly - generics sharing the same name don't conflict with each
other, but they can conflict with non-generics.  (AIUI; my
understanding of GOOPS is rather limited.)


paul


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Do we have to worry about the names of generic functions?

[Andreas Rottmann]

prj@po.cwru.edu (Paul Jarc) writes:

> Andy Wingo <wingo@pobox.com> wrote:
>> Consider a generic, `output'. I assert that x.output() in Python does
>> not clobber the namespace.
>
> Agreed, because that name exists only within "x.".
>
>> If output is a bound method, that means it will be invoked as
>> output(x) -- exactly the same as (output x) in guile.
>
> Not exactly - generics sharing the same name don't conflict with each
> other, but they can conflict with non-generics.  (AIUI; my
> understanding of GOOPS is rather limited.)
>
Yes, but when the non-generic are procedures, you can "upgrade" them:

(define quit (ensure-generic quit))

Andy
-- 
Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | a.rottmann@gmx.at
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Make free software, not war!



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Do we have to worry about the names of generic functions?

[Rob Browning]

Andreas Rottmann <a.rottmann@gmx.at> writes:

> Yes, but when the non-generic are procedures, you can "upgrade" them:
>
> (define quit (ensure-generic quit))

Hmm, but since you really don't know about all the other modules out
there, it seems like the safest thing when using really general names
might be to do this for all of your exported generics.  Although that
feels a bit crufty, and I presume still doesn't protect you from
exports that aren't a procedure or a method.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Do we have to worry about the names of generic functions?

[Andreas Rottmann]

Rob Browning <rlb@defaultvalue.org> writes:

> Andreas Rottmann <a.rottmann@gmx.at> writes:
>
>> Yes, but when the non-generic are procedures, you can "upgrade" them:
>>
>> (define quit (ensure-generic quit))
>
> Hmm, but since you really don't know about all the other modules out
> there, it seems like the safest thing when using really general names
> might be to do this for all of your exported generics.  Although that
> feels a bit crufty, and I presume still doesn't protect you from
> exports that aren't a procedure or a method.
>
You'd only do the above when you *know* a module imported has
e.g. "quit". You can't do much about stuff in modules you don't
import; I wonder what "#:generics merge" does when it encounters a
procedure and generic that have the same name...

That aside, another reason I think prefixes are basically unecessary
is that the importer can always do something like 

(use-modules ((g-wrap) #:renamer (symbol-prefix-proc 'gw:)))

if he insists on prefixed names. You could do something even more
fancy like prefixing only the non-class symbols (i.e. those not like
<FOO>).

Andy
-- 
Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | a.rottmann@gmx.at
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Make free software, not war!


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Do we have to worry about the names of generic functions?

[Rob Browning]

Andy Wingo <wingo@pobox.com> writes:

> I have a question for people, the answer to which will hopefully lay to
> rest a lot of namespace-related debate. That question is, do we have to
> worry about the names of our generic functions?

I just asked basically the same question on guile-devel, not realizing
you'd already done so here :>

> * Generics clobber the namespace.

> To put it another way: what's the difference between (output x) and the
> more smalltalk-like (x 'output)? The argument above leads to the
> conclusion that there is no difference, and therefore that generics do
> not clobber namespaces.
>
> Is there a hole in that argument?

One thing to consider is that at least in CLOS (and I'd presume GOOPS,
though I'm not as familiar with it), there are more sophisticated
multiple argument dispatch and multiple inheritance issues that may
distinguish the C++/python-esque "x.foo()" from CLOS/GOOPS "(foo x)",
or perhaps more accurately they may distinguish something like
"x.foo(a, b)" from "(foo x a b)".  With (foo x a b), x is not nearly
as "privileged" as it is in x.foo(a, b) because instead of just
considering the type of x, you have to consider the types of all of
the arguments, x, a, and b, and each one's class hierarchy, when
trying to determine dispatch.  Of course C++ has operator overloading
and implicit coercions which also complicate reading a call, and
require knowledge of more than just the type of x to determine what's
going on.

> * Using generics might be less readable.
>
> This is indeed a problem. It can be solved by making generic names more
> descriptive, or more commonly to make variable names more descriptive.
> After all, x.output() doesn't tell you much, either.

Yes, though choosing more distinguishing function names does have the
advantage that you can easily do things like

  fgrep '(gtk-close' *.scm

which wouldn't be possible if you're using the more generic names with
disambiguating variable names:

  (close window-foo)
  ...
  (close window-bar)

unless you use the same variable names in every invocation, or stick
to a very regular variable naming pattern.  Perhaps that's not a big
deal, but it might be worth consideration.

> So, I haven't yet decided about naming generics.

And contrary to any impression I may have given above, I haven't
either.  Although it is true that I don't mind more specific names,
and I have usually tended to think of generics more in terms of the
functionality they can provide within a given set of related classes,
I can also understand other people's desire to use the more generic
names, even if it doesn't weigh as heavily with me.

In any case, right now, I'd just like to try to make sure I understand
the relevant issues, and I want to be cautious where public exports
are concerned.

> The debate comes up in the context of g-wrap, a FFI-generating
> library.  It exports some generic functions as part of its API, and
> it's odd to see a library export symbols like `visible?' and
> `add-item!'. All input on this issue is appreciated.

Indeed.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Do we have to worry about the names of generic functions?

[Rob Browning]

Andreas Rottmann <a.rottmann@gmx.at> writes:

> You'd only do the above when you *know* a module imported has
> e.g. "quit". You can't do much about stuff in modules you don't
> import; I wonder what "#:generics merge" does when it encounters a
> procedure and generic that have the same name...

So I suppose it'd be up to the end user to do this when necessary
unless merge handles it somehow.

> That aside, another reason I think prefixes are basically unecessary
> is that the importer can always do something like 
>
> (use-modules ((g-wrap) #:renamer (symbol-prefix-proc 'gw:)))

Good point.  I didn't realize we already had support for that in 1.6.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Do we have to worry about the names of generic functions?

[Andy Wingo]

On Wed, 2004-05-12 at 12:14 -0400, Paul Jarc wrote:
> Andy Wingo <wingo@pobox.com> wrote:
> > Consider a generic, `output'. I assert that x.output() in Python does
> > not clobber the namespace.
> 
> Agreed, because that name exists only within "x.".

I'm not sure this is true. Of course python people will agree with you,
but contrast it to the message-passing style of programming, where a
message only has meaning in as much as the recipient knows how to deal
with it. Likewise, output() only means something if `x' has an output
field, and generics only have meaning in as much as a method has been
specialized for a type.

If the generic has not been specialized for a certain type, it won't
apply. The corresponding situation would be if x (or a superclass)
doesn't define an output() method. I'm not clear on the difference,
except wrt collisions with non-generics, which I believe Andreas
covered.

There is still something inside me saying that modules should not be
exporting identifiers like 'field or 'parent. But logic's leading me the
other way!

Cheers,
-- 
Andy Wingo <wingo@pobox.com>


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Do we have to worry about the names of generic functions?

[Andy Wingo]

Hi Rob,

On Thu, 2004-05-13 at 13:38 -0500, Rob Browning wrote:
> I just asked basically the same question on guile-devel, not realizing
> you'd already done so here :>

Hehe ;)

> > To put it another way: what's the difference between (output x) and the
> > more smalltalk-like (x 'output)? 
> 
> One thing to consider is that at least in CLOS (and I'd presume GOOPS,
> though I'm not as familiar with it), there are more sophisticated
> multiple argument dispatch and multiple inheritance issues that may
> distinguish the C++/python-esque "x.foo()" from CLOS/GOOPS "(foo x)",

True. But consider this: The set of python objects which have a foo
method is similar to the set of GOOPS objects which exist in the
specializers of a foo method. Specialization can only tighten the set of
objects to which foo can apply, which makes foo's dent on the namespace
even smaller.

> * Using generics might be less readable.
>
> Yes, though choosing more distinguishing function names does have the
> advantage that you can easily do things like
> 
>   fgrep '(gtk-close' *.scm

Although in the context of g-wrap we're dealing with generics that have
no procedural counterparts, (gnome gtk) for gtk2 provides both. So in
this case the choice is with the programmer. Furthermore, as Andreas
mentioned you can always use a prefix renamer.

At this point my brain is saying "don't worry about the names" and my
gut is saying "don't export anything without a prefix" ;) But it doesn't
seem like there's a technical reason to restrict the names, so long as
they don't conflict with non-generics.

Cheers,
-- 
Andy Wingo <wingo@pobox.com>


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Do we have to worry about the names of generic functions?

[Paul Jarc]

Andy Wingo <wingo@pobox.com> wrote:
> I'm not clear on the difference, except wrt collisions with
> non-generics, which I believe Andreas covered.

Well, he mentioned ensure-generic, but that only works on procedures.
Also suppose that I have this:
(use-modules (foo goops-module))
(use-modules (bar non-goops-module))

If both of those export the same name, then the non-goops module wins.
Which means it won't matter what the goops module did to defend
against collisions.  I have to resort to using a #:renamer, because
the default names weren't distinct enough.

That said, some conflicts just can't be foreseen, and #:renamer isn't
such a big burden for those cases.  (Personally, I always use an
explicit #:select to ensure I only pull in what I want, and I get no
collisions.)  But I agree with Rob that names should be designed for
readability and greppability; users shouldn't have to go to extra
effort (duplicated in each dependent module) to get those benefits.


paul


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user