Discussion:
[Bug-apl] Free APL reference documentation, any takers?
Elias Mårtenson
2017-04-11 08:22:14 UTC
Permalink
The Emacs mode for GNU APL contains a (small) reference manual. Really
nothing more than a short paragraph on most system functions, enough for
the integrated documentation features to work. It's been pointed out to me
that it would be nice if the documentation was more complete, particularly
with examples of the use of each function in addition to the abstract
explanation as to what it does.

Now, I feel that this documentation doesn't really belong in the Emacs
mode. It belongs in GNU APL itself. Emacs should simply access this from
the APL runtime when needed,

Thus, I would like to suggest creating an integrated reference
documentation inside GNU APL itself. We could start with what I have in the
Emacs mode, and then add more.

The following file contains the current documentation in the Emacs mode:
https://github.com/lokedhs/gnu-apl-mode/blob/master/gnu-apl-refdocs-bsd-license.el

Each element contains three strings:

- Invocation type (monadic, dyadic, etc)
- Name of the function
- One-line summary of the function
- (optional) Longer description

There are two questions:

1. Is anybody willing to help out with expanding in the reference
documentation?
2. For JÃŒrgen, are you willing to put this into GNU APL itself instead
of keeping it in the Emacs mode?

Regards,
Elias
Alexey Veretennikov
2017-04-11 14:34:48 UTC
Permalink
Hi,

Indeed I was also thinking on creating such a documentation even in terms
of notes for myself. I don't always use Emacs for GNU APL (I run it on a
device where I'm not able to compile emacs but fine to compile GNU APL), so
I would be happy to read this documentation from within the interpreter,
for example using like
]help ⍣
or
]help ⎕FX

Br,
/Alexey
Post by Elias MÃ¥rtenson
The Emacs mode for GNU APL contains a (small) reference manual. Really
nothing more than a short paragraph on most system functions, enough for
the integrated documentation features to work. It's been pointed out to me
that it would be nice if the documentation was more complete, particularly
with examples of the use of each function in addition to the abstract
explanation as to what it does.
Now, I feel that this documentation doesn't really belong in the Emacs
mode. It belongs in GNU APL itself. Emacs should simply access this from
the APL runtime when needed,
Thus, I would like to suggest creating an integrated reference
documentation inside GNU APL itself. We could start with what I have in the
Emacs mode, and then add more.
https://github.com/lokedhs/gnu-apl-mode/blob/master/gnu-
apl-refdocs-bsd-license.el
- Invocation type (monadic, dyadic, etc)
- Name of the function
- One-line summary of the function
- (optional) Longer description
1. Is anybody willing to help out with expanding in the reference
documentation?
2. For JÃŒrgen, are you willing to put this into GNU APL itself instead
of keeping it in the Emacs mode?
Regards,
Elias
Juergen Sauermann
2017-04-11 18:20:09 UTC
Permalink
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Helvetica, Arial, sans-serif">Hi,<br>
<br>
it would be good if someone could provide the help texts. Ideally
as a macro called <b>help_def()</b> like this:<br>
<br>
<b>help_def(valence, function, short</b><b>_</b><b>decription,
long</b><b>_description)</b><b><br>
</b><br>
with: valence: number (0 for niladic, 1 for monadic, or 2 for
dyadic)<br>
function: String literal</font><font face="Helvetica, Arial,
sans-serif"> or just the text</font><br>
<font face="Helvetica, Arial, sans-serif">short_description: String
literal or just the text</font><br>
<font face="Helvetica, Arial, sans-serif">long_decription: String
literal</font><font face="Helvetica, Arial, sans-serif"><font
face="Helvetica, Arial, sans-serif"> or just the text<br>
<br>
Please no comma or ; at the end of the macro, and one line per
macro (no \ continuation).<br>
<br>
Using a macro as opposed to instantiating struct has the
advantage that it is easier to integrate into the C++ code of
GNU APL.<br>
It is also easier to read and makes it possible to omit the ""
(for function and short_description). Have a look at the files
with<br>
extension <b>.def</b> in the GNU APL <b>src</b> directory to
see how this type of macro is being used. Like  <b></b><b>src/SystemVariable.def</b><b><br>
</b>which packs together figgerent properties of ⎕-Variables
from which later on the )HELP texts for the ⎕-variables is
derived.<br>
For example:<br>
<br>
</font></font><b><font face="Courier New, Courier, monospace">help_def(1,
"+B",  Conjugate, <span class="pl-s"><span class="pl-pds">"</span>Returns
the conjugate of B<span class="pl-pds">")</span></span><br>
</font></b><span class="pl-s"><span class="pl-pds"><b><font
face="Courier New, Courier, monospace">help_def(2, "A+B",
Add,       </font></b><span class="pl-s"><b><font
face="Courier New, Courier, monospace"><span
class="pl-pds">"</span>Returns the sum of A and B</font></b><span
class="pl-pds"><b><font face="Courier New, Courier,
monospace">")</font></b><br>
<br>
Finally it would be good if whoever provides this is willing
to release it under the GPL like all other GNU APL code.<br>
So all the <b>help_def</b> macros should go into a single
file, say <b>Help.def </b>with the usual GPL text at the
beginning and<br>
whoever has provided it as the Copyright holder.<br>
<br>
I will then be happy to change the )HELP command to display
the texts provided.<br>
<br>
Thanks,<br>
Jürgen<br>
<br>
<br>
</span></span></span></span><br>
<font face="Helvetica, Arial, sans-serif"><font face="Helvetica,
Arial, sans-serif"></font>
</font>
<div class="moz-cite-prefix">On 04/11/2017 04:34 PM, Alexey
Veretennikov wrote:<br>
</div>
<blockquote
cite="mid:CAKE5LL6Y5mknDEe49F6ZHxjwAk+xxc4gifjwOn+OPO04owqa-***@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>Hi,<br>
<br>
</div>
Indeed I was also thinking on creating such a documentation
even in terms of notes for myself. I don't always use Emacs
for GNU APL (I run it on a device where I'm not able to
compile emacs but fine to compile GNU APL), so I would be
happy to read this documentation from within the interpreter,
for example using like <br>
]help ⍣<br>
</div>
<div>or <br>
</div>
<div>]help ⎕FX<br>
<br>
</div>
<div>Br,<br>
</div>
<div>/Alexey<br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2017-04-11 10:22 GMT+02:00 Elias
Mårtenson <span dir="ltr">&lt;<a moz-do-not-send="true"
href="mailto:***@gmail.com" target="_blank">***@gmail.com</a>&gt;</span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">The Emacs mode for GNU APL contains a (small)
reference manual. Really nothing more than a short
paragraph on most system functions, enough for the
integrated documentation features to work. It's been
pointed out to me that it would be nice if the
documentation was more complete, particularly with
examples of the use of each function in addition to the
abstract explanation as to what it does.
<div><br>
</div>
<div>Now, I feel that this documentation doesn't really
belong in the Emacs mode. It belongs in GNU APL itself.
Emacs should simply access this from the APL runtime
when needed,</div>
<div><br>
</div>
<div>Thus, I would like to suggest creating an integrated
reference documentation inside GNU APL itself. We could
start with what I have in the Emacs mode, and then add
more.</div>
<div><br>
</div>
<div>The following file contains the current documentation
in the Emacs mode:</div>
<div><br>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
<blockquote
cite="mid:CAKE5LL6Y5mknDEe49F6ZHxjwAk+xxc4gifjwOn+OPO04owqa-***@mail.gmail.com"
type="cite">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div><br>
</div>
<div>Each element contains three strings:</div>
<div>
<ul>
<li>Invocation type (monadic, dyadic, etc)</li>
<li>Name of the function</li>
<li>One-line summary of the function</li>
<li>(optional) Longer description</li>
</ul>
</div>
<div>There are two questions:</div>
<div>
<ol>
<li>Is anybody willing to help out with expanding in
the reference documentation?<br>
</li>
<li>For Jürgen, are you willing to put this into GNU
APL itself instead of keeping it in the Emacs mode?</li>
</ol>
<div>Regards,</div>
</div>
<div>Elias</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>
Juergen Sauermann
2017-04-11 18:41:07 UTC
Permalink
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Helvetica, Arial, sans-serif">Hi again,<br>
<br>
one more thing. In the IBM documentation the functions are usually
denoted in a form like this:<br>
<br>
<b><font face="Courier New, Courier, monospace">Z←L+R </font></b>using
<b>Z</b> for the result and <b>L</b> and <b>R</b> for the left
and right value arguments.<br>
<br>
The ISO standard (also mainly written by IBM uses:<br>
</font><br>
<font face="Helvetica, Arial, sans-serif"><font face="Helvetica,
Arial, sans-serif"><b><font face="Courier New, Courier,
monospace">Z←A+B </font></b>using <b>Z</b> for the result
and <b>A</b> and <b>B</b> for the left and right value
arguments.<br>
<br>
My personal preference used to be</font>:<br>
</font><br>
<font face="Helvetica, Arial, sans-serif"><font face="Helvetica,
Arial, sans-serif"><font face="Helvetica, Arial, sans-serif"><b><font
face="Courier New, Courier, monospace">R←A+B </font></b>using
<b>R</b> for the result and <b>A</b> and <b>B</b> for the
left and right arguments. I guess this was from<br>
Gilman/Rose, but I am not sure.<br>
<br>
The GNU source code uses <b>Z</b>, <b>A</b>, and <b>B</b>
as well as <b>LO</b> and <b>RO</b> for the left and right
function arguments of operators.<br>
The <b>info apl</b> also uses <b>A</b> and <b>B</b>. I
would therefore like to prose (objections welcome) to use the
<font face="Courier New, Courier, monospace"><b>Z←A f </b></font><b>B</b>
for functions<br>
and <b>Z←A (LO op RO) B</b> for e.g. dyadic operators.<br>
<br>
Best Regards,<br>
Jürgen Sauermann<br>
 <br>
<br>
<br>
</font></font><br>
<br>
<br>
</font><br>
<div class="moz-cite-prefix">On 04/11/2017 08:20 PM, Juergen
Sauermann wrote:<br>
</div>
<blockquote
cite="mid:9a4a0c70-b3ac-0e84-2b0b-***@t-online.de"
type="cite">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<font face="Helvetica, Arial, sans-serif">Hi,<br>
<br>
it would be good if someone could provide the help texts.
Ideally as a macro called <b>help_def()</b> like this:<br>
<br>
<b>help_def(valence, function, short</b><b>_</b><b>decription,
long</b><b>_description)</b><b><br>
</b><br>
with: valence: number (0 for niladic, 1 for monadic, or 2 for
dyadic)<br>
function: String literal</font><font face="Helvetica, Arial,
sans-serif"> or just the text</font><br>
<font face="Helvetica, Arial, sans-serif">short_description:
String literal or just the text</font><br>
<font face="Helvetica, Arial, sans-serif">long_decription: String
literal</font><font face="Helvetica, Arial, sans-serif"><font
face="Helvetica, Arial, sans-serif"> or just the text<br>
<br>
Please no comma or ; at the end of the macro, and one line per
macro (no \ continuation).<br>
<br>
Using a macro as opposed to instantiating struct has the
advantage that it is easier to integrate into the C++ code of
GNU APL.<br>
It is also easier to read and makes it possible to omit the ""
(for function and short_description). Have a look at the files
with<br>
extension <b>.def</b> in the GNU APL <b>src</b> directory to
see how this type of macro is being used. Like  <b>src/SystemVariable.def</b><b><br>
</b>which packs together figgerent properties of ⎕-Variables
from which later on the )HELP texts for the ⎕-variables is
derived.<br>
For example:<br>
<br>
</font></font><b><font face="Courier New, Courier, monospace">help_def(1,
"+B",  Conjugate, <span class="pl-s"><span class="pl-pds">"</span>Returns
the conjugate of B<span class="pl-pds">")</span></span><br>
</font></b><span class="pl-s"><span class="pl-pds"><b><font
face="Courier New, Courier, monospace">help_def(2, "A+B",
Add,       </font></b><span class="pl-s"><b><font
face="Courier New, Courier, monospace"><span
class="pl-pds">"</span>Returns the sum of A and B</font></b><span
class="pl-pds"><b><font face="Courier New, Courier,
monospace">")</font></b><br>
<br>
Finally it would be good if whoever provides this is
willing to release it under the GPL like all other GNU APL
code.<br>
So all the <b>help_def</b> macros should go into a single
file, say <b>Help.def </b>with the usual GPL text at the
beginning and<br>
whoever has provided it as the Copyright holder.<br>
<br>
I will then be happy to change the )HELP command to
display the texts provided.<br>
<br>
Thanks,<br>
Jürgen<br>
<br>
<br>
</span></span></span></span><br>
<font face="Helvetica, Arial, sans-serif"> </font>
<div class="moz-cite-prefix">On 04/11/2017 04:34 PM, Alexey
Veretennikov wrote:<br>
</div>
<blockquote
cite="mid:CAKE5LL6Y5mknDEe49F6ZHxjwAk+xxc4gifjwOn+OPO04owqa-***@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>Hi,<br>
<br>
</div>
Indeed I was also thinking on creating such a documentation
even in terms of notes for myself. I don't always use Emacs
for GNU APL (I run it on a device where I'm not able to
compile emacs but fine to compile GNU APL), so I would be
happy to read this documentation from within the
interpreter, for example using like <br>
]help ⍣<br>
</div>
<div>or <br>
</div>
<div>]help ⎕FX<br>
<br>
</div>
<div>Br,<br>
</div>
<div>/Alexey<br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2017-04-11 10:22 GMT+02:00 Elias
Mårtenson <span dir="ltr">&lt;<a moz-do-not-send="true"
href="mailto:***@gmail.com" target="_blank">***@gmail.com</a>&gt;</span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">The Emacs mode for GNU APL contains a
(small) reference manual. Really nothing more than a
short paragraph on most system functions, enough for the
integrated documentation features to work. It's been
pointed out to me that it would be nice if the
documentation was more complete, particularly with
examples of the use of each function in addition to the
abstract explanation as to what it does.
<div><br>
</div>
<div>Now, I feel that this documentation doesn't really
belong in the Emacs mode. It belongs in GNU APL
itself. Emacs should simply access this from the APL
runtime when needed,</div>
<div><br>
</div>
<div>Thus, I would like to suggest creating an
integrated reference documentation inside GNU APL
itself. We could start with what I have in the Emacs
mode, and then add more.</div>
<div><br>
</div>
<div>The following file contains the current
documentation in the Emacs mode:</div>
<div><br>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
<blockquote
cite="mid:CAKE5LL6Y5mknDEe49F6ZHxjwAk+xxc4gifjwOn+OPO04owqa-***@mail.gmail.com"
type="cite">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div><br>
</div>
<div>Each element contains three strings:</div>
<div>
<ul>
<li>Invocation type (monadic, dyadic, etc)</li>
<li>Name of the function</li>
<li>One-line summary of the function</li>
<li>(optional) Longer description</li>
</ul>
</div>
<div>There are two questions:</div>
<div>
<ol>
<li>Is anybody willing to help out with expanding in
the reference documentation?<br>
</li>
<li>For Jürgen, are you willing to put this into GNU
APL itself instead of keeping it in the Emacs
mode?</li>
</ol>
<div>Regards,</div>
</div>
<div>Elias</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>
Alexey Veretennikov
2017-04-16 20:19:07 UTC
Permalink
Hi Juergen, Elias,

I've converted documentation from GNU APL Emacs mode with permission of
Elias to the format proposed by you.

I've only added additional 2nd argument with the plain symbol/text of
the function/operator to make it easier to parse/lookup.

I've not reviewed this documentation, just converted it to this format
and fixed naming conventions.
Please note what this is just a beginning and I hope myself and
community will work on this file further and hopefully continuously,
refining the open GNU APL documentation.
Louis Chrétien
2017-04-16 20:59:42 UTC
Permalink
Noticed 2 typos in the “Circle” definition:

Value 2 should be “cos” instead of “cosin”, to be consistent with the rest of the naming of the trigonometrics
Value 9 should read “Real” instead of “Beal”

I suspect your search/replace to replace R with B might have been a bit too strong
 ;)
Post by Alexey Veretennikov
Hi Juergen, Elias,
I've converted documentation from GNU APL Emacs mode with permission of
Elias to the format proposed by you.
I've only added additional 2nd argument with the plain symbol/text of
the function/operator to make it easier to parse/lookup.
I've not reviewed this documentation, just converted it to this format
and fixed naming conventions.
Please note what this is just a beginning and I hope myself and
community will work on this file further and hopefully continuously,
refining the open GNU APL documentation.
<Help.def>
Post by Juergen Sauermann
Hi again,
Z←L+R using Z for the result and L and R for the left and right value arguments.
Z←A+B using Z for the result and A and B for the left and right value arguments.
R←A+B using R for the result and A and B for the left and right arguments. I guess this was from
Gilman/Rose, but I am not sure.
The GNU source code uses Z, A, and B as well as LO and RO for the left and right function arguments of
operators.
The info apl also uses A and B. I would therefore like to prose (objections welcome) to use the Z←A f B
for functions
and Z←A (LO op RO) B for e.g. dyadic operators.
Best Regards,
JÃŒrgen Sauermann
Hi,
it would be good if someone could provide the help texts. Ideally as a macro called help_def() like
help_def(valence, function, short_decription, long_description)
with: valence: number (0 for niladic, 1 for monadic, or 2 for dyadic)
function: String literal or just the text
short_description: String literal or just the text
long_decription: String literal or just the text
Please no comma or ; at the end of the macro, and one line per macro (no \ continuation).
Using a macro as opposed to instantiating struct has the advantage that it is easier to integrate into
the C++ code of GNU APL.
It is also easier to read and makes it possible to omit the "" (for function and short_description). Have
a look at the files with
extension .def in the GNU APL src directory to see how this type of macro is being used. Like
src/SystemVariable.def
which packs together figgerent properties of ⎕-Variables from which later on the )HELP texts for the
⎕-variables is derived.
help_def(1, "+B", Conjugate, "Returns the conjugate of B")
help_def(2, "A+B", Add, "Returns the sum of A and B")
Finally it would be good if whoever provides this is willing to release it under the GPL like all other GNU
APL code.
So all the help_def macros should go into a single file, say Help.def with the usual GPL text at the
beginning and
whoever has provided it as the Copyright holder.
I will then be happy to change the )HELP command to display the texts provided.
Thanks,
JÃŒrgen
Hi,
Indeed I was also thinking on creating such a documentation even in terms of notes for myself. I
don't always use Emacs for GNU APL (I run it on a device where I'm not able to compile emacs
but fine to compile GNU APL), so I would be happy to read this documentation from within the
interpreter, for example using like
]help ⍣
or
]help ⎕FX
Br,
/Alexey
The Emacs mode for GNU APL contains a (small) reference manual. Really nothing more
than a short paragraph on most system functions, enough for the integrated documentation
features to work. It's been pointed out to me that it would be nice if the documentation was
more complete, particularly with examples of the use of each function in addition to the
abstract explanation as to what it does.
Now, I feel that this documentation doesn't really belong in the Emacs mode. It belongs in
GNU APL itself. Emacs should simply access this from the APL runtime when needed,
Thus, I would like to suggest creating an integrated reference documentation inside GNU
APL itself. We could start with what I have in the Emacs mode, and then add more.
* Invocation type (monadic, dyadic, etc)
* Name of the function
* One-line summary of the function
* (optional) Longer description
1 Is anybody willing to help out with expanding in the reference documentation?
2 For JÃŒrgen, are you willing to put this into GNU APL itself instead of keeping it in the
Emacs mode?
Regards,
Elias
--
Br,
/Alexey
---
Louis Chrétien
***@mac.com
Louis Chrétien
2017-04-16 21:34:04 UTC
Permalink
Also noticed that the “Find”, “Encode” and “Decode” are defined in two different places of the file, with slightly different wording.
Post by Alexey Veretennikov
Hi Juergen, Elias,
I've converted documentation from GNU APL Emacs mode with permission of
Elias to the format proposed by you.
I've only added additional 2nd argument with the plain symbol/text of
the function/operator to make it easier to parse/lookup.
I've not reviewed this documentation, just converted it to this format
and fixed naming conventions.
Please note what this is just a beginning and I hope myself and
community will work on this file further and hopefully continuously,
refining the open GNU APL documentation.
<Help.def>
Post by Juergen Sauermann
Hi again,
Z←L+R using Z for the result and L and R for the left and right value arguments.
Z←A+B using Z for the result and A and B for the left and right value arguments.
R←A+B using R for the result and A and B for the left and right arguments. I guess this was from
Gilman/Rose, but I am not sure.
The GNU source code uses Z, A, and B as well as LO and RO for the left and right function arguments of
operators.
The info apl also uses A and B. I would therefore like to prose (objections welcome) to use the Z←A f B
for functions
and Z←A (LO op RO) B for e.g. dyadic operators.
Best Regards,
JÃŒrgen Sauermann
Hi,
it would be good if someone could provide the help texts. Ideally as a macro called help_def() like
help_def(valence, function, short_decription, long_description)
with: valence: number (0 for niladic, 1 for monadic, or 2 for dyadic)
function: String literal or just the text
short_description: String literal or just the text
long_decription: String literal or just the text
Please no comma or ; at the end of the macro, and one line per macro (no \ continuation).
Using a macro as opposed to instantiating struct has the advantage that it is easier to integrate into
the C++ code of GNU APL.
It is also easier to read and makes it possible to omit the "" (for function and short_description). Have
a look at the files with
extension .def in the GNU APL src directory to see how this type of macro is being used. Like
src/SystemVariable.def
which packs together figgerent properties of ⎕-Variables from which later on the )HELP texts for the
⎕-variables is derived.
help_def(1, "+B", Conjugate, "Returns the conjugate of B")
help_def(2, "A+B", Add, "Returns the sum of A and B")
Finally it would be good if whoever provides this is willing to release it under the GPL like all other GNU
APL code.
So all the help_def macros should go into a single file, say Help.def with the usual GPL text at the
beginning and
whoever has provided it as the Copyright holder.
I will then be happy to change the )HELP command to display the texts provided.
Thanks,
JÃŒrgen
Hi,
Indeed I was also thinking on creating such a documentation even in terms of notes for myself. I
don't always use Emacs for GNU APL (I run it on a device where I'm not able to compile emacs
but fine to compile GNU APL), so I would be happy to read this documentation from within the
interpreter, for example using like
]help ⍣
or
]help ⎕FX
Br,
/Alexey
The Emacs mode for GNU APL contains a (small) reference manual. Really nothing more
than a short paragraph on most system functions, enough for the integrated documentation
features to work. It's been pointed out to me that it would be nice if the documentation was
more complete, particularly with examples of the use of each function in addition to the
abstract explanation as to what it does.
Now, I feel that this documentation doesn't really belong in the Emacs mode. It belongs in
GNU APL itself. Emacs should simply access this from the APL runtime when needed,
Thus, I would like to suggest creating an integrated reference documentation inside GNU
APL itself. We could start with what I have in the Emacs mode, and then add more.
* Invocation type (monadic, dyadic, etc)
* Name of the function
* One-line summary of the function
* (optional) Longer description
1 Is anybody willing to help out with expanding in the reference documentation?
2 For JÃŒrgen, are you willing to put this into GNU APL itself instead of keeping it in the
Emacs mode?
Regards,
Elias
--
Br,
/Alexey
---
Louis Chrétien
***@mac.com
Louis de Forcrand
2017-04-17 02:33:18 UTC
Permalink
Thank you very much for this.
I remember having a very hard time finding good, easy-to-use documentation as a beginner. One page that I used often was
http://microapl.com/apl_help/ch_020_020.htm

