Re: [gawk-devel] MPFR thoughts

[Neil R. Ormos]

arnold@skeeve.com wrote:
> "Neil R. Ormos" wrote:
>> ["Andrew J. Schorr" wrote:]

>>> [MPFR extension library] allows us to simplify
>>> core gawk and the extension API.

>> Could the problem of simplicity be materially
>> improved by requiring users to select either:
>>   (a) the -M MPFR features; or 
>>   (b) access to extensions; 
>> in any one run of Gawk?

> No.  The complexity of MPFR comes from the fact
> that the gawk code base has on the order of 85
> special cases to handle MPFR versus non-MPFR.
> The feature reaches its tentacles into every
> part of the code.

> After over a decade, there are still bugs in it,
> and the issue is the cost in *my* time to
> maintain it.  I firmly believe that the amount
> of use the feature sees by legitimate users is
> essentially neglible, and thus the ROI for the
> feature isn't worthwhile.

> I have no way to prove this, of course, except
> by deprecating the feature and seeing what
> happens.  Nobody has volunteered to maintain the
> feature, so (unless that changes) I will proceed
> as planned.

Thank you for the opportunity to plead the case for continued MPFR support and 
for your thoughtful replies.

I respect your position, though I wish the conclusion were a different one.

I also appreciate your hard work, and that of your colleagues, in continuing to 
develop and maintain Gawk.

Gawk is right in the Goldilocks Zone of programming languages for human-driven 
computing.  Powerful and flexible, it can handle sophisticated tasks, yet it's 
easy to learn and concise enough for very useful one-liners.  Plus, there's the 
excellent manual, though, happily, the language is small enough and consistent 
enough that the working set can remain in-core without constant manual page 
faults.