Re: [Bug-apl] Miscellaneous minor fixes

[Dr . Jürgen Sauermann]

Hi Alexey,

the "(almost) complete" is a left-over from from the first GNU APL release note (around 2013
if I remember correctly). At that time GNU APL was covering most features of IBM APL2, but
the ISO standard contained additional functions and features that were not available in APL2
(operator commute and operator rank if I remember correctly). Most of them have been added
in the meantime, though.

Another feature mentioned in the ISO standard is "Component  Files". They are not
contained in GNU APL, but have been submitted by the GNU APL users David B. Lamkins
and Blake Mc Bride (see web links in http://www.gnu.org/software/apl/Community.html) in
the form of GNU APL workspaces.

I have not created a development or release plan for GNU APL. As far as I am concerned,
everything that I believe should be implemented is contained in 1.8 (that's why 1.8 was so late;
I wanted it to contain what was missing from my personal wishlist). But I am open to good
proposals in the future. So my role will be bug fixing and keeping up with the rate at which
the gcc guys come up with new warnings.
 
Best Regards,
Jürgen Sauermann

On 7/5/19 4:20 PM, Alexey Dokuchaev wrote:

Thank you Jürgen!  Looks good at a quick glance, I'll test those
changes once I have long enough free time slot. :-)

On a somewhat related note, do you have a road map for new features
and/or releases?

Description says current implementation supports (almost) complete ISO
13751, what exactly is missing?

Overall, I quite like GNU APL as a calculator REPL and would probably
try to replace Python which I'm usually using for this purpose.

./danfe

On 7/5/19, Dr. Jürgen Sauermann <mail@jürgen-sauermann.de> wrote:

Hi Alexey,

I applied most of your patches, thanks for submitting them.

I have left the preferences file as is because changing it could come as a
surprise
to users that are happily using the current default.

I also changed the rlim_t comparison warnings in a different way. Please
complain
if that doesn't work.

SVN 1179.

BR,
Jürgen


On 7/4/19 5:52 PM, Alexey Dokuchaev wrote:

On 7/4/19, Dr. Jürgen Sauermann <mail@jürgen-sauermann.de> wrote:

Regarding signed vs. unsigned, the question is not so much if the chosen
type can hold the value but the number of comparisons needed to compute
if a value fits into a range (where the vast majority of cases the range
starts at 0).

A signed X falls into range [0, N] iff:   X ≥ 0 and X < N
An unsigned X falls into range [0, N] iff:   X < N

Understood.  It should not be too hard to fix, just make sure that
your desired types do not conflict with system types like rlim_t, then
either use a compatible type or employ a typecast as a last resort
(typecasts are evil and should be avoided).

This fired back badly (with milllions of warnings) when I replaced
Simple_string<X> with std::string<X> which uses unsigned for the length.

Been these, done that. :-)  Usually, the safest approach when handling
sizes is to use size_t type (which is unsigned, just as you prefer)
and only reluctantly fallback to ssize_t if you need/must to handle
negative sizes for some reason in the same variable (e.g. for error
handling).  Reluctantly because it is generally a bad idea to convey
errors by abusing the data type itself.  Unfortunately, in many
traditional languages there is no support for algebraic data types to
handle these situations in a correct, type-safe way.

./danfe