bug-apl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-apl] A modest proposal: user-defined commands


From: Elias Mårtenson
Subject: Re: [Bug-apl] A modest proposal: user-defined commands
Date: Sat, 3 May 2014 14:22:11 +0800

As much as I am a fan of extensions, I have to admit that I don't fully understand the justification for this. After all, the pkg-commands are plain functions, so why not expose them as such?

Regards,
Elias

On 3 May 2014 13:27, "David B. Lamkins" <address@hidden> 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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]