[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] *features*
From: |
Michael Koehne |
Subject: |
Re: [Gcl-devel] *features* |
Date: |
Fri, 16 Apr 2004 16:21:01 +0200 |
User-agent: |
Mutt/1.3.28i |
Moin Paul F. Dietz,
It was trivial to patch gcl/h/*-linux.h to show LINUX I386 instead
of MC68020 BSD386.
> From the CLHS, '*FEATURES*' page:
>
> "Symbols in the features list may be in any package, but in practice
> they are generally in the KEYWORD package. This is because KEYWORD
> is the package used by default when reading feature expressions
> in the #+ and #- reader macros. Code that needs to name a feature
> in a package P (other than KEYWORD) can do so by making explicit use
> of a package prefix for P, but note that such code must also assure
> that the package P exists in order for the feature expression to be
> read---even in cases where the feature expression is expected to
> fail."
I also found that place - but making all features keywords opened
a can of worm [1] in pcl and clcs. So I had to agree to my gecko [2]
that its getting dawn and there are enough bugs [3] to hunt the
next nights.
The question here : are those features who are not in the keyword
package contrary to the ANSI spec's, or just against my feeling
about the beauty of source ? So are they a must be fixed or something
that should better not touched ?
: Since features are normally symbols in the KEYWORD package where name
: collisions might easily result, and since no uniquely defined mechanism
: is designated for deciding who has the right to use which symbol for what
: reason, a conservative strategy is to prefer names derived from one's
: own company or product name, since those names are often trademarked and
: are hence less likely to be used unwittingly by another implementation.
ECL does not claim to be AKCL, even if its from same origin. Instead :
> *features*
(:LINUX :IEEE-FLOATING-POINT :UNIX :DLOPEN :CLOS :BOEHM-GC :ECL
:COMMON :ANSI-CL :COMMON-LISP :I486)
I wonder what happens, if gcl drops claiming to be AKCL and KCL also.
Bye Michael
[1] ECL's c/main.c is using make_keywords in the ADD_FEATURE definition,
while GCL is using make_ordinary. PCL will try to use the AKCL patches,
and fails the first time when building saved_gcl_pcl. The workaround
to drop the PCL *feature* in pcl/makefile wont work any longer, as its
now :PCL. Later saved_clcs_gcl suddenly stopped supporting the -compile
command line option. Typing (quit) was the only option to leave there.
[2] Hemidactylus turcicus
[3] Acheta domesticus
--
mailto:address@hidden UNA:+.? 'CED+2+:::Linux:2.4.22'UNZ+1'
http://www.xml-edifact.org/ CETERUM CENSEO WINDOWS ESSE DELENDAM
- Re: [Gcl-devel] 2.6.2....., (continued)
Re: [Gcl-devel] 2.6.2....., Camm Maguire, 2004/04/16
RE: [Gcl-devel] 2.6.2....., Billinghurst, David (CALCRTS), 2004/04/15
- Re: [Gcl-devel] *features*, Michael Koehne, 2004/04/15
- Re: [Gcl-devel] *features*, Paul F. Dietz, 2004/04/16
- Re: [Gcl-devel] *features*,
Michael Koehne <=
- Re: [Gcl-devel] *features*, Camm Maguire, 2004/04/16
- Message not available
- [Gcl-devel] Re: *features* - patch, Camm Maguire, 2004/04/19
- [Gcl-devel] Re: *features* - patch, Michael Koehne, 2004/04/19
- Message not available
- [Gcl-devel] Re: delayed pathname.d patch, Camm Maguire, 2004/04/22
- RE: [Gcl-devel] Re: delayed pathname.d patch, Mike Thomas, 2004/04/22
- RE: [Gcl-devel] Re: delayed pathname.d patch, Bill Page, 2004/04/22
- Re: [Gcl-devel] Re: delayed pathname.d patch, Camm Maguire, 2004/04/23
- RE: [Gcl-devel] Re: delayed pathname.d patch, Mike Thomas, 2004/04/27
- Re: [Gcl-devel] Re: delayed pathname.d patch, Camm Maguire, 2004/04/23
- RE: [Gcl-devel] Re: delayed pathname.d patch, Mike Thomas, 2004/04/27