Hi,
When I start CLISP with the full linking set (i.e., including all possible extensions), I have 63 packages in (list-all-packages), and 37 of them (more than half!) comes from asdf (22 ASDF/* and 15 UIOP/*).
I wonder if I am the only one unhappy about this. In particular, has it ever been considered that it might be a good idea to limit the number of packages asdf creates?
Thanks.
On 16 Jan 2018, at 17:46, Sam Steingold sds@gnu.org wrote:
Hi,
When I start CLISP with the full linking set (i.e., including all possible extensions), I have 63 packages in (list-all-packages), and 37 of them (more than half!) comes from asdf (22 ASDF/* and 15 UIOP/*).
I wonder if I am the only one unhappy about this. In particular, has it ever been considered that it might be a good idea to limit the number of packages asdf creates?
Why? Does FIND-PACKAGE use a linear algorithm to find the packages?
This apparent multiplication of packages is due to the absence of hierarchical package names (and, granted, a tendency to over-modularize the code). But IMO, an implementation should be prepared to handle a big number of packages. Notably, use-package should be cheap, so packages used by a lot of other packages shouldn’t be costly either. (On the other hand, FIND-SYMBOL in a package that uses a lot of other packages may be rather costly, either in time or in memory (cache)).
Note that users probably don’t use LIST-ALL-PACKAGES directly. In my case, I use com.informatimago.common-lisp.interactive.interactive:lspack ; I’ve never felt the need to filter out the packages very strongly (it uses string-match-p to select package names containing an optional substring), but it would be trivial to add filters to exclude package names that have some hierarchical structure in them (“sub-packages” delimited with “/“ or “.”).
On 16 Jan 2018, at 10:46, Sam Steingold wrote:
Hi,
When I start CLISP with the full linking set (i.e., including all possible extensions), I have 63 packages in (list-all-packages), and 37 of them (more than half!) comes from asdf (22 ASDF/* and 15 UIOP/*).
I wonder if I am the only one unhappy about this. In particular, has it ever been considered that it might be a good idea to limit the number of packages asdf creates?
The large number of packages was the outcome of the restructuring of ASDF in terms of package inferred systems.
Arguably this provides a better way of automatically identifying the dependencies in a complex system like ASDF.
This is not a style of programming that I follow, myself, but it certainly seems like a reasonable design decision.
Undoing this would, I believe, be a monumental amount of work, and would also lead to a constant need to maintain complicated dependencies by hand. These dependencies potentially change whenever we discover that one file/package needs another's capabilities. With package-inferred system construction, we don't have to wrangle ASDF dependencies to keep the system building successfully.
To be quite honest, I can't imagine a world in which there is so much labor available to ASDF that such fundamentally aesthetic considerations would rise to the top of anyone's priority list of ASDF tasks.
Sorry, r
-
Pascal Bourguignon -
Robert Goldman -
Sam Steingold