Perhaps it could serve as inspiration / reference for our documentation?

Louis
Post by Louis Chrétien
Also noticed that the “Find”, “Encode” and “Decode” are defined in two different places of the file, with slightly different wording.
Post by Alexey Veretennikov
Hi Juergen, Elias,
I've converted documentation from GNU APL Emacs mode with permission of
Elias to the format proposed by you.
I've only added additional 2nd argument with the plain symbol/text of
the function/operator to make it easier to parse/lookup.
I've not reviewed this documentation, just converted it to this format
and fixed naming conventions.
Please note what this is just a beginning and I hope myself and
community will work on this file further and hopefully continuously,
refining the open GNU APL documentation.
<Help.def>
Post by Juergen Sauermann
Hi again,
Z←L+R using Z for the result and L and R for the left and right value arguments.
Z←A+B using Z for the result and A and B for the left and right value arguments.
R←A+B using R for the result and A and B for the left and right arguments. I guess this was from
Gilman/Rose, but I am not sure.
The GNU source code uses Z, A, and B as well as LO and RO for the left and right function arguments of
operators.
The info apl also uses A and B. I would therefore like to prose (objections welcome) to use the Z←A f B
for functions
and Z←A (LO op RO) B for e.g. dyadic operators.
Best Regards,
JÃŒrgen Sauermann
Hi,
it would be good if someone could provide the help texts. Ideally as a macro called help_def() like
help_def(valence, function, short_decription, long_description)
with: valence: number (0 for niladic, 1 for monadic, or 2 for dyadic)
function: String literal or just the text
short_description: String literal or just the text
long_decription: String literal or just the text
Please no comma or ; at the end of the macro, and one line per macro (no \ continuation).
Using a macro as opposed to instantiating struct has the advantage that it is easier to integrate into
the C++ code of GNU APL.
It is also easier to read and makes it possible to omit the "" (for function and short_description). Have
a look at the files with
extension .def in the GNU APL src directory to see how this type of macro is being used. Like
src/SystemVariable.def
which packs together figgerent properties of ⎕-Variables from which later on the )HELP texts for the
⎕-variables is derived.
help_def(1, "+B", Conjugate, "Returns the conjugate of B")
help_def(2, "A+B", Add, "Returns the sum of A and B")
Finally it would be good if whoever provides this is willing to release it under the GPL like all other GNU
APL code.
So all the help_def macros should go into a single file, say Help.def with the usual GPL text at the
beginning and
whoever has provided it as the Copyright holder.
I will then be happy to change the )HELP command to display the texts provided.
Thanks,
JÃŒrgen
Hi,
Indeed I was also thinking on creating such a documentation even in terms of notes for myself. I
don't always use Emacs for GNU APL (I run it on a device where I'm not able to compile emacs
but fine to compile GNU APL), so I would be happy to read this documentation from within the
interpreter, for example using like
]help ⍣
or
]help ⎕FX
Br,
/Alexey
The Emacs mode for GNU APL contains a (small) reference manual. Really nothing more
than a short paragraph on most system functions, enough for the integrated documentation
features to work. It's been pointed out to me that it would be nice if the documentation was
more complete, particularly with examples of the use of each function in addition to the
abstract explanation as to what it does.
Now, I feel that this documentation doesn't really belong in the Emacs mode. It belongs in
GNU APL itself. Emacs should simply access this from the APL runtime when needed,
Thus, I would like to suggest creating an integrated reference documentation inside GNU
APL itself. We could start with what I have in the Emacs mode, and then add more.
* Invocation type (monadic, dyadic, etc)
* Name of the function
* One-line summary of the function
* (optional) Longer description
1 Is anybody willing to help out with expanding in the reference documentation?
2 For JÃŒrgen, are you willing to put this into GNU APL itself instead of keeping it in the
Emacs mode?
Regards,
Elias
--
Br,
/Alexey
---
Louis Chrétien
Juergen Sauermann
2017-04-17 10:37:00 UTC
Permalink
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Helvetica, Arial, sans-serif">Hi Alexey,<br>
<br>
thanks a lot, I will integrate it into GNU APL.<br>
I will also fix the typos reported by Louis.<br>
<br>
/// Jürgen<br>
<br>
</font><br>
<div class="moz-cite-prefix">On 04/16/2017 10:19 PM, Alexey
Veretennikov wrote:<br>
</div>
<blockquote cite="mid:***@MacBook-Pro-2.lan" type="cite">
<pre wrap="">Hi Juergen, Elias,

