Re: [bug-gawk] GAWK feature suggestions

[address@hidden]

Hi,

Thanks all of you for your feedback and the insights into your reasoning.

The point about namespaces is very valid. This is a new feature so I haven't 
used it much yet or explored all of its possibilities.

Special thanks for the trick to include testing code and only run it if a 
variable is declared on the command line. I will definitely be using this from 
now on. 

I do think that returning an array from a function would be useful addition, if 
only for clarity, but I certainly get the point about how it could lead to type 
mismatch errors. And obviously, I'm not aware of the actual coding 
difficulties, or how this would tie in to existing code and memory management 
issues.

And the block comments would be nice to have, but as you say don't really add 
much. I was thinking more along the lines of something like ##b and ##e (for 
begin and end), but again I have no idea of the impact this would have on 
existing parser code. 

I see your point about feature bloat. One of the main features of awk is its 
simplicity, and if you listen to everybody's wishlist you could quickly end up 
with a monster instead.

Finally, to address the point about porting to Python, I've already done this 
with much smaller awk scripts, up to 100 lines or so, and I definitely miss 
some of awk's short cuts such as the automatic conversion that you mention, and 
the implicit loop through the input file, but I'm seeing this as much as a 
(pretty hefty) learning exercise as as a production work project.

Once again, thanks to all who've helped in maintaining this project over the 
years and in getting it to where it is now.

Kind regards,
Chris


-----Original Message-----
From: address@hidden [mailto:address@hidden] 
Sent: 28 August 2019 19:23
To: Newell, Christopher (IE Dundrum); address@hidden
Cc: address@hidden; address@hidden
Subject: Re: [bug-gawk] GAWK feature suggestions

-----------------------------  PHISHING ALERT  -----------------------------
This email has been sent from an account outside of the BAE Systems network.

Be aware that this could be a phishing attempt. For more guidance, search 
"phishing email" on Connect. If you think this is a phishing email report it 
using the "PhishMe" button on Outlook.
------------------------------------------------------------------------------------

OK, here we go, my 2 cents.  (I'm afraid that you're also running up
against my bias to avoid adding more and more features.)

> > - Possibility to return an array from a function. This has probably
> >   already been requested, it would avoid the need for a number of
> >   public arrays.
>
> It would be nice, but as David pointed out, you can pass in an array, delete
> it, and populate it with the results. So there's no need for public arrays.

Right. Returning arrays would be nice, but I feel like gawk has already
stretched the language enough.

It would also complicate the code and memory management if such a
function is called not in an assignment.  It also introduces typing
conflicts. Consider:

        function magic(         a) {
                a[1] = 1; a[2] = 2
                return a
        }
        BEGIN {
                x = 1   # x is now and forevermore a scalar
                x = magic()     # type mismatch
        }

In short, it would make things *very* hairy.

> > - Nested functions. Not particularly important, but useful to hide
> >   helper functions from public view
>
> Doesn't the namespace feature more or less address this issue? You could
> choose your own convention of starting such functions with an underscore.

I agree with this.

> > - Block comments. Probably already suggested.
>
> What would the syntax be? I guess C-style comments?  The parser is already
> pretty hairy, so I'm not sure how easy this would be to implement. I know that
> Arnold has put a lot of effort into preserving the comments in the profiler
> output, and I'm not sure how challenging this would be in that respect.  It
> also seems a bit weird to have such a big syntactic departure from the regular
> language.

I don't think that block comments add that much too the language, and
indeed  /* hi there */  is actually a regexp constant (even if a silly one).

> > - And most useful for me when testing function libraries: ignore all
> >   rules if a file is called via @include (or maybe a @ignore-rules
> >   directive, as there may be rare cases where you want to include rules
> >   in an @include file). This would allow to combine test code and
> >   functions in a single file.
>
> This seems reminiscent of Python's 'if __name__ == "__main__"' construct.
> I don't know how difficult it would be to add something comparable for gawk.

So this one is actually pretty easy to do without any need to change
gawk itself. (The suggested change would be extremely difficult anyway.)

Simply write your library file like this:

        @namespace "mylib"
        function f1() { ... }
        function f2() { ... }
        ....
        BEGIN {
                if (awk::test_my_lib) {
                        # test code here
                }
        }

Then to test it:

        gawk -v test_my_lib=1 -f mylib.awk

No changes to gawk needed.

Python is pretty cool. Moving code from awk to Python is a little
challenging, since Python won't do the automatic number <-> string
conversions for you.

Thank you for taking the time to make contact. I'm glad you like
gawk and are finding it useful.

Best wishes,

Arnold

BAE Systems will collect and process information about you that may be subject 
to data protection laws. For more information about how we use and disclose 
your personal information, how we protect your information, our legal basis to 
use your information, your rights and who you can contact, please refer to the 
relevant sections of our Privacy note at 
www.baesystems.com/en/cybersecurity/privacy 
<http://www.baesystems.com/en/cybersecurity/privacy>

Please consider the environment before printing this email. This message should 
be regarded as confidential. If you have received this email in error please 
notify the sender and destroy it immediately. Statements of intent shall only 
become binding when confirmed in hard copy by an authorised signatory. The 
contents of this email may relate to dealings with other companies under the 
control of BAE Systems PLC, details of which can be found at 
http://www.baesystems.com/Businesses/index.htm.