Hi David,
from what I hear Dyalog APL seems to be a good interpreter and I have no
problem with it.
I am only a little more conservative when it comes to new and
non-standard APL features.
But Peter Teeson had ideas going into a similar direction.
One question that I have is how the implementation of a new command
would look like.
Is it an APL function (which basically means that the command only
relieves the user
from quoting the argument of the command) or would it be implemented in
or C++
like native functions?
And do we know how often this feature in Dyalog was used in real life?
/// Jürgen
On 05/03/2014 07:27 AM, David B. Lamkins wrote:
During a few idle moments at work today, I flipped through some of the
BAA archives and came across a short article regarding Dyalog's
extension to allow user-defined commands.
Yah, I know... Dyalog. But hear me out.
I've been thinking ahead to a time when I'll be ready to roll out the
package manager. Some of my thoughts have turned to user interface
issues.
I can of course make an APL-only UI by simply providing functions. But
wouldn't it be nice to have a way to access the UI using a not-strictly
APL syntax (rather: something that might admit, for example, simple
search terms or pathnames without quoting; or maybe even the kind of
interface that supports a limited vocabulary of subjects and verbs.)
For example, rather than invoking something like:
pkg_load 'package-name'
I could write:
]pkg load package-name
The main benefit in this example is a trivial simplification of syntax.
On the other hand, the ] serves as a visual reminder in the transcript
that this particular operation was - from the user's viewpoint - a
session command and not an operation in the program being used.
I envision a really simple interface to this feature. GNU APL would
recognize a prefix (something like gnu∆apl∆cmd_) on the name of a
monadic function and bind that function to be called when the suffix of
that function's name is present as the name of a ] command. For example:
]pkg
would call the monadic function gnu∆apl∆cmd_pkg.
The remainder of the line following the command's invocation would be
passed as a string to the command (after stripping leading and trailing
blanks). It'd be the responsibility of the user-defined APL function to
parse or interpret any supplied arguments. For example:
]pkg list all missing
would execute gnu∆apl∆cmd_pkg 'list all missing'.
I sussect that the main changes needed would be to
1) extend the ] command lookup to search for an APL function, and
2) build a string to pass to APL's internal execute.