I've converted documentation from GNU APL Emacs mode with permission of
Elias to the format proposed by you.

I've only added additional 2nd argument with the plain symbol/text of
the function/operator to make it easier to parse/lookup.

I've not reviewed this documentation, just converted it to this format
and fixed naming conventions.
Please note what this is just a beginning and I hope myself and
community will work on this file further and hopefully continuously,
refining the open GNU APL documentation.


</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">


Juergen Sauermann <a class="moz-txt-link-rfc2396E" href="mailto:***@t-online.de">&lt;***@t-online.de&gt;</a> writes:

</pre>
<blockquote type="cite">
<pre wrap="">Hi again,

one more thing. In the IBM documentation the functions are usually denoted in a form like this:

Z←L+R using Z for the result and L and R for the left and right value arguments.

The ISO standard (also mainly written by IBM uses:

Z←A+B using Z for the result and A and B for the left and right value arguments.

My personal preference used to be:

R←A+B using R for the result and A and B for the left and right arguments. I guess this was from
Gilman/Rose, but I am not sure.

The GNU source code uses Z, A, and B as well as LO and RO for the left and right function arguments of
operators.
The info apl also uses A and B. I would therefore like to prose (objections welcome) to use the Z←A f B
for functions
and Z←A (LO op RO) B for e.g. dyadic operators.

Best Regards,
Jürgen Sauermann

On 04/11/2017 08:20 PM, Juergen Sauermann wrote:

Hi,

it would be good if someone could provide the help texts. Ideally as a macro called help_def() like
this:

help_def(valence, function, short_decription, long_description)

with: valence: number (0 for niladic, 1 for monadic, or 2 for dyadic)
function: String literal or just the text
short_description: String literal or just the text
long_decription: String literal or just the text

Please no comma or ; at the end of the macro, and one line per macro (no \ continuation).

Using a macro as opposed to instantiating struct has the advantage that it is easier to integrate into
the C++ code of GNU APL.
It is also easier to read and makes it possible to omit the "" (for function and short_description). Have
a look at the files with
extension .def in the GNU APL src directory to see how this type of macro is being used. Like
src/SystemVariable.def
which packs together figgerent properties of ⎕-Variables from which later on the )HELP texts for the
⎕-variables is derived.
For example:

help_def(1, "+B", Conjugate, "Returns the conjugate of B")
help_def(2, "A+B", Add, "Returns the sum of A and B")

Finally it would be good if whoever provides this is willing to release it under the GPL like all other GNU
APL code.
So all the help_def macros should go into a single file, say Help.def with the usual GPL text at the
beginning and
whoever has provided it as the Copyright holder.

I will then be happy to change the )HELP command to display the texts provided.

Thanks,
Jürgen

On 04/11/2017 04:34 PM, Alexey Veretennikov wrote:

Hi,

Indeed I was also thinking on creating such a documentation even in terms of notes for myself. I
don't always use Emacs for GNU APL (I run it on a device where I'm not able to compile emacs
but fine to compile GNU APL), so I would be happy to read this documentation from within the
interpreter, for example using like
]help ⍣
or
]help ⎕FX

Br,
/Alexey

2017-04-11 10:22 GMT+02:00 Elias Mårtenson <a class="moz-txt-link-rfc2396E" href="mailto:***@gmail.com">&lt;***@gmail.com&gt;</a>:

The Emacs mode for GNU APL contains a (small) reference manual. Really nothing more
than a short paragraph on most system functions, enough for the integrated documentation
features to work. It's been pointed out to me that it would be nice if the documentation was
more complete, particularly with examples of the use of each function in addition to the
abstract explanation as to what it does.

Now, I feel that this documentation doesn't really belong in the Emacs mode. It belongs in
GNU APL itself. Emacs should simply access this from the APL runtime when needed,

Thus, I would like to suggest creating an integrated reference documentation inside GNU
APL itself. We could start with what I have in the Emacs mode, and then add more.

The following file contains the current documentation in the Emacs mode:

Each element contains three strings:

* Invocation type (monadic, dyadic, etc)
* Name of the function
* One-line summary of the function
* (optional) Longer description

There are two questions:

1 Is anybody willing to help out with expanding in the reference documentation?
2 For Jürgen, are you willing to put this into GNU APL itself instead of keeping it in the
Emacs mode?

Regards,
Elias


</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
</body>
</html>
Elias Mårtenson
2017-04-17 11:18:19 UTC
Permalink
Hello JÃŒrgen,

What is the API provided to programmatically access the documentation for a
given function?

