I've just hit an easy-to-fix compilation problem due
to a change in compiler behaviour between releases.
In the previous release a method definition with no
associated defgeneric like
(defmethod conformance-error PROGN ((arg my-class))
(do-something))
would compile quite happily, generating a generic-function
for PROGN method combination. However, it now generates
a standard-method combination generic-function and so
immediately breaks because the method is incompatible with
the generic-function created by the processing of this defmethod
form.
Huh? This looked broken to me, but checking the HyperSpec it says
(uppercasing is mine):
If (fboundp function-name) is nil, a generic function is created WITH
DEFAULT VALUES for the argument precedence order (each argument is more
specific than the arguments to its right in the argument list), for the
generic function class (the class standard-generic-function), for the method
class (the class standard-method), and FOR THE METHOD COMBINATION TYPE (THE
STANDARD METHOD COMBINATION TYPE). The lambda list of the generic function
is congruent with the lambda list of the method being defined; if the
defmethod form mentions keyword arguments, the lambda list of the generic
function will mention ..... key (but no keyword arguments). If function-name
names an ordinary function, a macro, or a special operator, an error is
signaled.
so this is actually conformant behaviour (unless I'm completely misreading
the spec).
Question: does anyone have any ideas as to why implicit
generic-function generation was spec'd this way? The old compiler
behaviour seemed much more intuitive and useful, but maybe I'm missing
some subtle point here...
From: Kent M Pitman
Subject: Re: Implicit GF creation - a spec rationale question
Date:
Message-ID: <sfwr9wrx791.fsf@world.std.com>
Guy Footring <········@thcsv01.trafford.ford.com> writes:
> I've just hit an easy-to-fix compilation problem due
> to a change in compiler behaviour between releases.
for varying values of "easy" and "fix".
incidentally, i think it's good hygiene in discussions of this kind
to add the phrase "of the implementation i'm using" to sentences
like yours quoted here. or even to specify the implementation name
AND version. too many people are too confused about the difference
between the language and its implementations, and using explicit
markers to separate those does a service to the community, especially
those you may not be directly addressing but who may just be "following
along", by encouraging them to make the implementation/language
distinction.
(also, your message is ambiguous as to whether you think it's easy for
you to fix or easy for a vendor to fix; if you think it's the former,
you're probably right--if the latter, well... politics, semantics,
etc. makes that ... unlikely)
> does anyone have any ideas as to why implicit
> generic-function generation was spec'd this way? The old compiler
> behaviour seemed much more intuitive and useful, but maybe I'm missing
> some subtle point here...
It might be to trap syntax errors. Consider the case of
(defmethod conformance-error arg (do-something))
Personally, I think it's a bad idea to do implicit creation of gf's at
all. The problem is that the system doesn't know if the first
reference is correct. It can end up flagging the error at some goofy
place (e.g., a later correct defmethod after an earlier incorrect one)
in a way that really confuses people who don't know what's going on.
I don't know if any of this was the rationale for the decision. CLOS
was designed as a monolith by a small group of people who were
paranoid about my even changing tiny wording things in that part of
the standard, so it's pretty much as it was delivered from the
subcommittee except where explicit votes changed things. Asking
someone on that committee might yield some useful insight. Not sure
if any of them read this newsgroup. A list of who was on that committee
is probably in the credits section of the spec (and, therefore, the
hyperspec).
But I happen to think that the present behavior is the right behavior,
for the reasons I cited, if indeed you allow auto-gf creation at all.
From: Howard R. Stearns
Subject: Re: Implicit GF creation - a spec rationale question
Date:
Message-ID: <3615120D.CB4F3F72@elwood.com>
Kent M Pitman wrote:
> ...
> Personally, I think it's a bad idea to do implicit creation of gf's at
> all. The problem is that the system doesn't know if the first
> reference is correct. It can end up flagging the error at some goofy
> place (e.g., a later correct defmethod after an earlier incorrect one)
> in a way that really confuses people who don't know what's going on.
> ...
I also think that it is helpful style for programmers to provide
explicit defgeneric forms. For example, doing so can allow a language
translator like Eclipse to define the dispatching function as an
ordinary named function in the target language. Expecting the compiler
to do this without an explicit, user-provided degeneric form raises the
issue of "which file should the dispatching function be defined in?"
Nonetheless, it strikes me as hardship to REQUIRE that users provide
explicit defgeneric forms. For example, I can't imagine how one would
modularize accessor functions. Which file does the defgeneric form
belong in? The "first" one in which a defclass with the given accessor
appears? Which is "first"? Does their need to be a separate
"gfdcl.lisp" in which all defgenerics are defined for each application?
(The analogy to "pkgdcl.lisp" files for defining "all the symbols" used
by an application is important. Even a pkgdcl allows individual files
to intern their own symbols as needed. That is, it isn't necessary to
define all symbols in a defpackage, only those that are exported,
imported, shadowed, etc.)
Kent M Pitman <······@world.std.com> writes:
>
> Guy Footring <········@thcsv01.trafford.ford.com> writes:
>
> > I've just hit an easy-to-fix compilation problem due
> > to a change in compiler behaviour between releases.
>
> for varying values of "easy" and "fix".
>
> incidentally, i think it's good hygiene in discussions of this kind
> to add the phrase "of the implementation i'm using" to sentences
> like yours quoted here. or even to specify the implementation name
> AND version. too many people are too confused about the difference
> between the language and its implementations, and using explicit
> markers to separate those does a service to the community, especially
> those you may not be directly addressing but who may just be "following
> along", by encouraging them to make the implementation/language
> distinction.
>
Apologies for unduly loose use of language - when I talk about a compiler
I implicitly think I'm talking about an implementation, but I'll endeavour
to be more explicit in future posts. Now that it's pointed out I can see
the ambiguity in "easy-to-fix" too.
The change in behaviour was between Harlequin's LWW4.01 and LWW4.1beta
releases.
> (also, your message is ambiguous as to whether you think it's easy for
> you to fix or easy for a vendor to fix; if you think it's the former,
> you're probably right--if the latter, well... politics, semantics,
> etc. makes that ... unlikely)
>
Easy for me to correct the existing code to conform to the standard.
> > does anyone have any ideas as to why implicit
> > generic-function generation was spec'd this way? The old compiler
> > behaviour seemed much more intuitive and useful, but maybe I'm missing
> > some subtle point here...
>
> It might be to trap syntax errors. Consider the case of
> (defmethod conformance-error arg (do-something))
>
> Personally, I think it's a bad idea to do implicit creation of gf's at
> all. The problem is that the system doesn't know if the first
> reference is correct. It can end up flagging the error at some goofy
> place (e.g., a later correct defmethod after an earlier incorrect one)
> in a way that really confuses people who don't know what's going on.
>
> I don't know if any of this was the rationale for the decision.
That doesn't look like a reasonable design decision to me since the same
problem occurs if I erroneously define a standard-method-combination method
before a correct non-standard-combination method. Also the current
behaviour confused the hell out of me for a while (admittedly that was
because of previous experience of the behaviour defmethod rather than
necessarily being intrinsic to the behaviour itself, although a better error
message might have prevented the confusion).
> CLOS
> was designed as a monolith by a small group of people who were
> paranoid about my even changing tiny wording things in that part of
> the standard, so it's pretty much as it was delivered from the
> subcommittee except where explicit votes changed things. Asking
> someone on that committee might yield some useful insight. Not sure
> if any of them read this newsgroup. A list of who was on that committee
> is probably in the credits section of the spec (and, therefore, the
> hyperspec).
>
> But I happen to think that the present behavior is the right behavior,
> for the reasons I cited, if indeed you allow auto-gf creation at all.
Thanks for the comments.
In article <··············@thcsv01.trafford.ford.com>,
Guy Footring <········@ford.com> wrote:
>Question: does anyone have any ideas as to why implicit
>generic-function generation was spec'd this way? The old compiler
>behaviour seemed much more intuitive and useful, but maybe I'm missing
>some subtle point here...
The same method qualifier could be used by multiple method combination type
(for instance, most of them support :AROUND methods). Since the qualifier
doesn't necessarily identify a unique method combination type, which one
would you propose it use? Since the standard method combination type is
the default for defgeneric, it was specified as the default for when the
implicit defgeneric is done.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Barry Margolin <······@bbnplanet.com> writes:
>
> In article <··············@thcsv01.trafford.ford.com>,
> Guy Footring <········@ford.com> wrote:
> >Question: does anyone have any ideas as to why implicit
> >generic-function generation was spec'd this way? The old compiler
> >behaviour seemed much more intuitive and useful, but maybe I'm missing
> >some subtle point here...
>
> The same method qualifier could be used by multiple method combination type
> (for instance, most of them support :AROUND methods). Since the qualifier
> doesn't necessarily identify a unique method combination type, which one
> would you propose it use? Since the standard method combination type is
> the default for defgeneric, it was specified as the default for when the
> implicit defgeneric is done.
>
I'm not sure that I find that answer very satisfactory. I fully agree that
in the absence of any information to direct the compiler that a default is
needed and that standard-method-combination is a reasonable default. The
:AROUND case is also something I hadn't considered before I posted, but when
it's not a case of filling in the blanks since all the information is
available in the method signature it seems odd to then ignore it. The spec
as it stands doesn't directly say that writing a method
(defmethod conformance-error PROGN ((arg my-class))
(do-something))
with no associated defgeneric is an error, but it does specify a sequence of
actions that implicitly makes it so. I guess that this then becomes a
quality of implementation issue: does your compiler complain that this usage
is illegal or does it simply perform the dictated actions and give a
somewhat less useful message. I'd better go be a good a lisp citizen and
send an appropriate email to the lisp vendor....
> --
> Barry Margolin, ······@bbnplanet.com
> GTE Internetworking, Powered by BBN, Burlington, MA
> *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Anyway, thanks for the response.