Most of the documentation I see of packages really only addresses the
use of the declaration of "Here is the metadata about _this_ package,"
as opposed to indicating "Here's how you might _use_ that metadata."
The nearest thing to that seems to be in the "provide/require"
functions, which have, unfortunately, been deprecated.
Is it normal for people to define something that provides local
conventions akin to what one might use (PROVIDE) for?
As a "for instance," I'd rather like to have the Series function set
available for use.
Between three different environments I happen to use, there are three
different ways I might access it, and I'd rather prefer to be able to
do something like starting by loading in a sort of "directory"
indicating where Stuff Like Series can be found, and then use
something like (require 'series) to request Series in those cases
when I need it. Ditto for other packages.
--
(concatenate 'string "cbbrowne" ·@" "acm.org")
<http://www.ntlug.org/~cbbrowne/>
"Intel engineering seem to have misheard Intel marketing strategy. The
phrase was ``Divide and conquer'' not ``Divide and cock up''"
-- <······@www.linux.org.uk> Alan Cox
········@news.hex.net (Christopher Browne) writes:
> Between three different environments I happen to use, there are three
> different ways I might access it, and I'd rather prefer to be able to
> do something like starting by loading in a sort of "directory"
> indicating where Stuff Like Series can be found, and then use
> something like (require 'series) to request Series in those cases
> when I need it. Ditto for other packages.
mk:defsystem does this: it changes the definition of
provide/require so that (require :foo) will try to load the defsystem
file "foo.system" from a particular place (*central-registry*).
--
Raymond Wiker
·············@fast.no
On Tue, 03 Oct 2000 00:38:51 GMT, ········@news.hex.net (Christopher
Browne) wrote:
> Between three different environments I happen to use, there are three
> different ways I might access it, and I'd rather prefer to be able to
> do something like starting by loading in a sort of "directory"
> indicating where Stuff Like Series can be found, and then use
> something like (require 'series) to request Series in those cases
> when I need it. Ditto for other packages.
This looks like the kind of problem that Marco Antoniotti's
DEFCONFIGURATION is intended to solve. The tool is part of CLOCC (Common
Lisp Open Code Collection):
http://clocc.sourceforge.net/
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Paolo Amoroso <·······@mclink.it> writes:
> On Tue, 03 Oct 2000 00:38:51 GMT, ········@news.hex.net (Christopher
> Browne) wrote:
>
> > Between three different environments I happen to use, there are three
> > different ways I might access it, and I'd rather prefer to be able to
> > do something like starting by loading in a sort of "directory"
> > indicating where Stuff Like Series can be found, and then use
> > something like (require 'series) to request Series in those cases
> > when I need it. Ditto for other packages.
>
> This looks like the kind of problem that Marco Antoniotti's
> DEFCONFIGURATION is intended to solve. The tool is part of CLOCC (Common
> Lisp Open Code Collection):
>
> http://clocc.sourceforge.net/
>
Since I am putting my money where my mouth is, I must say that I just
found a buglet in the current implementation. It is not as flexible
as I want it. It is good that I did not put it up for download as a
File Release yet. I will as soon as I fix this bug.
BTW. CL.ENVIRONMENT is available for download.
It seems that soirceforge is messing up the uploading of *.lisp
files. Hence 'defsystem.lisp' may not be available. I am reporting
this to Sourceforge to fix the problem.
Cheers
--
Marco Antoniotti =============================================================
NYU Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp