Hi David,
truly sorry that I forgot to mention it.
/// Jürgen
On 12/21/2016 08:55 PM, David B.
Lamkins wrote:
This seems like a good time to again mention my APL package manager.
https://github.com/TieDyedDevil/apl-pkg
This provides, among other things:
- a way to organize APL code,
- analysis tools, and
- editor integration.
I'll start with editor integration, since that's the current topic of interest. You can edit any function that the package manager has loaded with the command:
]pkg edit <function-name>
This opens the function in an external editor, positioning the cursor to the header line of the function within the .apl file from which the function was loaded.
The editor itself defaults to `vi`; this can be be changed by naming your favorite editor in the package manager's configuration file. In the editor, the keyboard is mapped for APL without using `loadkeys` or `xmodmap`.
The package also provides a wrapper script `awe` (for APL Workbench Environment) that, among other things, establishes a proper environment to support the editor. By default this is `dvtm` in the Linux console and your window manager under X. The `awe` script also supports `tabbed` (an XEmbed container) and `dvtm` under X.
The package manager's analysis tools include:
- apropos (find APL functions, variables or operators by partial name)
- refs (list all non-local names referenced by a function)
- uses (list all functions that use a given user-defined function, variable or operator)
- undefs (list names referenced but not defined)
- unrefs (list named defined but not referenced)
- locate (identify the file from which a function or operator has been loaded)
- inspect (inspect/edit variables via navigation of their nested structure)
Then there's the actual package management functionality. Simply put, a package is a collection of source code in one or more .apl files. A package may depend upon other packages; dependencies are loaded as needed. You may program the package loader (on a per-package basis) to perform different actions depending upon certain environmental queries, e.g. what's the OS?
A package's loader may shell out to do non-APL things. For example, you can compile the code of a shared library to be loaded as a native function using GNU APL's quad-FX extension.
All of the above is already implemented. I use the package manager to develop the package manager and some other utility libraries, such as my ISO-compliant component file library.
https://github.com/TieDyedDevil/iso-apl-cf
In the longer run, I intend to implement versioned dependency loading and the ability to load packages from the `net.
On Wed, Dec 21, 2016 at 01:35:36PM +0100, Juergen Sauermann wrote:
Hi Alexey,
I am myself not familiar with emacs and, as a matter of fact, I do not even
have it
installed on my machine. I believe the most efficient way to write APL programs
these days is to edit the functions and variables offline in a separate .apl
file which
is then run in a separate window. Like you write a C/C++ program beforehand.
compile it, and then execute it. With that approach you can use whatever editor
you prefer and you have all the functions and variables in a single file and in
a
consistent state. It also simplifies the documentation and publishing of APL
programs lot.
You can also check-in the .apl files into a revision control system, diff them,
and so on.
The interactive mode of APL (including function editing) has always had severe
limitations
and I have provided it only for compatibility and for the elder APL programmers
who are used to it.
The interactive mode was definitely an improvement over the punch cards used
when APL was invented,
but today the capabilities of computers are very different and I would not
recommend the interactive mode
for newcomers to APL.
|