Re: [Bug-apl] Getting list of quad-commands and system commands

[Juergen Sauermann]

Hi,

providing descriptions of functions is a lot of work. Most people know APL after
a short while, and those who need it are probably better off with a good APL book.

I wanted to wait with the next release until the rate of error reports goes down a little.
Right now it seems to get a little more quiet, so maybe in two weeks from now?

/// Jürgen


On 03/01/2014 05:22 PM, Elias Mårtenson wrote:

Thanks. Looks easy enough.

What do you think of the idea of having descriptions of the functions embedded in the APL interpreter instead of in the Emacs mode?

Secondly, when do you plan to release 1.3?

Regards,

Elias

On 1 March 2014 23:50, Juergen Sauermann <address@hidden> wrote:

Hi Elias,

for commands, you can #define macro cmd_def() and then #include Command.def.
For Quad-vars you can #define macros ro_sv_def() and rw_sv_def and then #include SystemVariable.def.

For example, to get the strings for all commands:

#define cmd_def(cmd_str, code, _arg) #cmd_str
#include "Command.def"

To get the strings for all quad variables:

#define ro_sv_def(var) #var
#define rw_sv_def(var) #var
#include "Command.def"

In the latter case you need to replace "Quad_" by "⎕". Or #define
the macro as ID_ ## x (which gives an enum Id) and call id_name() on it
to get an UCS_string.

/// Jürgen

On 03/01/2014 02:42 PM, Elias Mårtenson wrote:

I've recently added smart expansion of symbols in the Emacs mode (press TAB and get a list of suggested variable and function names). I'd like it to be able to expand system commands and quad commands as well. Of course, I could simply hard-code the list of available commands, but it would be neater if there was a way of accessing this from GNU APL itself.

Also, since the expansion list has room for a description, it would be even more awesome if I could access a one-line description of these commands and variables. Of course, I could include it on my side, but this is something that's useful for not only the Emacs mode, but for any user of GNU APL, so would it make sense to include this information in the interpreter itself (I'd access it through an API, while it can also be made available from some kind of help command from the commandline).

Regards,
Elias