An APL package manager automates the construction of a software system
from a collection of independently-written packages.
Of course you can build an APL system from a collection of packages
today, but only by manually )copy-ing in the necessary workspaces.
I envision that each APL package will be bundled with metadata. In the
earliest implementation of the package manager, this metadata will
express dependencies of one package upon another. This will be used to
automate the loading of dependent packages. (This is the specific driver
for the ⎕CP request.)
Without dependency management, an APL programmer must manually detect
and resolve dependencies. As the size of a software system grows, manual
dependency resolution becomes increasingly difficult and frustrating.
(For the Linux guys: imagine having to use RPM without a dependency
manager...)
Manual dependency management is additionally frustrating when one wants
to simply update to a newer version of a package, but that package's
dependencies have changed.
The above summarizes my initial concerns for a package manager.
To put this in concrete terms:
1. Each package is distributed and installed as an independent unit. (I
envision a local repository in which each package is a subdirectory.)
2. The package manager constructs a database of all the local packages.
This database contains only metadata. A package's metadata is read from
a file in the package.
3. To load a package, the programmer issues a request to the package
manager, perhaps as:
pkg_load 'my_package'
The pkg_load function recursively looks up all the other packages
required by 'my_package' and arranges to load not only 'my_package', but
also all of the packages required to support 'my_package'.
For example, let's say I've written a web service in APL. I've saved
that in a package name 'my_apl_webservice'.
Knowing that a lot of the infrastructure for 'my_apl_webservice' may
have other applications, I've chosen to write components that can be
reused. For example, I might write the following packages (ignoring for
the moment the fact that APL may not be the language in which most
programmers would choose to write some of these):
XML_dom
XML_query
XSLT_processor
network_io
database_access
Here's what the package dependency graph (using indentation to express a
depends-on relation) might look like for 'my_apl_webservice':
my_apl_webservice
network_io
database_access
XML_dom
XSLT_processor
database_access
network_io
XML_query
XML_dom
XSLT_processor
XML_query
XML_dom
This is already getting pretty hairy, and it's not a particularly large
system (only six packages). Imagine trying to manually sort out the
dependencies among dozens of interrelated packages.
Beyond that, imagine that some of the packages are written in a mix of
APL and other languages.
I dunno... I feel that perhaps I've misunderstood the question.
Dependency management is such a fundamental part of software
construction that it seems odd to me to justify its application to APL.
Perhaps we're all so used to tools like 'make' and 'ant' and 'apt' and
'yum' that we have ceased to think about them in terms of dependency
management. But imagine trying to build and maintain software or systems
without these tools...
On Sun, 2014-04-27 at 19:30 +0200, Juergen Sauermann wrote:
> Hi David and all,
>
> thanks for the link below.
>
> Attached is a quick summary of my thoughts regarding libraries.
> Looks like David and myself are on the same page, just the focus is a
> bit different.
> I wouldn't rule out ⎕CP for GNU APL in the long run, but I feel like not
> having fully
> understood what the requirements are.
>
> I vaguely remember that some APL vendors (Dyalog and MicroAPL ?) had
> similar discussions on the
> web long ago, but I haven't seen the outcome. So we should not attempt
> too much in one go in order to
> succeed. On the other hand it is important to have clear requirements so
> that we spend effort in the right
> direction.
>
> So please shoot and lets see how we can collect the responses in a
> single doc or web page.
>
> /// Jürgen
>
>
> On 04/27/2014 12:03 AM, David B. Lamkins wrote:
> > See https://github.com/TieDyedDevil/apl-pkg .
> >
> > This repo has most of the documentation as comments in the code. Read
> > both .apl files. See additional notes in the README.
> >
> > There's one very important thing to note: This is not yet a functional
> > package manager. The primary roadblock is that GNU APL does not (unless
> > I've overlooked something) have a programmatic equivalent of )copy.
> >
> >
> >
> >
>
