On Fri, Aug 19, 2011 at 11:49 AM, Didier Verna <did...@lrde.epita.fr> wrote:
> Juan Jose Garcia-Ripoll <juanjose.garciarip...@googlemail.com> wrote:
>
> > I have been reading the CDR documents and none of them seems to
> > mandate the inclusion of some feature to signal the presence of a CDR
> > in an implementation. *features* right now is quite populated and I
> > would not want to fill it with further names that may collide with
> > other users's. Does anybody have a strong opinion or is better
> > informed than me in this respect?
>
> We had a short discussion about this on the CDR mailing list when I
> issued the "File Local Variables" CDR. See:
> http://lists.common-lisp.net/pipermail/cdr-discuss/2011-April/thread.html
>
I see both things mentioned:
- Adding :CDRnn or :CDR-nn to *features*
- Making the symbols live in some package.
The first one is not agreed upon. Each one says a different name and a vague
reference to CDR recommending this does not lead to any document. This is
problematic.
The second thing solves a different problem: conflicts among extensions. But
this is not our case. ECL's CDR symbols now live in EXT and do not conflict
with anything. I see, however, a potential need for packages to solve
clashes among versions, but this does not seem to be a problem with CDR
right now.
So we still have two problems (determining the existence of a CDR extension
or not, and using it through appropriate names) but no convention has been
mandated. What do other implementations do?
Juanjo
--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
_______________________________________________
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list