Whatever the API is, may I suggest that this function also accepts any
defined function? The text returned should of course be the content of the
comment header (i.e. the comments at the beginning of the function prefixed
with two ⍝ symbols. The first line is the summary, while the rest is the
long description.

For the benefit of others on the list that doesn't know how that works,
here's an example from the SQL library:

∇Z←statement SQL∆Select[db] args
⍝⍝ Execute a select statement and return the result table.
⍝⍝
⍝⍝ The axis parameter indicates the database handle.
⍝⍝
⍝⍝ L is a select statement to be executed. Positional parameters can
⍝⍝ be supplied by specifying a question mark "?" in the statemement.
⍝⍝
⍝⍝ R is an array containing the values for the positional parameters.
⍝⍝ If the array is of rank 2, the statement will be executed multiple
⍝⍝ times with each row being the values for each call.
⍝⍝
⍝⍝ The return value is a rank-2 array representing the result of the
⍝⍝ select statement. Null values are returned as ⍬ and empty strings
⍝⍝ are returned as ''.
Z←statement ⎕SQL[3,db] args
∇
Post by Juergen Sauermann
Hi Alexey,
thanks a lot, I will integrate it into GNU APL.
I will also fix the typos reported by Louis.
/// JÃŒrgen
Hi Juergen, Elias,
I've converted documentation from GNU APL Emacs mode with permission of
Elias to the format proposed by you.
I've only added additional 2nd argument with the plain symbol/text of
the function/operator to make it easier to parse/lookup.
I've not reviewed this documentation, just converted it to this format
and fixed naming conventions.
Please note what this is just a beginning and I hope myself and
community will work on this file further and hopefully continuously,
refining the open GNU APL documentation.
Hi again,
Z←L+R using Z for the result and L and R for the left and right value arguments.
Z←A+B using Z for the result and A and B for the left and right value arguments.
R←A+B using R for the result and A and B for the left and right arguments. I guess this was from
Gilman/Rose, but I am not sure.
The GNU source code uses Z, A, and B as well as LO and RO for the left and right function arguments of
operators.
The info apl also uses A and B. I would therefore like to prose (objections welcome) to use the Z←A f B
for functions
and Z←A (LO op RO) B for e.g. dyadic operators.
Best Regards,
JÃŒrgen Sauermann
Hi,
it would be good if someone could provide the help texts. Ideally as a macro called help_def() like
help_def(valence, function, short_decription, long_description)
with: valence: number (0 for niladic, 1 for monadic, or 2 for dyadic)
function: String literal or just the text
short_description: String literal or just the text
long_decription: String literal or just the text
Please no comma or ; at the end of the macro, and one line per macro (no \ continuation).
Using a macro as opposed to instantiating struct has the advantage that it is easier to integrate into
the C++ code of GNU APL.
It is also easier to read and makes it possible to omit the "" (for function and short_description). Have
a look at the files with
extension .def in the GNU APL src directory to see how this type of macro is being used. Like
src/SystemVariable.def
which packs together figgerent properties of ⎕-Variables from which later on the )HELP texts for the
⎕-variables is derived.
help_def(1, "+B", Conjugate, "Returns the conjugate of B")
help_def(2, "A+B", Add, "Returns the sum of A and B")
Finally it would be good if whoever provides this is willing to release it under the GPL like all other GNU
APL code.
So all the help_def macros should go into a single file, say Help.def with the usual GPL text at the
beginning and
whoever has provided it as the Copyright holder.
I will then be happy to change the )HELP command to display the texts provided.
Thanks,
JÃŒrgen
Hi,
Indeed I was also thinking on creating such a documentation even in terms of notes for myself. I
don't always use Emacs for GNU APL (I run it on a device where I'm not able to compile emacs
but fine to compile GNU APL), so I would be happy to read this documentation from within the
interpreter, for example using like
]help ⍣
or
]help ⎕FX
Br,
/Alexey
The Emacs mode for GNU APL contains a (small) reference manual. Really nothing more
than a short paragraph on most system functions, enough for the integrated documentation
features to work. It's been pointed out to me that it would be nice if the documentation was
more complete, particularly with examples of the use of each function in addition to the
abstract explanation as to what it does.
Now, I feel that this documentation doesn't really belong in the Emacs mode. It belongs in
GNU APL itself. Emacs should simply access this from the APL runtime when needed,
Thus, I would like to suggest creating an integrated reference documentation inside GNU
APL itself. We could start with what I have in the Emacs mode, and then add more.
* Invocation type (monadic, dyadic, etc)
* Name of the function
* One-line summary of the function
* (optional) Longer description
1 Is anybody willing to help out with expanding in the reference documentation?
2 For JÃŒrgen, are you willing to put this into GNU APL itself instead of keeping it in the
Emacs mode?
Regards,
Elias
Juergen Sauermann
2017-04-17 18:16:40 UTC
Permalink
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Elias,<br>
<br>
the API to the APL help texts is the <b>help_def</b><b>()</b>
macro. See e.g. <b>Command.cc</b> line <b>778</b>.<br>
<br>
Showing <b>)HELP</b> for defined function seems to be a cool idea,
but I need a little more time<br>
for that.<br>
<br>
Best Regards,<br>
/// Jürgen<br>
<br>
<br>
<div class="moz-cite-prefix">On 04/17/2017 01:18 PM, Elias Mårtenson
wrote:<br>
</div>
<blockquote
cite="mid:CADtN0WJA7CLHsCv_o+Kuh=kQ4sPqaAEdYfk=***@mail.gmail.com"
type="cite">
<div dir="ltr">Hello Jürgen,
<div><br>
</div>
<div>What is the API provided to programmatically access the
documentation for a given function?</div>
<div><br>
</div>
<div>Whatever the API is, may I suggest that this function also
accepts any defined function? The text returned should of
course be the content of the comment header (i.e. the comments
at the beginning of the function prefixed with two ⍝ symbols.
The first line is the summary, while the rest is the long
description.</div>
<div><br>
</div>
<div>For the benefit of others on the list that doesn't know how
that works, here's an example from the SQL library:</div>
<div><br>
</div>
<div>
<div>∇Z←statement SQL∆Select[db] args</div>
<div>⍝⍝ Execute a select statement and return the result
table.</div>
<div>⍝⍝</div>
<div>⍝⍝ The axis parameter indicates the database handle.</div>
<div>⍝⍝</div>
<div>⍝⍝ L is a select statement to be executed. Positional
parameters can</div>
<div>⍝⍝ be supplied by specifying a question mark "?" in the
statemement.</div>
<div>⍝⍝</div>
<div>⍝⍝ R is an array containing the values for the positional
parameters.</div>
<div>⍝⍝ If the array is of rank 2, the statement will be
executed multiple</div>
<div>⍝⍝ times with each row being the values for each call.</div>
<div>⍝⍝</div>
<div>⍝⍝ The return value is a rank-2 array representing the
result of the</div>
<div>⍝⍝ select statement. Null values are returned as ⍬ and
empty strings</div>
<div>⍝⍝ are returned as ''.</div>
<div>  Z←statement ⎕SQL[3,db] args</div>
<div>∇</div>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
</div>
</blockquote>
<br>
</body>
</html>
Juergen Sauermann
2017-04-17 18:06:35 UTC
Permalink
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Helvetica, Arial, sans-serif">Hi,<br>
<br>
I have integrated Alexey's help texts into GNU APL. <b>SVN 921</b>.<br>
</font><br>
To display help for an APL primitive say e.g.<br>
<br>
<font face="Courier New, Courier, monospace"><b>      ]HELP ⌹</b><b><br>
</b><b>    monadic function: Z ← ⌹ B (Matrix inverse)</b><b><br>
</b><b>    Inverse of matrix B</b><b><br>
</b><b><br>
</b><b>    dyadic function:  Z ← A ⌹ B (Matrix divide)</b><b><br>
</b><b>    Solution to system of linear equations Ax = B</b></font><br>
<br>
To get a list of all primitives use tab-expansion (which also works
for other things like filenames,<br>
user defined and distinguished names, etc, depending on context):<br>
<br>
<font face="Courier New, Courier, monospace"><b>      ]HELP 
&lt;TAB&gt;</b><b><br> </b><b>Help topics (APL primitives) are:</b><b><br> </b><b> + - × ÷ ⋆ ⍟ ⌈ ⌊ ∣ ∼ ! &lt; ≤ = ≥ &gt; ≠ ∨ ∧ ⍱ ⍲ ○ ? ∊ ⍷ ⍴
↑ ↓ , \ ⍀ / ⌿ ⍳ ⌹ ⌽ ⊖ ⍕ ⍉</b><b><br>
</b><b> ⍋ ⍒ ⍎ ⊂ ⊃ ∪ ≡ ≢ ⊥ ⊤ ⊢ ⊣ ⍪ ← → ∇ ⍨ ¨ .</b><b><br>
</b></font><br>
The descriptions deserve some more polishing, in particular for
consistency and terminology.<br>
<br>
Enjoy,<br>
Jürgen<br>
<br>
<br>
<div class="moz-cite-prefix">On 04/16/2017 10:19 PM, Alexey
Veretennikov wrote:<br>
</div>
<blockquote cite="mid:***@MacBook-Pro-2.lan" type="cite">
<pre wrap="">Hi Juergen, Elias,

I've converted documentation from GNU APL Emacs mode with permission of
Elias to the format proposed by you.

I've only added additional 2nd argument with the plain symbol/text of
the function/operator to make it easier to parse/lookup.

I've not reviewed this documentation, just converted it to this format
and fixed naming conventions.
Please note what this is just a beginning and I hope myself and
community will work on this file further and hopefully continuously,
refining the open GNU APL documentation.


</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">


Juergen Sauermann <a class="moz-txt-link-rfc2396E" href="mailto:***@t-online.de">&lt;***@t-online.de&gt;</a> writes:

</pre>
<blockquote type="cite">
<pre wrap="">Hi again,

one more thing. In the IBM documentation the functions are usually denoted in a form like this:

Z←L+R using Z for the result and L and R for the left and right value arguments.

The ISO standard (also mainly written by IBM uses:

Z←A+B using Z for the result and A and B for the left and right value arguments.

My personal preference used to be:

R←A+B using R for the result and A and B for the left and right arguments. I guess this was from
Gilman/Rose, but I am not sure.

The GNU source code uses Z, A, and B as well as LO and RO for the left and right function arguments of
operators.
The info apl also uses A and B. I would therefore like to prose (objections welcome) to use the Z←A f B
for functions
and Z←A (LO op RO) B for e.g. dyadic operators.

Best Regards,
Jürgen Sauermann

On 04/11/2017 08:20 PM, Juergen Sauermann wrote:

Hi,

it would be good if someone could provide the help texts. Ideally as a macro called help_def() like
this:

help_def(valence, function, short_decription, long_description)

with: valence: number (0 for niladic, 1 for monadic, or 2 for dyadic)
function: String literal or just the text
short_description: String literal or just the text
long_decription: String literal or just the text

Please no comma or ; at the end of the macro, and one line per macro (no \ continuation).

Using a macro as opposed to instantiating struct has the advantage that it is easier to integrate into
the C++ code of GNU APL.
It is also easier to read and makes it possible to omit the "" (for function and short_description). Have
a look at the files with
extension .def in the GNU APL src directory to see how this type of macro is being used. Like
src/SystemVariable.def
which packs together figgerent properties of ⎕-Variables from which later on the )HELP texts for the
⎕-variables is derived.
For example:

help_def(1, "+B", Conjugate, "Returns the conjugate of B")
help_def(2, "A+B", Add, "Returns the sum of A and B")

Finally it would be good if whoever provides this is willing to release it under the GPL like all other GNU
APL code.
So all the help_def macros should go into a single file, say Help.def with the usual GPL text at the
beginning and
whoever has provided it as the Copyright holder.

I will then be happy to change the )HELP command to display the texts provided.

Thanks,
Jürgen

On 04/11/2017 04:34 PM, Alexey Veretennikov wrote:

Hi,

Indeed I was also thinking on creating such a documentation even in terms of notes for myself. I
don't always use Emacs for GNU APL (I run it on a device where I'm not able to compile emacs
but fine to compile GNU APL), so I would be happy to read this documentation from within the
interpreter, for example using like
]help ⍣
or
]help ⎕FX

Br,
/Alexey

2017-04-11 10:22 GMT+02:00 Elias Mårtenson <a class="moz-txt-link-rfc2396E" href="mailto:***@gmail.com">&lt;***@gmail.com&gt;</a>:

