Re: [Bug-apl] Miscellaneous minor fixes

[Alexey Dokuchaev]

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
>>
>
>