guile-devel
[Top][All Lists]
Advanced

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

Re: guile-1.5.1 and deprecated ...


From: Marius Vollmer
Subject: Re: guile-1.5.1 and deprecated ...
Date: 24 Aug 2001 00:52:01 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.102

Rob Browning <address@hidden> writes:

> One naive view would be that as long as two methods signatures don't
> conflict, they're not the same method and there shouldn't be any
> shadowing problems.  i.e. imagine you have:

When trying to nail down the semantics, we have to spell out all the
details that are normally glossed over for convenience:

Methods are not functions and don't have names; functions don't have
names, either; variables don't have names; variables are accessible
via some name relative to some module or its public interface.

That methods seem to have names is a illusion caused by the short hand
syntax

    (define-method (open arg ...) ...)

which really means

    (add-method! open (make-method '(...) (lambda (...) ...)))

That is, methods don't really have names just as

    (define foo (lambda () ...))

does not really define a function named "foo".  It defines a new
variable, makes it accessible under the name "foo" and initializes it
with a value that is a function.

The variable that holds a generic function object and the generic
function object are very different things, and trying to conflate the
two runs counter to very fundamental Scheme semantics.

I can see that people might want to have their generic functions
merged, but I can't really understand why they want it to happen
magically, automatically, based on dubious interpretations of what
functions in Scheme are about.  To be able to do something in this
direction, we would have to stop treating generic functions as
ordinary functions and first class objects.  That would be very wrong.



reply via email to

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