Dan Bensen <··········@cyberspace.net> writes:
> So provide/require is deprecated? What's the rationale for this, and
> what's the alternative?
The alternative is to use ASDF (and ASDF-INSTALL).
http://constantly.at/lisp/asdf/
http://common-lisp.net/project/asdf-install/tutorial/index.html
--
__Pascal Bourguignon__ http://www.informatimago.com/
READ THIS BEFORE OPENING PACKAGE: According to certain suggested
versions of the Grand Unified Theory, the primary particles
constituting this product may decay to nothingness within the next
four hundred million years.
Pascal Bourguignon wrote:
> The alternative is to use ASDF (and ASDF-INSTALL).
Thanks for the links. So why/how is this better than module systems
that other languages use?
--
Dan
www.prairienet.org/~dsb
On Feb 19, 3:25 pm, Dan Bensen <··········@cyberspace.net> wrote:
> Pascal Bourguignon wrote:
> > The alternative is to use ASDF (and ASDF-INSTALL).
>
> Thanks for the links. So why/how is this better than module systems
> that other languages use?
It's better because it handles Lisp modules, which happens to be
exactly what you need if you are programming in Lisp. You could try
using, say, the module system that is built into an Ada compiler, but
it won't be as useful.
Dan Bensen <··········@cyberspace.net> writes:
> Pascal Bourguignon wrote:
>> The alternative is to use ASDF (and ASDF-INSTALL).
>
> Thanks for the links. So why/how is this better than module systems
> that other languages use?
Beware of the terminology!
There are names such as "package", "module", "system", etc that have
different meanings (and also other names) in different languages or
contexts.
In Modula-2 or Modula-3, what's called a module corresponds coarsely
to what we call a package in Common Lisp.
ASDF is, like its name indicate Another System Definition Facility.
What it does is to track dependencies and to load (compile) lisp files
and systems ("components") in the required order.
Very few other language has anything slightly related to this.
For example, Modula-2 and Modula-3 modules declare enough dependency
so you can write an automatic tool to track them (and generate a
makefile), but these languages themselves don't have any provision to
"compile" the needed (Modula-2 or -3 modules).
Eiffel (and IIRC Ada) too have enough information in the source files,
to let external tools track the dependencies.
But even in these cases, there is nothing in the language that
actually compiles, link-edit or load the needed dependencies. You
need external tools to scan the sources, to generate from the data
collected the makefile, and then use make (or an equivalent integrated
in the IDE) to invoke the compiler and link editor.
So, why or how are you better when you cannot compare yourself to
anything else?
There's simply no competition.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"You can tell the Lisp programmers. They have pockets full of punch
cards with close parentheses on them." --> http://tinyurl.com/8ubpf
Pascal Bourguignon wrote:
> Beware of the terminology!
Understood.
> ASDF is, like its name indicate Another System Definition Facility.
> What it does is to track dependencies and to load (compile) lisp files
> and systems ("components") in the required order.
> Very few other language has anything slightly related to this.
Okay, I'll give it a try. It looks like one big difference is that
file dependencies are concentrated in one place instead of at the top
of each file. Maybe its advantages are more obvious for a large system.
--
Dan
www.prairienet.org/~dsb
On Mon, 19 Feb 2007 19:01:57 -0600, Dan Bensen <··········@cyberspace.net> said:
| ...
| It looks like one big difference is that
| file dependencies are concentrated in one place instead of at the top
| of each file.
None of these two approaches (centralized vs. distributed dependency
definitions) is unconditionally better than the other. In general,
handling dependencies is hard [1], and there probably isn't a
one-size-fits-all approach (which is why PROVIDE and REQUIRE were only
reluctantly left in the standard).
[1] E.g. in some programming environments with a sufficiently large number of
modules available (in the hundreds or more), where each module is
available in multiple releases (not necessarily backward compatible,
never mind forward), and where each program typically depends
(directly or indirectly) on dozens of modules, anecdotally 1/4 to 1/3
of troubleshooting time goes just into chasing incorrect dependency
definitions. Arguably, one important factor causing such an undesirable
state of affairs is the lack of proper dependency management facilities.
---Vassil.
--
Our programs do not have bugs; it is just that the users' expectations
differ from the way they are implemented.
On Feb 20, 5:23 am, Vassil Nikolov <···············@pobox.com> wrote:
>
> [1] E.g. in some programming environments with a sufficiently large number of
> modules available (in the hundreds or more), where each module is
> available in multiple releases (not necessarily backward compatible,
> never mind forward), and where each program typically depends
> (directly or indirectly) on dozens of modules, anecdotally 1/4 to 1/3
> of troubleshooting time goes just into chasing incorrect dependency
> definitions. Arguably, one important factor causing such an undesirable
> state of affairs is the lack of proper dependency management facilities.
This is definitely true, but I think these issues generally arise not
due to lack of facilities, but due to people not using them for
various reasons too complicated for me to describe here (but usually
some combination of sloth, incompetence, pervasiveness of box-people
and management pressure for features rather than "non-productive" work
on the build & deployment system).
--tim
Vassil Nikolov <···············@pobox.com> wrote:
+---------------
| Dan Bensen <··········@cyberspace.net> said:
| | ...
| | It looks like one big difference is that file dependencies are
| | concentrated in one place instead of at the top of each file.
|
| None of these two approaches (centralized vs. distributed dependency
| definitions) is unconditionally better than the other. In general,
| handling dependencies is hard [1], and there probably isn't a
| one-size-fits-all approach (which is why PROVIDE and REQUIRE were only
| reluctantly left in the standard).
+---------------
Those interested in such issues might also find this useful:
http://www.nhplace.com/kent/Papers/Large-Systems.html
The Description of Large Systems
Kent M. Pitman
MIT AI Memo 801, September, 1984 (revised 23-Jan-2001)
In this paper, we discuss the problems associated with the
description and manipulation of large systems when their sources
are not maintained as single files. We show why and how tools
that address these issues, such as Unix[1] MAKE and Lisp Machine
DEFSYSTEM, have evolved.
...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607