Is it conforming for a vendor to define a function on an exported
symbol in package COMMON-LISP which is not specified in the standard
to have a function?
For example:
ACL 6.2 defines coercing functions SIMPLE-STRING, DOUBLE-FLOAT,
SINGLE-FLOAT, etc. CMUCL 18c defines FIXNUM which appears to be the
internal representation of a fixnum. CLISP 2.27 defines introspection
function SPACE. LWW 4.3 defines GENERIC-FUNCTION which I guess works
somehow like FUNCTION to cross the list structure/function barrier
(didn't investigate very much).
I certainly don't want to write my portable programs to employ
e.g. ACL's SIMPLE-STRING, but I get these anyway, since I need the
"standing" meanings of these symbols. I recognize that it's hard to
construe a case where this is harmful. It still seems oddly
asymmetric.
Andrew
From: Paul F. Dietz
Subject: Re: which symbols in package COMMON-LISP should be fboundp?
Date:
Message-ID: <9uGdnQqKRdfk7VvdRVn-uw@dls.net>
Andrew Philpot wrote:
> Is it conforming for a vendor to define a function on an exported
> symbol in package COMMON-LISP which is not specified in the standard
> to have a function?
No (with the understanding that macros and special operators can
also be fboundp). See section 12.1.2.1.1 of the ANSI standard.
Paul
From: Paul F. Dietz
Subject: Re: which symbols in package COMMON-LISP should be fboundp?
Date:
Message-ID: <9uGdnQWKRdcK7VvdRVn-uw@dls.net>
I wrote:
> No (with the understanding that macros and special operators can
> also be fboundp). See section 12.1.2.1.1 of the ANSI standard.
Err, 11.1.2.1.1, I meant.
Paul
From: Duane Rettig
Subject: Re: which symbols in package COMMON-LISP should be fboundp?
Date:
Message-ID: <4ise1z50l.fsf@franz.com>
Andrew Philpot <·······@isi.edu> writes:
> Is it conforming for a vendor to define a function on an exported
> symbol in package COMMON-LISP which is not specified in the standard
> to have a function?
No, it is not.
> For example:
>
> ACL 6.2 defines coercing functions SIMPLE-STRING, DOUBLE-FLOAT,
> SINGLE-FLOAT, etc.
Actually, I think these are the only ones. We had never documented
these, even though they were exported, and for 7.0 we've moved them
to internal symbols of different names in the excl package (but there
could easily be an autoloadable module to re-enable them for thos
who count on their definitions).
> I certainly don't want to write my portable programs to employ
> e.g. ACL's SIMPLE-STRING, but I get these anyway, since I need the
> "standing" meanings of these symbols. I recognize that it's hard to
> construe a case where this is harmful. It still seems oddly
> asymmetric.
It is asymmetric, and it goes against the spirit of the rule against
giving certain kinds of definitions to symbols in system packages -
if program A defines #'single-float, and program B defines
#'single-float with a different definition, which one should be
established? What if program A happened to come from the vendor?
What's the difference?
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
>>>>> "Andrew" == Andrew Philpot <·······@isi.edu> writes:
Andrew> Is it conforming for a vendor to define a function on an exported
Andrew> symbol in package COMMON-LISP which is not specified in the standard
Andrew> to have a function?
Andrew> For example:
Andrew> ACL 6.2 defines coercing functions SIMPLE-STRING, DOUBLE-FLOAT,
Andrew> SINGLE-FLOAT, etc. CMUCL 18c defines FIXNUM which appears to be the
Andrew> internal representation of a fixnum.
These issues in cmucl are fixed in the soon-to-be-released 19a and
also in recent monthly snapshots.
common-lisp.net is still being recovered, I think, so they're not
available from there, but you may find some binaries from the mirror
sites, which can be found on www.cons.org/cmucl.
Ray