[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [gawk-devel] MPFR thoughts
From: |
Neil R. Ormos |
Subject: |
RE: [gawk-devel] MPFR thoughts |
Date: |
Fri, 6 May 2022 11:14:34 -0500 (CDT) |
Carl Friedberg wrote:
> [... Manuel Collado wrote:]
>> [Eli Zaretskii wrote:]
>>> ...
>>> Gawk is a general-purpose language,
>>> and as such, it isn't outlandish
>>> for Gawk to provide extended-precision arithmetics.
>> Please let me respectfully disagree. IMHO gawk
>> is a kind of domain-specific language. Focused
>> of processing textual representation of data,
>> i.e. strings. Of course some numeric
>> computation capability is needed, but only to
>> some extension.
>> Not being the main purpose of gawk, this
>> capability can be provided as an extension, as
>> already said. No need to be integrated in the
>> gawk core.
> Thank you. I agree with the removal of MPFR
> support. I am not in any way an AWK/GAWK
> developer, nor do I have the skills needed.
I am not a member of the Gawk developers mailing list, but since thoughts about
removing MPFR from Gawk have been mentioned on this Bug-Gawk list, I offer this
user comment.
I appreciate the GNU MP and MPFR support in Gawk and urge that it not be
removed. I have found the MPFR feature quite useful, e.g., for experimentation
to explore the behavior of a calculation when spreadsheets didn't work.
Even if Gawk is seen by many as primarily a text processing language, Gawk has
proven to be amazingly versatile in my practice, providing a marvelous tradeoff
between functionality and simplicity.
There may be well be better languages for specific problem domains,
particularly for production systems, but Gawk is often quite adequate for
proof-of-concept and other prototyping, avoiding the large up-front cost of
acquiring fluency in some special-purpose language, along with its required
tool chain and infinity of libraries and modules. Removing the MPFR support
from Gawk would reduce its versatility.
Finally, it would be a shame to let the undiplomatic complaints of a single
user serve as the catalyst for the removal of important functionality from
Gawk. To the extent Gawk -M behavior is library-dependent and cannot feasibly
be reconciled with Gawk's non-dash-M behavior, instead of removing MPFR
support, it would seem sufficient to warn users that the behavior may vary and
that such variation will not, alone, be treated as a bug.
> We owe Arnold Andy, and all the others who have
> supported AWK over the generations a huge thank
> you
Indeed. Thank you Arnold, Andy, Eli, and all the others.
- RE: [gawk-devel] MPFR thoughts, Carl Friedberg, 2022/05/05
- RE: [gawk-devel] MPFR thoughts,
Neil R. Ormos <=
- Re: [gawk-devel] MPFR thoughts, arnold, 2022/05/07
- Re: [gawk-devel] MPFR thoughts, Eric Pruitt, 2022/05/07
- Re: [gawk-devel] MPFR thoughts, Eric Pruitt, 2022/05/07
- Re: [gawk-devel] MPFR thoughts, Andrew J. Schorr, 2022/05/07
- Re: [gawk-devel] MPFR thoughts, Eric Pruitt, 2022/05/07
- RE: [gawk-devel] MPFR thoughts, pjfarley3, 2022/05/08
- Extension packaging, arnold, 2022/05/08
- RE: Extension packaging, pjfarley3, 2022/05/10
- Re: Extension packaging, Manuel Collado, 2022/05/10
- Re: Extension packaging, Andrew J. Schorr, 2022/05/10