[Top][All Lists]

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

Re: Comments on GNU APL

From: Dr . Jürgen Sauermann
Subject: Re: Comments on GNU APL
Date: Fri, 10 Jan 2020 14:17:28 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

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
         sec2rad ← 4.8481368110953599359e¯6

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


   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

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

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.

Thank You!

--- Brian

reply via email to

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