The Emacs mode for GNU APL contains a (small) reference manual. Really nothing more
than a short paragraph on most system functions, enough for the integrated documentation
features to work. It's been pointed out to me that it would be nice if the documentation was
more complete, particularly with examples of the use of each function in addition to the
abstract explanation as to what it does.

Now, I feel that this documentation doesn't really belong in the Emacs mode. It belongs in
GNU APL itself. Emacs should simply access this from the APL runtime when needed,

Thus, I would like to suggest creating an integrated reference documentation inside GNU
APL itself. We could start with what I have in the Emacs mode, and then add more.

The following file contains the current documentation in the Emacs mode:

Each element contains three strings:

* Invocation type (monadic, dyadic, etc)
* Name of the function
* One-line summary of the function
* (optional) Longer description

There are two questions:

1 Is anybody willing to help out with expanding in the reference documentation?
2 For Jürgen, are you willing to put this into GNU APL itself instead of keeping it in the
Emacs mode?

Regards,
Elias


</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
</body>
</html>
Alexey Veretennikov
2017-04-17 18:52:03 UTC
Permalink
Hi,

Thanks! This is awesome.
I can't build this version however:

QuadFunction.cc:120:2: error: 'doFooWithExtendedMarkupLanguageSoon' does not name a type
}doFooWithExtendedMarkupLanguageSoon
^
Hi,
I have integrated Alexey's help texts into GNU APL. SVN 921.
To display help for an APL primitive say e.g.
]HELP ⌹
monadic function: Z ← ⌹ B (Matrix inverse)
Inverse of matrix B
dyadic function: Z ← A ⌹ B (Matrix divide)
Solution to system of linear equations Ax = B
To get a list of all primitives use tab-expansion (which also works for other things like filenames,
]HELP <TAB>
+ - × ÷ ⋆ ⍟ ⌈ ⌊ ∣ ∼ ! < ≤ = ≥ > ≠ ∨ ∧ ⍱ ⍲ ○ ? ∊ ⍷ ⍴ ↑ ↓ , \ ⍀ / ⌿ ⍳ ⌹ ⌽ ⊖ ⍕ ⍉
⍋ ⍒ ⍎ ⊂ ⊃ ∪ ≡ ≢ ⊥ ⊤ ⊢ ⊣ ⍪ ← → ∇ ⍨ ¨ .
The descriptions deserve some more polishing, in particular for consistency and terminology.
Enjoy,
Jürgen
Hi Juergen, Elias,
I've converted documentation from GNU APL Emacs mode with permission of
Elias to the format proposed by you.
I've only added additional 2nd argument with the plain symbol/text of
the function/operator to make it easier to parse/lookup.
I've not reviewed this documentation, just converted it to this format
and fixed naming conventions.
Please note what this is just a beginning and I hope myself and
community will work on this file further and hopefully continuously,
refining the open GNU APL documentation.
Hi again,
Z←L+R using Z for the result and L and R for the left and right value arguments.
Z←A+B using Z for the result and A and B for the left and right value arguments.
R←A+B using R for the result and A and B for the left and right arguments. I guess this was from
Gilman/Rose, but I am not sure.
The GNU source code uses Z, A, and B as well as LO and RO for the left and right function arguments of
operators.
The info apl also uses A and B. I would therefore like to prose (objections welcome) to use the Z←A f B
for functions
and Z←A (LO op RO) B for e.g. dyadic operators.
Best Regards,
Jürgen Sauermann
Hi,
it would be good if someone could provide the help texts. Ideally as a macro called help_def() like
help_def(valence, function, short_decription, long_description)
with: valence: number (0 for niladic, 1 for monadic, or 2 for dyadic)
function: String literal or just the text
short_description: String literal or just the text
long_decription: String literal or just the text
Please no comma or ; at the end of the macro, and one line per macro (no \ continuation).
Using a macro as opposed to instantiating struct has the advantage that it is easier to integrate into
the C++ code of GNU APL.
It is also easier to read and makes it possible to omit the "" (for function and short_description). Have
a look at the files with
extension .def in the GNU APL src directory to see how this type of macro is being used. Like
src/SystemVariable.def
which packs together figgerent properties of ⎕-Variables from which later on the )HELP texts for the
⎕-variables is derived.
help_def(1, "+B", Conjugate, "Returns the conjugate of B")
help_def(2, "A+B", Add, "Returns the sum of A and B")
Finally it would be good if whoever provides this is willing to release it under the GPL like all other GNU
APL code.
So all the help_def macros should go into a single file, say Help.def with the usual GPL text at the
beginning and
whoever has provided it as the Copyright holder.
I will then be happy to change the )HELP command to display the texts provided.
Thanks,
Jürgen
Hi,
Indeed I was also thinking on creating such a documentation even in terms of notes for myself. I
don't always use Emacs for GNU APL (I run it on a device where I'm not able to compile emacs
but fine to compile GNU APL), so I would be happy to read this documentation from within the
interpreter, for example using like
]help ⍣
or
]help ⎕FX
Br,
/Alexey
The Emacs mode for GNU APL contains a (small) reference manual. Really nothing more
than a short paragraph on most system functions, enough for the integrated documentation
features to work. It's been pointed out to me that it would be nice if the documentation was
more complete, particularly with examples of the use of each function in addition to the
abstract explanation as to what it does.
Now, I feel that this documentation doesn't really belong in the Emacs mode. It belongs in
GNU APL itself. Emacs should simply access this from the APL runtime when needed,
Thus, I would like to suggest creating an integrated reference documentation inside GNU
APL itself. We could start with what I have in the Emacs mode, and then add more.
* Invocation type (monadic, dyadic, etc)
* Name of the function
* One-line summary of the function
* (optional) Longer description
1 Is anybody willing to help out with expanding in the reference documentation?
2 For Jürgen, are you willing to put this into GNU APL itself instead of keeping it in the
Emacs mode?
Regards,
Elias
--
Br,
/Alexey
Juergen Sauermann
2017-04-17 19:07:56 UTC
Permalink
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Helvetica, Arial, sans-serif">Hi Alexey,<br>
<br>
that string appears nowhere in my code:<br>
<br>
<font face="Courier New, Courier, monospace"><b><a class="moz-txt-link-abbreviated" href="mailto:***@server66:~/projects/juergen/apl-1.7$">***@server66:~/projects/juergen/apl-1.7$</a>
grep -r doFooWithExtendedMarkupLanguageSoon .</b><b><br>
</b><b><a class="moz-txt-link-abbreviated" href="mailto:***@server66:~/projects/juergen/apl-1.7$">***@server66:~/projects/juergen/apl-1.7$</a> </b><b><br>
</b></font></font><br>
And QuadFunction.cc:120 simply reads:<br>
<br>
<font face="Courier New, Courier, monospace"><b>}</b></font><br>
<br>
and hasn't changed in the last 4 weeks.<br>
<br>
/// Jürgen<br>
<br>
<br>
<div class="moz-cite-prefix">On 04/17/2017 08:52 PM, Alexey
Veretennikov wrote:<br>
</div>
<blockquote cite="mid:***@MacBook-Pro-2.lan" type="cite">
<pre wrap="">Hi,

Thanks! This is awesome.
I can't build this version however:

QuadFunction.cc:120:2: error: 'doFooWithExtendedMarkupLanguageSoon' does not name a type
}doFooWithExtendedMarkupLanguageSoon
^


Juergen Sauermann <a class="moz-txt-link-rfc2396E" href="mailto:***@t-online.de">&lt;***@t-online.de&gt;</a> writes:

</pre>
<blockquote type="cite">
<pre wrap="">Hi,

I have integrated Alexey's help texts into GNU APL. SVN 921.

To display help for an APL primitive say e.g.

]HELP ⌹
monadic function: Z ← ⌹ B (Matrix inverse)
Inverse of matrix B

dyadic function: Z ← A ⌹ B (Matrix divide)
Solution to system of linear equations Ax = B

To get a list of all primitives use tab-expansion (which also works for other things like filenames,
user defined and distinguished names, etc, depending on context):

]HELP &lt;TAB&gt;
Help topics (APL primitives) are:
+ - × ÷ ⋆ ⍟ ⌈ ⌊ ∣ ∼ ! &lt; ≤ = ≥ &gt; ≠ ∨ ∧ ⍱ ⍲ ○ ? ∊ ⍷ ⍴ ↑ ↓ , \ ⍀ / ⌿ ⍳ ⌹ ⌽ ⊖ ⍕ ⍉
⍋ ⍒ ⍎ ⊂ ⊃ ∪ ≡ ≢ ⊥ ⊤ ⊢ ⊣ ⍪ ← → ∇ ⍨ ¨ .

The descriptions deserve some more polishing, in particular for consistency and terminology.

Enjoy,
Jürgen

On 04/16/2017 10:19 PM, Alexey Veretennikov wrote:

Hi Juergen, Elias,

I've converted documentation from GNU APL Emacs mode with permission of
Elias to the format proposed by you.

I've only added additional 2nd argument with the plain symbol/text of
the function/operator to make it easier to parse/lookup.

