Shouldn't file-error-pathname be an accessor for file-error, instead
of a function? For those with out the CLHS handy, file-error has a
slot called pathname, and file-error-pathname is supposed to return
the contents of this slot.
Is it permissible for conforming implementations to "upgrade" regular
functions to generic functions?
--
UN-altered reproduction and DISSEMINATION of this IMPORTANT information is
ENCOURAGED
From: Tim Bradshaw
Subject: Re: file-error and file-error-pathname
Date:
Message-ID: <ey3u2bbphkk.fsf@cley.com>
* Xenophon Fenderson the Carbon(d)ated wrote:
> Shouldn't file-error-pathname be an accessor for file-error, instead
> of a function? For those with out the CLHS handy, file-error has a
> slot called pathname, and file-error-pathname is supposed to return
> the contents of this slot.
FILE-ERROR conditions don't have any documented slots: there's an
initarg and a reader function. There probably is a slot in there, but
it could be called anything.
> Is it permissible for conforming implementations to "upgrade" regular
> functions to generic functions?
Whether it is in the completely general case I'm not sure, but I'm
sure it would be in this case. In Allegro FILE-ERROR-PATHNAME is
generic.
(by `upgrade' I assume you mean that something that in the standard is
described as a function is in fact a generic function in the
implementation).
--tim
In article <···············@lovecraft.irtnog.org>,
Xenophon Fenderson the Carbon(d)ated <········@irtnog.org> wrote:
>Shouldn't file-error-pathname be an accessor for file-error, instead
>of a function? For those with out the CLHS handy, file-error has a
>slot called pathname, and file-error-pathname is supposed to return
>the contents of this slot.
>
>Is it permissible for conforming implementations to "upgrade" regular
>functions to generic functions?
Common Lisp does not require CLOS to be used to implement the conditions
system. It was designed independently of CLOS. This was done for
historical reasons (in case the CLOS proposal wasn't adopted, we didn't
want to have to redesign the condition system) and also for implementation
ease (CLOS uses the condition system, so there would be a circular
dependency).
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
········@irtnog.org (Xenophon Fenderson the Carbon(d)ated) writes:
> Shouldn't file-error-pathname be an accessor for file-error, instead
> of a function? For those with out the CLHS handy, file-error has a
> slot called pathname, and file-error-pathname is supposed to return
> the contents of this slot.
>
The relationship between CLOS and conditions is fairly complex in ANSI
CL. Look at 9.2 Condition Type Condition for the restrictions. Issue
CLOS-CONDITIONS:INTEGRATE giveth full integration but issues
CLOS-CONDITIONS-AGAIN:ALLOW-SUBSET and CONDITION-SLOTS:HIDDEN take
away most of this. In fact, I can't find it in the CLHS that
conditions have to be subclasses of STANDARD-CLASS.
> Is it permissible for conforming implementations to "upgrade" regular
> functions to generic functions?
Interesting question. Section 1.4.4.14 in combination with the
glossary entries for `function' and `standard generic function' would
seem to indicate that implementations can do this.
--
Lieven Marchand <···@bewoner.dma.be>
Lambda calculus - Call us a mad club
Lieven Marchand <···@bewoner.dma.be> writes:
> > Is it permissible for conforming implementations to "upgrade" regular
> > functions to generic functions?
>
> Interesting question. Section 1.4.4.14 in combination with the
> glossary entries for `function' and `standard generic function' would
> seem to indicate that implementations can do this.
I'd like to hear more about this. At first thought, it doesn't seem
like a wise move, but I'd like to hear more.
Also, it might take some extra effort to do so. For example,
functions like #'LENGTH and #'WRITE-SEQUENCE which already handle
typecase dispatch internally on sequences, etc.
One of the interesting things about Dylan is that all functions are
generic (if I remember right).
At first thought, this does sound like a plus as well as a
simplification. I havn't given it much thought though.
dave
From: Tim Bradshaw
Subject: Re: file-error and file-error-pathname
Date:
Message-ID: <ey3hf7au8r0.fsf@cley.com>
* David Bakhash wrote:
> I'd like to hear more about this. At first thought, it doesn't seem
> like a wise move, but I'd like to hear more.
I don't see why it makes any difference. If the implementation
chooses to make a given function generic it's pretty much
user-invisible, In particular, just because it's a GF doesn't license
the user to add methods to it. It's really an implementation detail.
--tim