[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] *features*
From: |
Camm Maguire |
Subject: |
Re: [Gcl-devel] *features* |
Date: |
16 Apr 2004 15:19:42 -0400 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
Greetings!
Michael Koehne <address@hidden> writes:
> 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 ?
>
I think from the above that the only question of compilance here is
that we're not using the explicit package prefix, e.g. lisp::.... But
we might as well make them working keywords if we want to make a
change like this anyway.
> : 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.
>
See previous email here.
> 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.
Thanks for this. Will chase this down in 2.7.x. Please don't let me
forget.
Take care,
> [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
>
>
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
>
>
>
--
Camm Maguire address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
- 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, 2004/04/16
- Re: [Gcl-devel] *features*,
Camm Maguire <=
- 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
- Re: [Gcl-devel] Re: delayed pathname.d patch, Michael Koehne, 2004/04/27