|From:||Dr . Jürgen Sauermann|
|Subject:||Re: [Bug-apl] Miscellaneous minor fixes|
|Date:||Fri, 5 Jul 2019 17:13:17 +0200|
|User-agent:||Mozilla/5.0 (X11; Linux i686; rv:60.0) Gecko/20100101 Thunderbird/60.6.1|
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.
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 < NUnderstood. 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
|[Prev in Thread]||Current Thread||[Next in Thread]|