The ANSI standard provides some symbols that should be present in the
features list of implementations for various features of the
implementation; examples are :ansi-cl, :ieee-floating-point, and so
on. The meanings of these are well defined and specified.
Less well specified (for obvious reasons) are features added when
various extensions or implementation details are present. Consider for
instance the Gray stream proposal, which is implemented in several
implementations.
How can one test for its presence? Well, as was recently discussed
here, (ignore-errors (find-class 'fundamental-stream)) would do[1],
along with other similarly clunky things. I think it would be nice,
though, if implementors would volunteer to push, say, :gray-streams
onto *features* when the extension is present (and, obviously, make
sure it's not there when the extension isn't loaded).
Is there any chance of this happening? I think it would be nice.
Thanks,
Christophe
[1] Though not in CMUCL
--
Jesus College, Cambridge, CB5 8BL +44 1223 524 842
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
Christophe Rhodes <·····@cam.ac.uk> writes:
> Less well specified (for obvious reasons) are features added when
> various extensions or implementation details are present. Consider for
> instance the Gray stream proposal, which is implemented in several
> implementations.
>
> How can one test for its presence? Well, as was recently discussed
> here, (ignore-errors (find-class 'fundamental-stream)) would do[1],
> along with other similarly clunky things. I think it would be nice,
> though, if implementors would volunteer to push, say, :gray-streams
> onto *features* when the extension is present (and, obviously, make
> sure it's not there when the extension isn't loaded).
>
> Is there any chance of this happening? I think it would be nice.
I think it's a good idea. And maybe at some point you could rely on
it. But keep in mind that as long as any implementation doesn't,
which includes any already-released version still being used after an
updated release is issued, you still have to do the (ignore-errors
...) or you're making your code less portable by relying on the #+/#-
stuff. In other words, it's very difficult to beat down prior problems
after-the-fact.
Normally the way I recommend people do this is to have a foothold step
at the start of a system that does
(eval-when (:execute :compile-toplevel :load-toplevel)
(when (ignore-errors (find-class (read-from-string
"STREAM:FUNDAMENTAL-STREAM")))
(push :gray-streams *features*)))
or whatever, and then use #+gray-streams and #-gray-streams in
subsequent files.
And, of course, creators of new modules should consider pushing something
on *FEATURES* in their initial release, exactly because it's so hard to
do later.
Kent M Pitman <······@world.std.com> writes:
> And, of course, creators of new modules should consider pushing something
> on *FEATURES* in their initial release, exactly because it's so hard to
> do later.
I was never sure whether *features* was meant to be modified by users
or only by the implementation.
--
Lieven Marchand <···@wyrd.be>
Gla�r ok reifr skyli gumna hverr, unz sinn b��r bana.
Lieven Marchand <···@wyrd.be> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > And, of course, creators of new modules should consider pushing something
> > on *FEATURES* in their initial release, exactly because it's so hard to
> > do later.
>
> I was never sure whether *features* was meant to be modified by users
> or only by the implementation.
Oh, absolutely. Users are allowed to put stuff there. Lisp assumes that
life is a cascade of taking something from a vendor, adding value, and
reselling your value-added thing (usually as a loadable module, because vendor
licenses prohibit repackaging the whole system, but the effect is as if
to sell a layered system since the end user buys your programs + the original
system and then can layer their own). It is surely true that some users
just package stuff for end-users, adding a GUI, and losing the ability to
further extend. But the language is not designed around that model.
One issue that has hurt the use of *features* is the flat namespace. I
think at least three vendors picked :CCL as their key, and they have had
bad luck with code porting in and out using that key because #+CCL is
effectively meaningless.
Package names have the same problem.
Of late I name all my packages COM.mydomain.whatever just like Java does,
and I tell everyone to do the same. I guess I think this would not be a
bad practice for features either, though occasionally it will lead to the
need to cope with #+COM.HARLEQUIN.whatever becoming #+COM.XANALYS.whatever
and things like that. It still means not fighting over the "good names".
The fight used to be over the good "short names" since everyone wanted
#+{letter}CL (i.e., xcl, acl, scl, hcl, ...) but I actually think if we
made it socially unaccepable to use short names and we told people to use
long names, it might have the beneficial effect of encouraging people
not to use as many #+/- conditionals, leading to them being centralized
in abstractions faster rather than tolerated in-line in repeated places
in code.
So here I put out my first public call for everyone to use the following
new style rule:
Use com.yourdomain.yourname1.yourname2...yournameN for package names.
Use yournameN as a package short name if you want, but ONLY either
interactively (where you control the package names available interactively)
or during loading of a non-autoloaded module (since whoever's
loading can arrange to resolve package conflicts by calls to rename-package
to adjust the nicknames. If this isn't clear, consider an example where
there is a com.foo.xml and com.bar.xml. I think it's ok for you to give
both nicknames of xml, since if a conflict arises, one can just call
rename-package just before loading the second package with that short-name.
But the package's correct execution must not rely on
(intern "FOO" "XML") since by execution time, the package short name
may have been given up. instead, use (intern "FOO" "COM.FOO.XML") which
should be the package primary name and should not get renamed.
For features, use :com.yourdomain.yourname1...yournameN and
the corresponding #+/#-. Leave the undotted names to community-wide
standards like those dictated by ANSI CL.
We could establish a name registry at alu.org so that
org.alu.fredjones...
was available to Fred Jones if he had no domain name.
Does anyone think this would be a bad idea? I've been studying this issue
for a while, looking for a solution that would work without needing to change
the standard, and this is working for me in my private coding.
Kent M Pitman <······@world.std.com> wrote in message news:<···············@world.std.com>...
[...]
>
> We could establish a name registry at alu.org so that
> org.alu.fredjones...
> was available to Fred Jones if he had no domain name.
>
[...]
I like your suggestions and imho there should definitely be a registry
for this stuff. The Lisp community is small enough that this might
work (it seems to have worked for TCL). So, when someone wants to
release a module to the public, she or he should enter the package
name and the *features* key in this public registry to avoid name
collisions.
g
··········@my-deja.com (glauber) writes:
> Kent M Pitman <······@world.std.com> wrote in message news:<···············@world.std.com>...
> [...]
> >
> > We could establish a name registry at alu.org so that
> > org.alu.fredjones...
> > was available to Fred Jones if he had no domain name.
> >
> [...]
>
> I like your suggestions and imho there should definitely be a registry
> for this stuff. The Lisp community is small enough that this might
> work (it seems to have worked for TCL). So, when someone wants to
> release a module to the public, she or he should enter the package
> name and the *features* key in this public registry to avoid name
> collisions.
Well, the good thing about the way Java does it is that everyone can just
make up module names without registering them, because it's easy to know
how to generate a unique name. If you control foo.com, then the entire
com.foo.xxx namespace is yours.
We talked for a long time about a registry for CL, but I don't think it's
essential if we just use this style convention that Java so nicely created.
[I do think there are other advantages to registries, and I'm actually
involved in setting one up of my own, but I'm not ready to talk about the
details yet. Hopefully sometime this summer.]
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> writes:
> Well, the good thing about the way Java does it is that everyone can just
> make up module names without registering them, because it's easy to know
> how to generate a unique name. If you control foo.com, then the entire
> com.foo.xxx namespace is yours.
If you control the foo.com domain, why not use xxx.foo.com for the
features/packages? One could then put docs, code, etc at xxx.foo.com to
describe the thing. If you're going to base it upon domain names, at least
follow the domain name ordering.
Mike McDonald
·······@mikemac.com
·······@mikemac.com (Mike McDonald) writes:
> In article <···············@world.std.com>,
> Kent M Pitman <······@world.std.com> writes:
>
> > Well, the good thing about the way Java does it is that everyone can just
> > make up module names without registering them, because it's easy to know
> > how to generate a unique name. If you control foo.com, then the entire
> > com.foo.xxx namespace is yours.
>
> If you control the foo.com domain, why not use xxx.foo.com for the
> features/packages? One could then put docs, code, etc at xxx.foo.com to
> describe the thing. If you're going to base it upon domain names, at least
> follow the domain name ordering.
That's not how it's done in Java. The order is reversed. I can live with
that and it'd be annoying for there to be two competing conventions for
naming the same function.
I have hypermeta.com so I have packages named com.hypermeta.xml,
com.hypermeta.http.server, and so on. There is actually some logic to
this. They also in Java use directory structure to mirror. com.foo.x
works like com/foo/x so foo is a subdir of com, and x is a subdir of
foo, which is right, since if there is also a bar.com at your
location, then having com have a second subdir of bar (along with foo)
is the right inclusion relationship. You could argue, actually, that
it's the domain name system, not Java, that got this point wrong.
If we were doing this anew, I'd go with the normal domain ordering.
But ther are too many Java programmers out there to fight with, and it
doesn't matter to us yet now. So we should order it their way rather
than create a gratuitous incompatibility.
From: ···@uk.co.cley
Subject: Re: *features* for extensions
Date:
Message-ID: <nkjy9rpagmw.fsf@tfeb.org>
·······@mikemac.com (Mike McDonald) writes:
> If you control the foo.com domain, why not use xxx.foo.com for the
> features/packages? One could then put docs, code, etc at xxx.foo.com to
> describe the thing. If you're going to base it upon domain names, at least
> follow the domain name ordering.
>
That's because, as anyone who lives in the UK knows you idiot
americans got it all backwards. The ONE TRUE ordering of domain names
is left-to-right: uk.co.cley, for instance. Tell me, which way do you
write numbers? I thought so. Just because you invented the internet
(or so you claim, I have my doubts), you think you can dicatate your
mutant cretin right-to-left orderings to us. Well let me tell you we
won't stand for this: we've had enough of your colonial impudence, and
from now on people will write things the right way around. I hear you
drive on the wrong side of the $�RGY )( *U&&··@@
NO CARRIER
>>>>> "t" == tfb <···@uk.co.cley> writes:
t> NO CARRIER
There is this story that during the Falklands war, the message
CARRIER LOST
popped up on a terminal at the trading desk at an important financial
institution, and the pound dropped.
Jon K�re
···@uk.co.cley writes:
> ·······@mikemac.com (Mike McDonald) writes:
>
> > If you control the foo.com domain, why not use xxx.foo.com for the
> > features/packages? One could then put docs, code, etc at xxx.foo.com to
> > describe the thing. If you're going to base it upon domain names, at least
> > follow the domain name ordering.
> >
>
> That's because, as anyone who lives in the UK knows you idiot
> americans got it all backwards. The ONE TRUE ordering of domain names
> is left-to-right: uk.co.cley, for instance. Tell me, which way do you
> write numbers? I thought so. Just because you invented the internet
> (or so you claim, I have my doubts), you think you can dicatate your
> mutant cretin right-to-left orderings to us. Well let me tell you we
> won't stand for this: we've had enough of your colonial impudence, and
> from now on people will write things the right way around. I hear you
> drive on the wrong side of the $�RGY )( *U&&··@@
>
> NO CARRIER
Oh yeah! What about miles and feet and inches and stones and other
bogus units of measures?
Moreover, why driving on the left? And why should the UK have any
voting right on food matters (except maybe tea and beer) within the
EU? :)
Cheers
BTW. AFAIK only the Japanese get dates right: today is 2001-05-22.
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
On 22 May 2001 10:42:32 -0400, Marco Antoniotti <·······@cs.nyu.edu>
wrote:
>Moreover, why driving on the left? And why should the UK have any
>voting right on food matters (except maybe tea and beer) within the
>EU? :)
Definitely not beer 8-)
George
On Fri, 18 May 2001 23:10:09 GMT, Kent M Pitman <······@world.std.com>
wrote:
>Well, the good thing about the way Java does it is that everyone can just
>make up module names without registering them, because it's easy to know
>how to generate a unique name. If you control foo.com, then the entire
>com.foo.xxx namespace is yours.
The operative being control of the domain. What happens when (the
hypothetical you) your venture goes belly up and its cutesy domain (or
worse alias) gets recycled?
The odds are good that lost domains will be snapped up by those in a
closely related niche - increasing the odds of confusion if
identically named packages are somehow released.
AFAIK it hasn't happened yet, but for two years nearly Internet Week
featured someone moaning about how all the juicy domain names suitable
for their app de jur had been taken already. Lots of those companies
are shaky or out of business now. What happened to their software?
Knowing this is far less of an issue here, but just wanting to hear
your thoughts.
George
·······@dyn.com (George Neuner) writes:
> On Fri, 18 May 2001 23:10:09 GMT, Kent M Pitman <······@world.std.com>
> wrote:
>
> >Well, the good thing about the way Java does it is that everyone can just
> >make up module names without registering them, because it's easy to know
> >how to generate a unique name. If you control foo.com, then the entire
> >com.foo.xxx namespace is yours.
>
>
> The operative being control of the domain. What happens when (the
> hypothetical you) your venture goes belly up and its cutesy domain (or
> worse alias) gets recycled?
>
> The odds are good that lost domains will be snapped up by those in a
> closely related niche - increasing the odds of confusion if
> identically named packages are somehow released.
The odds are not fundamentally changed from any other venture you might have.
Right now if I take the SYMBOLICS-COMMON-LISP package and I Symbolics goes
belly up, the same situation applies.
If the another vendor buys the name planning to be in the same market area
without understanding there is an overlap, then that's naive. The rmoe likely
case is that they buy it to not do Lisp (no conflict there) or to pick up the
same set of packages (no conflict there).
Seems like a real non-issue to me.
Plus, stable organizations like ALU can sell space, as in
org.alu.pitman.foo or org.alu.neuner.bar
> AFAIK it hasn't happened yet, but for two years nearly Internet Week
> featured someone moaning about how all the juicy domain names suitable
> for their app de jur had been taken already. Lots of those companies
> are shaky or out of business now. What happened to their software?
>
> Knowing this is far less of an issue here, but just wanting to hear
> your thoughts.
My thoughts are that we could have much worse problems.
It's cheaper than us maintaining our own registry and just about as
reliable. No system is perfect. This one makes a piece of software's
name as stable as the entity that provides it. I don't think you can ask
much more than that.
From: George Neuner
Subject: Re: *features* for extensions
Date:
Message-ID: <3b157ae2.2515997@helice>
On Wed, 30 May 2001 01:21:41 GMT, Kent M Pitman <······@world.std.com>
wrote:
>If the another vendor buys the name planning to be in the same market area
>without understanding there is an overlap, then that's naive.
No question .. I would only observe that we have witnessed a shocking
amount of business naivete in recent times :)
George
··········@my-deja.com (glauber) writes:
> Kent M Pitman <······@world.std.com> wrote in message news:<···············@world.std.com>...
> [...]
> >
> > We could establish a name registry at alu.org so that
> > org.alu.fredjones...
> > was available to Fred Jones if he had no domain name.
> >
> [...]
>
> I like your suggestions and imho there should definitely be a registry
> for this stuff. The Lisp community is small enough that this might
> work (it seems to have worked for TCL). So, when someone wants to
> release a module to the public, she or he should enter the package
> name and the *features* key in this public registry to avoid name
> collisions.
I like the principle of Kent's idea, though my instinctive reaction
(shallow, I know) is "but that'll make lisp code look ugly!" (I would
prefer a looser system along the lines of :mk-defsystem, :db-sockets,
:csr-sendmail or whatever).
However, while we're on the community efforts, what would be wrong
with having <URL:http://ww.telent.net/cliki/features> as an interim
repository. It depends of course on trust, but I think that currently
the lisp community is small enough that such trust is not unwarranted.
So the idea is that the CLiki features page should be checked and
updated by implementors and module-writers who wish to use a feature;
in the event of disputes, well, how about shotguns at dawn?
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 524 842
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
Kent M Pitman <······@world.std.com> writes:
> One issue that has hurt the use of *features* is the flat namespace. I
> think at least three vendors picked :CCL as their key, and they have had
> bad luck with code porting in and out using that key because #+CCL is
> effectively meaningless.
>
> Package names have the same problem.
>
At least CL has enough tools to solve it without having to modify or
even have the original source. Languages without renaming facilities
can get very unwieldy.
> So here I put out my first public call for everyone to use the following
> new style rule:
>
> Use com.yourdomain.yourname1.yourname2...yournameN for package names.
>
Or tld.the.world.is.a.very.big.place where appropriate. Erik and I
have gotten nice combinations this way: if Erik would ever implement
scheme in CL, it could be put into no.naggum.scheme ;-)
> We could establish a name registry at alu.org so that
> org.alu.fredjones...
> was available to Fred Jones if he had no domain name.
>
> Does anyone think this would be a bad idea? I've been studying this issue
> for a while, looking for a solution that would work without needing to change
> the standard, and this is working for me in my private coding.
Sounds like a good idea.
--
Lieven Marchand <···@wyrd.be>
Gla�r ok reifr skyli gumna hverr, unz sinn b��r bana.
Lieven Marchand <···@wyrd.be> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > Use com.yourdomain.yourname1.yourname2...yournameN for package names.
> >
>
> Or tld.the.world.is.a.very.big.place where appropriate. Erik and I
> have gotten nice combinations this way: if Erik would ever implement
> scheme in CL, it could be put into no.naggum.scheme ;-)
Sure. You'll note I used org.xxx in one of my examples. I should have
said it better...
Too bad no country has a cctld of .cl ... :-)
Kent M Pitman <······@world.std.com> writes:
> Lieven Marchand <···@wyrd.be> writes:
>
> > Kent M Pitman <······@world.std.com> writes:
> >
> > > Use com.yourdomain.yourname1.yourname2...yournameN for package names.
> > >
> >
> > Or tld.the.world.is.a.very.big.place where appropriate. Erik and I
> > have gotten nice combinations this way: if Erik would ever implement
> > scheme in CL, it could be put into no.naggum.scheme ;-)
>
> Sure. You'll note I used org.xxx in one of my examples. I should have
> said it better...
>
> Too bad no country has a cctld of .cl ... :-)
Actually Chile does:
.cl - Chile
Sponsoring organization:
NIC Chile (University of Chile)
Blanco Encalada 2120
Santiago 651 1224
Chile
Administrative contact:
Patricio Poblete
NIC Chile
University of Chile
Blanco Encalada 2120
Santiago, 651 1224
Chile
E-mail: ········@nic.cl
Voice: +56 2 689 2736
Fax: +56 2 689 7998
Technical contact:
Jose Piquer
NIC Chile
University of Chile
Blanco Encalada 2120
Santiago, 651 1224
Chile
E-mail: ·······@nic.cl
Voice: +56 2 689 2736
Fax: +56 2 689 7998
URL for registration services: http://www.nic.cl/
Record last updated - 30-July-99
Record created - 27-January-95
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
"Pierre R. Mai" <····@acm.org> writes:
>> Too bad no country has a cctld of .cl ... :-)
> Actually Chile does:
> .cl - Chile
And they'll willingly give you domains, too. We got b.cl. (So that
we can reach boxes with fewer keystrokes.:)
--
johs <·@b.cl>
On Fri, 18 May 2001 16:14:20 GMT, Kent M Pitman <······@world.std.com>
wrote:
> So here I put out my first public call for everyone to use the following
> new style rule:
>
> Use com.yourdomain.yourname1.yourname2...yournameN for package names.
Do you have any guidelines for package nicknames?
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Paolo Amoroso <·······@mclink.it> writes:
>
> On Fri, 18 May 2001 16:14:20 GMT, Kent M Pitman <······@world.std.com>
> wrote:
>
> > So here I put out my first public call for everyone to use the following
> > new style rule:
> >
> > Use com.yourdomain.yourname1.yourname2...yournameN for package names.
>
> Do you have any guidelines for package nicknames?
My feeling is that package nicknames should be used only for backward
compatibility (not for new code), and should only be used in the special
ways I outlined (for short names)--that is, only for use interactively
and at load time. As long as you do that, it shouldn't matter what names
you use.
If I could change CL, what I'd do would be to say that the package name
cannot change and that any time a new package comes along with a nickname
that collides with an old one, it's redefined to point to the new package.
I can't make that change, but people can program as if they are guarding
against that. So packages should think of their nicknames as having only
fleetingly reliable duration.
Kent M Pitman <······@world.std.com> writes:
> Christophe Rhodes <·····@cam.ac.uk> writes:
>
> > How can one test for its presence? Well, as was recently discussed
> > here, (ignore-errors (find-class 'fundamental-stream)) would do[1],
> > along with other similarly clunky things. I think it would be nice,
> > though, if implementors would volunteer to push, say, :gray-streams
> > onto *features* when the extension is present (and, obviously, make
> > sure it's not there when the extension isn't loaded).
> >
> > Is there any chance of this happening? I think it would be nice.
>
> I think it's a good idea. And maybe at some point you could rely on
> it.
Well, it would certainly make my life as a (hobbyist) software writer
easier.
> But keep in mind that as long as any implementation doesn't,
> which includes any already-released version still being used after an
> updated release is issued, you still have to do the (ignore-errors
> ...) or you're making your code less portable by relying on the #+/#-
> stuff. In other words, it's very difficult to beat down prior problems
> after-the-fact.
This is of course very true. However, I think that it is perhaps worth
trying to combat the inertia of a large number of people by making
them think about these things.
Maybe at this point I should `advertise' the existence of Dan Barlow's
CL Wiki-a-like[1]; in particlular, there exists a page at
<URL:http://ww.telent.net/cliki/features> which is a start at
cataloguing the various eccentricities of implementations. I think it
would be a great help if information about various implementations
were kept somewhere, and it seems to me that CLiki is as good a place
as any to keep it. Bear in mind, of course, that anyone can edit
anything on that site...
> Normally the way I recommend people do this is to have a foothold step
> at the start of a system that does
>
> (eval-when (:execute :compile-toplevel :load-toplevel)
> (when (ignore-errors (find-class (read-from-string
> "STREAM:FUNDAMENTAL-STREAM")))
> (push :gray-streams *features*)))
>
> or whatever, and then use #+gray-streams and #-gray-streams in
> subsequent files.
Indeed. This kind of thing is unpretty, but `works'. The reason I'm
slightly hesitant about this approach is from my experience with
MK-DEFSYSTEM (a freely available defsystem[2]); the code is so full of
read-time conditionals that it's really quite hard to figure out what
on earth will be executed, particularly since it manipulates the
*features* list quite aggressively at compile-time. I am in the
process of editing that defsystem with the assumption that it is
running on an ANSI CL, in the hope that this will make it easier to
understand...
> And, of course, creators of new modules should consider pushing something
> on *FEATURES* in their initial release, exactly because it's so hard to
> do later.
Absolutely. I would love it if module writers not only modified the
*features* list but also advertised this fact, on CLiki if nowhere
else.
Cheers.
Christophe
[1] http://ww.telent.net/cliki
[2] http://clocc.sourceforge.net/
--
Jesus College, Cambridge, CB5 8BL +44 1223 524 842
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
Christophe Rhodes <·····@cam.ac.uk> writes:
> > Normally the way I recommend people do this is to have a foothold step
> > at the start of a system that does
> >
> > (eval-when (:execute :compile-toplevel :load-toplevel)
> > (when (ignore-errors (find-class (read-from-string
> > "STREAM:FUNDAMENTAL-STREAM")))
> > (push :gray-streams *features*)))
> >
> > or whatever, and then use #+gray-streams and #-gray-streams in
> > subsequent files.
>
> Indeed. This kind of thing is unpretty, but `works'. The reason I'm
> slightly hesitant about this approach is from my experience with
> MK-DEFSYSTEM (a freely available defsystem[2]); the code is so full of
> read-time conditionals that it's really quite hard to figure out what
> on earth will be executed, particularly since it manipulates the
> *features* list quite aggressively at compile-time.
IMO, code should *never* be full of these things. You should always separate
your modules as much as possible to isolate non-portable things into a single
file or small number of files as part of the bootstrap layer, leaving the
meat to be done by a fully portable layer. So you don't repeat mention of
#+x "fasl" #-x "bin" all over the place, you instead defvar *blah-type*
at the start using those conditionals and then use *blah-type* throughout
the meat of the code.
I've reorganized some pretty large systems in this way and am convinced it
can be done in most or all cases. It's pretty clear to me that it's laziness
that leads to #+/#- being distributed into code. If you have an example of
something that's hard to do under this methodology, post it and we should
discuss it.
Kent M Pitman <······@world.std.com> writes:
> Christophe Rhodes <·····@cam.ac.uk> writes:
>
> > > Normally the way I recommend people do this is to have a foothold step
> > > at the start of a system that does
> > >
> > > (eval-when (:execute :compile-toplevel :load-toplevel)
> > > (when (ignore-errors (find-class (read-from-string
> > > "STREAM:FUNDAMENTAL-STREAM")))
> > > (push :gray-streams *features*)))
> > >
> > > or whatever, and then use #+gray-streams and #-gray-streams in
> > > subsequent files.
> >
> > Indeed. This kind of thing is unpretty, but `works'. The reason I'm
> > slightly hesitant about this approach is from my experience with
> > MK-DEFSYSTEM (a freely available defsystem[2]); the code is so full of
> > read-time conditionals that it's really quite hard to figure out what
> > on earth will be executed, particularly since it manipulates the
> > *features* list quite aggressively at compile-time.
>
> IMO, code should *never* be full of these things. You should always separate
> your modules as much as possible to isolate non-portable things into a single
> file or small number of files as part of the bootstrap layer, leaving the
> meat to be done by a fully portable layer. So you don't repeat mention of
> #+x "fasl" #-x "bin" all over the place, you instead defvar *blah-type*
> at the start using those conditionals and then use *blah-type* throughout
> the meat of the code.
>
> I've reorganized some pretty large systems in this way and am convinced it
> can be done in most or all cases. It's pretty clear to me that it's laziness
> that leads to #+/#- being distributed into code. If you have an example of
> something that's hard to do under this methodology, post it and we should
> discuss it.
I completely agree.
Please apologize my unabashedly self-promoting spree, but
CL-ENVIRONMENT and CL-CONFIGURATION do address exactly these
problems.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Christophe Rhodes <·····@cam.ac.uk> writes:
...
>
> Indeed. This kind of thing is unpretty, but `works'. The reason I'm
> slightly hesitant about this approach is from my experience with
> MK-DEFSYSTEM (a freely available defsystem[2]); the code is so full of
> read-time conditionals that it's really quite hard to figure out what
> on earth will be executed, particularly since it manipulates the
> *features* list quite aggressively at compile-time. I am in the
> process of editing that defsystem with the assumption that it is
> running on an ANSI CL, in the hope that this will make it easier to
> understand...
As the "caretaker" of MK:DEFSYSTEM I cannot but symphatize with your
predicament. CL-ENVIRONMENT came out as a reaction to the frustration
of dealing with MK:DEFSYSTEM read time conditionals. I thought: there
has to be a better way. Then remembered Sonya Keene's book and I went
on from there.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Kent M Pitman <······@world.std.com> writes:
> Christophe Rhodes <·····@cam.ac.uk> writes:
>
> > Less well specified (for obvious reasons) are features added when
> > various extensions or implementation details are present. Consider for
> > instance the Gray stream proposal, which is implemented in several
> > implementations.
> >
> > How can one test for its presence? Well, as was recently discussed
> > here, (ignore-errors (find-class 'fundamental-stream)) would do[1],
> > along with other similarly clunky things. I think it would be nice,
> > though, if implementors would volunteer to push, say, :gray-streams
> > onto *features* when the extension is present (and, obviously, make
> > sure it's not there when the extension isn't loaded).
> >
> > Is there any chance of this happening? I think it would be nice.
>
> I think it's a good idea. And maybe at some point you could rely on
> it. But keep in mind that as long as any implementation doesn't,
> which includes any already-released version still being used after an
> updated release is issued, you still have to do the (ignore-errors
> ...) or you're making your code less portable by relying on the #+/#-
> stuff. In other words, it's very difficult to beat down prior problems
> after-the-fact.
(Shameless plug) If you download CL-ENVIRONMENT from the CLOCC
(http://sourceforge.net/projects/clocc) you will have a package that
centralizes and (IMHO) rationalizes the handling of several
discrepancies among different implementations. Think 'config.guess'.
> Normally the way I recommend people do this is to have a foothold step
> at the start of a system that does
>
> (eval-when (:execute :compile-toplevel :load-toplevel)
> (when (ignore-errors (find-class (read-from-string
> "STREAM:FUNDAMENTAL-STREAM")))
> (push :gray-streams *features*)))
>
> or whatever, and then use #+gray-streams and #-gray-streams in
> subsequent files.
Excellent suggestion. I will add it to CL-ENVIRONMENT.
> And, of course, creators of new modules should consider pushing something
> on *FEATURES* in their initial release, exactly because it's so hard to
> do later.
Good suggestion as well. This is one for CL-CONFIGURATION.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > or whatever, and then use #+gray-streams and #-gray-streams in
> > subsequent files.
>
> Excellent suggestion. I will add it to CL-ENVIRONMENT.
>
> > And, of course, creators of new modules should consider pushing something
> > on *FEATURES* in their initial release, exactly because it's so hard to
> > do later.
>
> Good suggestion as well. This is one for CL-CONFIGURATION.
While it is all well and good for these kinds of utility to exist,
they are really only palliative remedies; much more useful in the
medium- to long-term is a community-based solution, I think, simply
because the "one utility managing differences between implementations"
kind of thing really doesn't scale well.
I hope to persuade those who aren't already persuaded that instead
that their lisp programmes do not exist in a vacuum, in the vague hope
of enhancing not just my but everyone's "lisp experience".
I'll drop the marketspeak now, and go back to writing code (and bug
reports...)
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 524 842
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
Christophe Rhodes <·····@cam.ac.uk> writes:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
> > Kent M Pitman <······@world.std.com> writes:
> >
> > > or whatever, and then use #+gray-streams and #-gray-streams in
> > > subsequent files.
> >
> > Excellent suggestion. I will add it to CL-ENVIRONMENT.
> >
> > > And, of course, creators of new modules should consider pushing something
> > > on *FEATURES* in their initial release, exactly because it's so hard to
> > > do later.
> >
> > Good suggestion as well. This is one for CL-CONFIGURATION.
>
> While it is all well and good for these kinds of utility to exist,
> they are really only palliative remedies; much more useful in the
> medium- to long-term is a community-based solution, I think, simply
> because the "one utility managing differences between implementations"
> kind of thing really doesn't scale well.
Of course the real solution would be to have the vendors and the
implementors to agree on, let's say, a FFI.
But, seriously. What does not scale well is (and now let me
weigh in my experience) the ad hoc mess that you see in the first part
of the MK:DEFSYSTEM, or the (well meaning, by all means) horror that
every once in a while you stumble upon in "load files" (mine included).
Having said that, I strongly believe that one of the problems with the
Common Lisp community is the lack of cross-implementations utilities.
I invite you to have a look at CL-CONFIGURATION (and CL-ENVRONMENT).
They are not perfect and I do not know how many people use them.
However, I have not received negative comments so far.
> I hope to persuade those who aren't already persuaded that instead
> that their lisp programmes do not exist in a vacuum, in the vague hope
> of enhancing not just my but everyone's "lisp experience".
I second that.
> I'll drop the marketspeak now, and go back to writing code (and bug
> reports...)
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.