Re: Comments on GNU APL

[Dr . Jürgen Sauermann]

Hi Brian,

thank you very much for your comments. Please see some
remarks from my side inline below.

On 1/9/20 8:53 PM, Mr. Brian B. McGuinness wrote:

1. On startup of GNU APL 1.8 I get the error message:

   The following directories and file names were tried:

       directory /usr/local/lib/apl

       directory /usr/lib/apl

       file ./libemacs.so                       (No such file or directory)

       file ./libemacs.dylib                    (No such file or directory)

       file ./libemacs                          (No such file or directory)

       directory ./native

       directory ./emacs_mode

   The file is /usr/lib64/apl/libemacs.so (the installer apparently placed it there).

Interesting. This seems to be related to platform on which
GNU APL runs. At the time when this was implemented 64-bit
GNU/Linux was not as common as it is today (and even on my
current 64-bit system this does not happen. Apparently you
somehow start GNU APL in a way that ⎕FXes the libemacs
native function automatically (I am a notorious vi user, thats probably
why I missed it).

I will look into this, please let me know:

1. what is your platform, and
2. how (command line arguments, )COUTINUE workspace) do you
start GNU APL when this error occurs?

2. )DUMP should always store floating point values whose magnitudes are less

   than 1 in scientific notation to preserve precision.

   For example, if I do

         )wsid test

   WAS CLEAR WS

         sec2rad ← 4.8481368110953599359e¯6

         )dump

   and then I look at the test.apl file, I see

   sec2rad←0.00000484813681109536

   so I have lost five digits.

   I am tempted to use )DUMP instead of )SAVE as it stores workspaces in a more

   compact and easily readable form that does not become obsolete as new

   versions of GNU APL are released.

Actually )SAVE and )DUMP use the same function for serializing floating
point values. As Kacper and Jay pointed out, the precision is lost in the
assignment

sec2rad ← 4.8481368110953599359e¯6

You can provide as many significant digits as you like, but the precision
will always be limited by the internal representation of floating point numbers.
This representation is platform specific and will, in most cases, be the precision
of IEEE 754 doubles with 64-bits (the precision is then around 51 bits or 16
decimal digits).

3. I am strongly opposed to the use of the axis parameter for passing arbitrary

   data to a function as a third argument.  This is very confusing to people

   trying to read the code.  When I see brackets, I expect the contents to be

   either a genuine axis specification or an index into an array.  A better

   approach would be to pass arguments in a nested array and then unpack them

   with a statement such as  (A B C) ← ARGUMENTS.  

As far as defined functions are concerned, I see no reason why
there should be arbitrary restrictions on the arguments of defined
functions. And a genuine axis specification can already today be
more than a simple integer scalar, for example X in ⊃[X] B or
'123'[''] , the latter already valid long before APL2.

   Alternatively, APL2 could    be extended to allow the use of data as

   operands for operators, as in J.  Then the operator operands could be used

   as third and fourth arguments.  That would allow #FIO and other such

   functions to be implemented in much the same way as the foreign conjunction

   in J.

Initially ⎕FIO did allow only integer scalars as function numbers. This
was, due to the large number of functions that ⎕FIO provides, rather
cumbersome to read and the fix for this was the FILE_IO.apl workspace
which wrapped every ⎕FIO function into a corresponding  FIO∆ function.
So, to e.g. fopen() a file for reading we have 3 alternatives:

H←⎕FIO[3] filename

)COPY FIO.apl
H←FIO∆fopen filename

H←⎕FIO['fopen'] filename

My personal taste is that ⎕FIO[3] is entirely unreadable and FIO∆fopen
is readable but the need to )COPY FIO.aplis somewhat annoying. I would
argue that the third option, ⎕FIO['fopen'], is the most readable and
elegant one.

4. ]boxing is very helpful.  

The honor is Dyalog's who apparently came up with this and Elias'
(if I remember correctly) to propose it for GNU APL.

5. I would like to see #RE extended to support replacement operations with

   back-substitution as well as searches.  For example, one might enter

   TEXT ← ('"(\w)' '“$1') #RE['g'] TEXT

I am already lost when it comes to understand what the above means.
My guts feeling is that importing an absolutely ugly syntax like regular
expressions into a beautiful language like APL might make the
inventor of APL rotate in his grave. I already felt guilty when turning the
native function for regular expressions the system function ⎕RE. This
was already a compromise and I would prefer not to drive it any further.

   to replace double quotes preceding words with "“".

   But I would prefer a syntax like

   TEXT ← '/"(\w)/“$1/g' #RE TEXT

   to avoid abusing the axis selector.

Thanks.

Thank You!

--- Brian