I've not reviewed this documentation, just converted it to this format
and fixed naming conventions.
Please note what this is just a beginning and I hope myself and
community will work on this file further and hopefully continuously,
refining the open GNU APL documentation.





Juergen Sauermann <a class="moz-txt-link-rfc2396E" href="mailto:***@t-online.de">&lt;***@t-online.de&gt;</a> writes:

Hi again,

one more thing. In the IBM documentation the functions are usually denoted in a form like this:

Z←L+R using Z for the result and L and R for the left and right value arguments.

The ISO standard (also mainly written by IBM uses:

Z←A+B using Z for the result and A and B for the left and right value arguments.

My personal preference used to be:

R←A+B using R for the result and A and B for the left and right arguments. I guess this was from
Gilman/Rose, but I am not sure.

The GNU source code uses Z, A, and B as well as LO and RO for the left and right function arguments of
operators.
The info apl also uses A and B. I would therefore like to prose (objections welcome) to use the Z←A f B
for functions
and Z←A (LO op RO) B for e.g. dyadic operators.

Best Regards,
Jürgen Sauermann

On 04/11/2017 08:20 PM, Juergen Sauermann wrote:

Hi,

it would be good if someone could provide the help texts. Ideally as a macro called help_def() like
this:

help_def(valence, function, short_decription, long_description)

with: valence: number (0 for niladic, 1 for monadic, or 2 for dyadic)
function: String literal or just the text
short_description: String literal or just the text
long_decription: String literal or just the text

Please no comma or ; at the end of the macro, and one line per macro (no \ continuation).

Using a macro as opposed to instantiating struct has the advantage that it is easier to integrate into
the C++ code of GNU APL.
It is also easier to read and makes it possible to omit the "" (for function and short_description). Have
a look at the files with
extension .def in the GNU APL src directory to see how this type of macro is being used. Like
src/SystemVariable.def
which packs together figgerent properties of ⎕-Variables from which later on the )HELP texts for the
⎕-variables is derived.
For example:

help_def(1, "+B", Conjugate, "Returns the conjugate of B")
help_def(2, "A+B", Add, "Returns the sum of A and B")

Finally it would be good if whoever provides this is willing to release it under the GPL like all other GNU
APL code.
So all the help_def macros should go into a single file, say Help.def with the usual GPL text at the
beginning and
whoever has provided it as the Copyright holder.

I will then be happy to change the )HELP command to display the texts provided.

Thanks,
Jürgen

On 04/11/2017 04:34 PM, Alexey Veretennikov wrote:

Hi,

Indeed I was also thinking on creating such a documentation even in terms of notes for myself. I
don't always use Emacs for GNU APL (I run it on a device where I'm not able to compile emacs
but fine to compile GNU APL), so I would be happy to read this documentation from within the
interpreter, for example using like
]help ⍣
or
]help ⎕FX

Br,
/Alexey

2017-04-11 10:22 GMT+02:00 Elias Mårtenson <a class="moz-txt-link-rfc2396E" href="mailto:***@gmail.com">&lt;***@gmail.com&gt;</a>:

The Emacs mode for GNU APL contains a (small) reference manual. Really nothing more
than a short paragraph on most system functions, enough for the integrated documentation
features to work. It's been pointed out to me that it would be nice if the documentation was
more complete, particularly with examples of the use of each function in addition to the
abstract explanation as to what it does.

Now, I feel that this documentation doesn't really belong in the Emacs mode. It belongs in
GNU APL itself. Emacs should simply access this from the APL runtime when needed,

Thus, I would like to suggest creating an integrated reference documentation inside GNU
APL itself. We could start with what I have in the Emacs mode, and then add more.

The following file contains the current documentation in the Emacs mode:

Each element contains three strings:

* Invocation type (monadic, dyadic, etc)
* Name of the function
* One-line summary of the function
* (optional) Longer description

There are two questions:

1 Is anybody willing to help out with expanding in the reference documentation?
2 For Jürgen, are you willing to put this into GNU APL itself instead of keeping it in the
Emacs mode?

Regards,
Elias




</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
</body>
</html>
Alexey Veretennikov
2017-04-17 19:27:44 UTC
Permalink
Hi,

My bad, apparently I've accidentally modified the source file while
browsing around the code.

Thanks, looks like it (help) works now!
Post by Juergen Sauermann
Hi Alexey,
}
and hasn't changed in the last 4 weeks.
/// Jürgen
Hi,
Thanks! This is awesome.
QuadFunction.cc:120:2: error: 'doFooWithExtendedMarkupLanguageSoon' does not name a type
}doFooWithExtendedMarkupLanguageSoon
^
Hi,
I have integrated Alexey's help texts into GNU APL. SVN 921.
To display help for an APL primitive say e.g.
]HELP ⌹
monadic function: Z ← ⌹ B (Matrix inverse)
Inverse of matrix B
dyadic function: Z ← A ⌹ B (Matrix divide)
Solution to system of linear equations Ax = B
To get a list of all primitives use tab-expansion (which also works for other things like filenames,
]HELP <TAB>
+ - × ÷ ⋆ ⍟ ⌈ ⌊ ∣ ∼ ! < ≤ = ≥ > ≠ ∨ ∧ ⍱ ⍲ ○ ? ∊ ⍷ ⍴ ↑ ↓ , \ ⍀ / ⌿ ⍳ ⌹ ⌽ ⊖ ⍕ ⍉
⍋ ⍒ ⍎ ⊂ ⊃ ∪ ≡ ≢ ⊥ ⊤ ⊢ ⊣ ⍪ ← → ∇ ⍨ ¨ .
The descriptions deserve some more polishing, in particular for consistency and terminology.
Enjoy,
Jürgen
Hi Juergen, Elias,
I've converted documentation from GNU APL Emacs mode with permission of
Elias to the format proposed by you.
I've only added additional 2nd argument with the plain symbol/text of
the function/operator to make it easier to parse/lookup.
I've not reviewed this documentation, just converted it to this format
and fixed naming conventions.
Please note what this is just a beginning and I hope myself and
community will work on this file further and hopefully continuously,
refining the open GNU APL documentation.
Hi again,
Z←L+R using Z for the result and L and R for the left and right value arguments.
Z←A+B using Z for the result and A and B for the left and right value arguments.
R←A+B using R for the result and A and B for the left and right arguments. I guess this was from
Gilman/Rose, but I am not sure.
The GNU source code uses Z, A, and B as well as LO and RO for the left and right function arguments of
operators.
The info apl also uses A and B. I would therefore like to prose (objections welcome) to use the Z←A f B
for functions
and Z←A (LO op RO) B for e.g. dyadic operators.
Best Regards,
Jürgen Sauermann
Hi,
it would be good if someone could provide the help texts. Ideally as a macro called help_def() like
help_def(valence, function, short_decription, long_description)
with: valence: number (0 for niladic, 1 for monadic, or 2 for dyadic)
function: String literal or just the text
short_description: String literal or just the text
long_decription: String literal or just the text
Please no comma or ; at the end of the macro, and one line per macro (no \ continuation).
Using a macro as opposed to instantiating struct has the advantage that it is easier to integrate into
the C++ code of GNU APL.
It is also easier to read and makes it possible to omit the "" (for function and short_description). Have
a look at the files with
extension .def in the GNU APL src directory to see how this type of macro is being used. Like
src/SystemVariable.def
which packs together figgerent properties of ⎕-Variables from which later on the )HELP texts for the
⎕-variables is derived.
help_def(1, "+B", Conjugate, "Returns the conjugate of B")
help_def(2, "A+B", Add, "Returns the sum of A and B")
Finally it would be good if whoever provides this is willing to release it under the GPL like all other GNU
APL code.
So all the help_def macros should go into a single file, say Help.def with the usual GPL text at the
beginning and
whoever has provided it as the Copyright holder.
I will then be happy to change the )HELP command to display the texts provided.
Thanks,
Jürgen
Hi,
Indeed I was also thinking on creating such a documentation even in terms of notes for myself. I
don't always use Emacs for GNU APL (I run it on a device where I'm not able to compile emacs
but fine to compile GNU APL), so I would be happy to read this documentation from within the
interpreter, for example using like
]help ⍣
or
]help ⎕FX
Br,
/Alexey
The Emacs mode for GNU APL contains a (small) reference manual. Really nothing more
than a short paragraph on most system functions, enough for the integrated documentation
features to work. It's been pointed out to me that it would be nice if the documentation was
more complete, particularly with examples of the use of each function in addition to the
abstract explanation as to what it does.
Now, I feel that this documentation doesn't really belong in the Emacs mode. It belongs in
GNU APL itself. Emacs should simply access this from the APL runtime when needed,
Thus, I would like to suggest creating an integrated reference documentation inside GNU
APL itself. We could start with what I have in the Emacs mode, and then add more.
* Invocation type (monadic, dyadic, etc)
* Name of the function
* One-line summary of the function
* (optional) Longer description
1 Is anybody willing to help out with expanding in the reference documentation?
2 For Jürgen, are you willing to put this into GNU APL itself instead of keeping it in the
Emacs mode?
Regards,
Elias
--
Br,
/Alexey
Xiao-Yong Jin
2017-04-17 19:18:01 UTC
Permalink
dyadic function: Z ← A ⌹ B (Matrix divide)
Solution to system of linear equations Ax = B
That should be "A = Bx"

