3 ms·

Did they cite a reason that sounded reasonable? Like the particular implementation breaks some design principle they want to stick to or something? Did they sug

Did they cite a reason that sounded reasonable? Like the particular implementation breaks some design principle they want to stick to or something? Did they suggest it might be acceptable some other way or in some other form? It's curious because gawk cannot for one second claim something like needing to stick to some legacy standard, not with a straight face.

Joeri 3y ago
If I were the gawk maintainer I would be unwilling to take on features by default. It is widely used infrastructure and keeping out bugs is far more important than taking on features. If the userbase keeps asking for the same feature over and over, at that point it would be up for consideration, but no sooner.
- vidarh 3y ago
  I think the point is that the list of features added in gawk vs. POSIX awk is miles long... They've not exactly shown restraint. That said, proving it's value in a fork first seems reasonable.
im3w1l 3y ago
Programming languages try very hard to be backward compatible so every feature you add is an eternal commitment.
kazinator 3y ago
The thread is here: https://lists.gnu.org/archive/html/bug-gawk/2022-04/msg00025.html https://lists.gnu.org/archive/html/bug-gawk/2022-04/msg00025... There is more around it. I had the idea in two other forms. Initially I had a @param:<ident> syntax which indicated that the given variable is to be allocated in the parameter space (a local variable frame where function parameters go). This only worked inside functions. Between that and @let was a @local thing. The maintainer of GNU Awk is one of the two authors of the "Fork y Code Please", the other being the Bash guy: https://www.skeeve.com/fork-my-code.html https://www.skeeve.com/fork-my-code.html So ...
- nextaccountic 3y ago
  > We are glad to receive input from our user community about: > Suggestions for new features that: > Cannot be accomplished using existing features in a straightforward way > Don't (too badly) break compatibility for existing code So.. in theory your @let should qualify
  - kazinator 3y ago
    I may end up renaming it let and hiding it in --posix mode. GNU Awk has switch, which is an extension and not hidden by @.

Joeri 3y ago

If I were the gawk maintainer I would be unwilling to take on features by default. It is widely used infrastructure and keeping out bugs is far more important than taking on features. If the userbase keeps asking for the same feature over and over, at that point it would be up for consideration, but no sooner.

vidarh 3y ago
I think the point is that the list of features added in gawk vs. POSIX awk is miles long... They've not exactly shown restraint. That said, proving it's value in a fork first seems reasonable.

im3w1l 3y ago

Programming languages try very hard to be backward compatible so every feature you add is an eternal commitment.

kazinator 3y ago

The thread is here: https://lists.gnu.org/archive/html/bug-gawk/2022-04/msg00025.html https://lists.gnu.org/archive/html/bug-gawk/2022-04/msg00025... There is more around it. I had the idea in two other forms. Initially I had a @param:<ident> syntax which indicated that the given variable is to be allocated in the parameter space (a local variable frame where function parameters go). This only worked inside functions. Between that and @let was a @local thing. The maintainer of GNU Awk is one of the two authors of the "Fork y Code Please", the other being the Bash guy: https://www.skeeve.com/fork-my-code.html https://www.skeeve.com/fork-my-code.html So ...

nextaccountic 3y ago
> We are glad to receive input from our user community about: > Suggestions for new features that: > Cannot be accomplished using existing features in a straightforward way > Don't (too badly) break compatibility for existing code So.. in theory your @let should qualify
- kazinator 3y ago
  I may end up renaming it let and hiding it in --posix mode. GNU Awk has switch, which is an extension and not hidden by @.