file-error and file-error-pathname 
Author Message
 file-error and file-error-pathname

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



Sat, 08 Mar 2003 03:00:00 GMT  
 file-error and file-error-pathname

Quote:
> 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.

Quote:
> 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



Sun, 09 Mar 2003 03:00:00 GMT  
 file-error and file-error-pathname


Quote:
>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).

--

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.



Sun, 09 Mar 2003 03:00:00 GMT  
 file-error and file-error-pathname

Quote:
> 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.

Quote:
> 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.

--

Lambda calculus - Call us a mad club



Sun, 09 Mar 2003 03:00:00 GMT  
 file-error and file-error-pathname

Quote:

> > 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



Sun, 09 Mar 2003 03:00:00 GMT  
 file-error and file-error-pathname

Quote:

> 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



Sun, 09 Mar 2003 03:00:00 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. Error(36) Invalid Data file / Error: Invalid Record Declaration

2. Intermittant Error 37 File Not Open Error on Network

3. Error brwosing files in Dictionary - error 13

4. Windows XP file access errors (View open error)

5. Error (513): Internal error 13 (try to browse a pervasive file from dct in C5)

6. Sporadic GPIB Read Error 6, Generic File I/O Error

7. ABC File Access Error - Key File is invalid

8. error while importing a extaernal file into the DCT file

9. CW2.003 - file errors on Clarion file - HELP!

10. Halt-File Access Error: Which file?

11. error 37 File not open using a variable file name

12. Multi DLL with Variable File Name, got Invalid Data File(36) error

 

 
Powered by phpBB® Forum Software