It seems that ⍤ and ⍣ are not in the list.
I guess that's because they are not in APL2?
Juergen Sauermann
2017-04-17 21:31:11 UTC
Permalink
Hi Xiao-Yong,

thanks, I have added *⍤*, *⍣*, and *⍬* to *)HELP* in *SVN 923*.

No Idea what *⍥* is, and GNU APL seems not to support it. Nor does ISO
or APL2.

What I do know is *ö* and *Ö* (German Umlaute: *ö* is lower-case and *Ö*
is upper-case).
I suppose *⍥* is German middle-case then :-).

/// Jürgen
Post by Xiao-Yong Jin
dyadic function: Z ← A ⌹ B (Matrix divide)
Solution to system of linear equations Ax = B
That should be "A = Bx"
It seems that ⍤ and ⍣ are not in the list.
I guess that's because they are not in APL2?
Xiao-Yong Jin
2017-04-17 21:54:09 UTC
Permalink
If you haven't added those, the quads are missing too, ⌷ ⎕ ⍞.
In addition, the result of "]HELP ." is not good.
Perhaps describing it as a dyadic operator with a special left operand of ∘ works better.
Post by Juergen Sauermann
Hi Xiao-Yong,
thanks, I have added *⍤*, *⍣*, and *⍬* to *)HELP* in *SVN 923*.
No Idea what *⍥* is, and GNU APL seems not to support it. Nor does ISO or APL2.
What I do know is *ö* and *Ö* (German Umlaute: *ö* is lower-case and *Ö* is upper-case).
I suppose *⍥* is German middle-case then :-).
/// Jürgen
Post by Xiao-Yong Jin
dyadic function: Z ← A ⌹ B (Matrix divide)
Solution to system of linear equations Ax = B
That should be "A = Bx"
It seems that ⍤ and ⍣ are not in the list.
I guess that's because they are not in APL2?
Juergen Sauermann
2017-04-18 11:11:40 UTC
Permalink
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Helvetica, Arial, sans-serif">Hi Xiao-Yong.<br>
<br>
thanks, fixed in <b>SVN 924</b>.  </font><font face="Courier
New, Courier, monospace"><b>⎕</b></font> and <font face="Courier
New, Courier, monospace"><b>⍞</b></font> are now listed as system
variables.<br>
<br>
/// Jürgen<br>
<br>
 <br>
<div class="moz-cite-prefix">On 04/17/2017 11:54 PM, Xiao-Yong Jin
wrote:<br>
</div>
<blockquote
cite="mid:CEDDD1A5-4154-455E-8FD2-***@gmail.com"
type="cite">
<pre wrap="">If you haven't added those, the quads are missing too, ⌷ ⎕ ⍞.
In addition, the result of "]HELP ." is not good.
Perhaps describing it as a dyadic operator with a special left operand of ? works better. </pre> <blockquote type="cite"> <pre wrap="">On Apr 17, 2017, at 4:31 PM, Juergen Sauermann <a class="moz-txt-link-rfc2396E" href="mailto:***@t-online.de">&lt;***@t-online.de&gt;</a> wrote:

Hi Xiao-Yong,

thanks, I have added *⍤*, *⍣*, and *⍬* to *)HELP* in *SVN 923*.

No Idea what *⍥* is, and GNU APL seems not to support it. Nor does ISO or APL2.

What I do know is *ö* and *Ö* (German Umlaute: *ö* is lower-case and *Ö* is upper-case).
I suppose *⍥* is German middle-case then :-).

/// Jürgen


On 04/17/2017 09:18 PM, Xiao-Yong Jin wrote: </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">On Apr 17, 2017, at 1:06 PM, Juergen Sauermann <a class="moz-txt-link-rfc2396E" href="mailto:***@t-online.de">&lt;***@t-online.de&gt;</a> wrote:

dyadic function: Z ← A ⌹ B (Matrix divide)
Solution to system of linear equations Ax = B
</pre>
</blockquote>
<pre wrap="">That should be "A = Bx"

It seems that ⍤ and ⍣ are not in the list.
I guess that's because they are not in APL2?


</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">

</pre>
</blockquote>
<br>
</body>
</html>

Louis de Forcrand
2017-04-18 00:20:57 UTC
Permalink
Ö (the APL symbol, which I don't have access to on this keyboard) was used in Sharp APL as the composition operator (equivalent to @ in modern J). It might still be used for the same purpose in NARS.

Cheers,
Louis
Post by Juergen Sauermann
Hi Xiao-Yong,
thanks, I have added *⍤*, *⍣*, and *⍬* to *)HELP* in *SVN 923*.
No Idea what *⍥* is, and GNU APL seems not to support it. Nor does ISO or APL2.
What I do know is *ö* and *Ö* (German Umlaute: *ö* is lower-case and *Ö* is upper-case).
I suppose *⍥* is German middle-case then :-).
/// Jürgen
Post by Xiao-Yong Jin
dyadic function: Z ← A ⌹ B (Matrix divide)
Solution to system of linear equations Ax = B
That should be "A = Bx"
It seems that ⍤ and ⍣ are not in the list.
I guess that's because they are not in APL2?
Fred Weigel
2017-04-17 19:36:11 UTC
Permalink
Elias, Juergen

I use the "Toronto Toolkit" convention, which looks like this:

∇y←x adjust d;⎕IO;ex;i;line;lmrg;pw;w
 ⍝adjust each row of matrix <d> according to parameters <x>
 ⍝.e ('/' ∆box 'please do not  / enter') = 15 adjust 'please do not
enter'
 ⍝.k formatting
 ⍝.n rml
 ⍝.t 1992.4.24.14.4.17
 ⍝.v 1.0 / 05jan82
 ⍝.v 2.0 / 05apr88 / change order of <x>, use subroutines
 ⍝.v 2.1 / 24apr92 / using signalerror
 ⍝ x[1] width of result in columns
 ⍝ x[2] width of left margin (i.e. number of blank columns)
 ⍝ x[3] number of blank lines to insert between each row
 ⎕IO←1

...and more of the function...

I suspect that if the first line is a lamp line, that can be taken as
the description, and a double-lamp taken as a single lamp. This lamp
line may be indented, and could then be the "help" for the function.
The "Toronto Toolkit" format then has lamp lines with ".x" (. followed
by letter) and data .e is example, .t is timestamp, .v is version, .k
for keywords, .n for name/initials and more. Then there are function in
the Toolkit that handle this data. But, again, the first lamp-line gives
the overview.

Just food for thought.
FredW
Juergen Sauermann
2017-04-17 20:09:27 UTC
Permalink
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Helvetica, Arial, sans-serif">Hi Fred,<br>
<br>
the <font face="Courier New, Courier, monospace"><b>⍝⍝</b></font>
was a proposal to mark Doxygen descriptions in APL. For example in
C/C++<br>
you have normal comments starting with <font face="Courier New,
Courier, monospace"><b>//</b></font> and Doxygen comments
starting with <font face="Courier New, Courier, monospace"><b>///</b></font>.<br>
Or <font face="Courier New, Courier, monospace"><b>/* </b></font>for
normal comments and <font face="Courier New, Courier, monospace"><b>/**</b></font>
for Doxygen comments.<br>
<br>
Best Regards,<br>
Jürgen<br>
<br>
</font><br>
<div class="moz-cite-prefix">On 04/17/2017 09:36 PM, Fred Weigel
wrote:<br>
</div>
<blockquote cite="mid:***@crisys.com"
type="cite">
<pre wrap="">Elias, Juergen

I use the "Toronto Toolkit" convention, which looks like this:

∇y←x adjust d;⎕IO;ex;i;line;lmrg;pw;w
 ⍝adjust each row of matrix &lt;d&gt; according to parameters &lt;x&gt;
 ⍝.e ('/' ∆box 'please do not  / enter') = 15 adjust 'please do not
enter'
 ⍝.k formatting
 ⍝.n rml
 ⍝.t 1992.4.24.14.4.17
 ⍝.v 1.0 / 05jan82
 ⍝.v 2.0 / 05apr88 / change order of &lt;x&gt;, use subroutines
 ⍝.v 2.1 / 24apr92 / using signalerror
 ⍝ x[1] width of result in columns
 ⍝ x[2] width of left margin (i.e. number of blank columns)
 ⍝ x[3] number of blank lines to insert between each row
 ⎕IO←1

...and more of the function...

I suspect that if the first line is a lamp line, that can be taken as
the description, and a double-lamp taken as a single lamp. This lamp
line may be indented, and could then be the "help" for the function.
The "Toronto Toolkit" format then has lamp lines with ".x" (. followed
by letter) and data .e is example, .t is timestamp, .v is version, .k
for keywords, .n for name/initials and more. Then there are function in
the Toolkit that handle this data. But, again, the first lamp-line gives
the overview.

Just food for thought.
FredW


</pre>
</blockquote>
<br>
</body>
</html>
Loading...