[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


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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]