"The functions PROVIDE and REQUIRE are deprecated." says CLHS.
So, how can we declare which packages are used by a given package?
In the case where package A inherits a package B, it's easy to find
out, B is listed in the :USE clause of package A. But when A uses the
package C with direct references to symbols such as C:STUFF, bar from
a parsing of the whole A package, how can we know that it needs C?
And I suppose that the A package could build dynamically such
references, the range of which may be known before hand or not. But
let's just try to be helpful in the normal case where the list of used
and referenced packages is static and known before hand.
(If the :USE argument of DEFPACKAGE specify the packages that are
_inherited_, why is it not called :INHERIT ?)
I'm trying to write a make-make, that is, I have packages, one per
file, and I want to build a Makefile to compile them. If you must
know, this is useful because there's no multiprogramming inside lisp,
so the various defsystem won't compile several files at the same time,
while make -p can do. Just to point one reason.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
Do not adjust your mind, there is a fault in reality.
From: Tim Bradshaw
Subject: Re: The functions provide and require are deprecated.
Date:
Message-ID: <ey3bryixx4z.fsf@cley.com>
* Pascal Bourguignon wrote:
> (If the :USE argument of DEFPACKAGE specify the packages that are
> _inherited_, why is it not called :INHERIT ?)
Because it doesn't. Inheriting a package would be much closer to
creating a conduit for it in the sense of my conduits system.
-tim
From: Steven M. Haflich
Subject: Re: The functions provide and require are deprecated.
Date:
Message-ID: <3EB5D7C1.2000407@alum.mit.edu>
Pascal Bourguignon wrote:
> "The functions PROVIDE and REQUIRE are deprecated." says CLHS.
>
> So, how can we declare which packages are used by a given package?
The mechanism of PROVIDE/REQUIRE/*MODULES* has nothing to do with
packages. Nothing, nada, no interaction whatever. You are probably
jumbling these two language components because they both have
something to do with partitioning large systems into manageable
parts. But the components that manipulate modules do not interact
with the components that manipulate packages.
The modules component is deprecated because it was recognized as
much too weak to fill the need of serious industrial systems.
Leaving it undeprecated would have confused users into thinking
that they should build upon it. Deprecating it tells users that
it still works and previous code using it won't break, but users
should not use it for new work.
From your questions it seems that your are not very familiar with
the way(s) large systems are managed in Common Lisp. If so,
probably you should investigate these things before you try to
design your own.
You should look at defsystem. There are several implementations,
some quite portable across common platforms.
"Steven M. Haflich" <·················@alum.mit.edu> writes:
> Pascal Bourguignon wrote:
> > "The functions PROVIDE and REQUIRE are deprecated." says CLHS.
> > So, how can we declare which packages are used by a given package?
>
> The mechanism of PROVIDE/REQUIRE/*MODULES* has nothing to do with
> packages. Nothing, nada, no interaction whatever. You are probably
> jumbling these two language components because they both have
> something to do with partitioning large systems into manageable
> parts. But the components that manipulate modules do not interact
> with the components that manipulate packages.
Yes, it's orthogonal, but it's linked with package because when in a
package A you have a reference such as B:S, the only wait to document
this dependency between A and B (bar from scanning the whole source of
package A), is to rely on a (REQUIRE 'B) at the beginning of the file
containing the package A. That what I did until now, (as I did with
my emacs sources). But since it's deprecated, I'm surprised to see
that there's nothing else standardized, and that it's up to me to
define an implement my own package management system. (or to choose
one of the various defsystem available).
> The modules component is deprecated because it was recognized as
> much too weak to fill the need of serious industrial systems.
> Leaving it undeprecated would have confused users into thinking
> that they should build upon it. Deprecating it tells users that
> it still works and previous code using it won't break, but users
> should not use it for new work.
>
> From your questions it seems that your are not very familiar with
> the way(s) large systems are managed in Common Lisp. If so,
> probably you should investigate these things before you try to
> design your own.
>
> You should look at defsystem. There are several implementations,
> some quite portable across common platforms.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
Do not adjust your mind, there is a fault in reality.
Pascal Bourguignon wrote:
> "Steven M. Haflich" writes:
>
>
> >Pascal Bourguignon wrote:
> >
> >>"The functions PROVIDE and REQUIRE are deprecated." says CLHS.
> >>So, how can we declare which packages are used by a given package?
> >
> >The mechanism of PROVIDE/REQUIRE/*MODULES* has nothing to do with
> >packages. Nothing, nada, no interaction whatever. You are probably
> >jumbling these two language components because they both have
> >something to do with partitioning large systems into manageable
> >parts. But the components that manipulate modules do not interact
> >with the components that manipulate packages.
>
>
> Yes, it's orthogonal, but it's linked with package because when in a
> package A you have a reference such as B:S, the only wait to document
> this dependency between A and B (bar from scanning the whole source of
> package A), is to rely on a (REQUIRE 'B) at the beginning of the file
> containing the package A.
No it is not. REQUIRE and PROVIDE in CL require a 'string designator'.
They are underspecified and therefore deprecated.
> That what I did until now, (as I did with
> my emacs sources).
Elisp is not CL (even if you should stick `(require 'cl)' in your .emacs).
> But since it's deprecated, I'm surprised to see
> that there's nothing else standardized, and that it's up to me to
> define an implement my own package management system. (or to choose
> one of the various defsystem available).
Yep. That is what you have to do. Note that even one of the defsystem
implementations may not work for you. That is why I tried to come up
with CL-CONFIGURATION (check the CLOCC - shameless plug).
Cheers
--
Marco Antoniotti
Pascal Bourguignon <····@thalassa.informatimago.com> writes:
> Yes, it's orthogonal, but it's linked with package because when in a
> package A you have a reference such as B:S, the only wait to document
> this dependency between A and B (bar from scanning the whole source of
> package A), is to rely on a (REQUIRE 'B) at the beginning of the file
> containing the package A.
That may be a useful convention, but nothing more than that. (REQUIRE
'B) requires a /module/ B, not a package with the same name.
While the spec isn't exactly clear about what a module actually is,
from the description of REQUIRE one may infer that it is just some
arbitrary body of code that can be loaded. I don't see anything that
says that this code has to live in a package whose name matches the
module name.
> But since it's deprecated, I'm surprised to see that there's nothing
> else standardized, and that it's up to me to define an implement my
> own package management system. (or to choose one of the various
> defsystem available).
I would agree that this situation is less than optimal, and apparently
the X3J13 team did as well, see the discussion of the defsystem
proposal. However, it seems that for now we have to live with this
situation and just use what's there. For the most part, the existing
solutions like mk:defsystem and asdf work just fine for me, but a
makemake kind of thing will probably not be trivial to write,
requiring a code walker once again.
Regards
Henrik