Re: [bug-gawk] GAWK feature suggestions

[arnold]

Hi.

Thanks for the note, and you're welcome, glad to help.  I'm happy my
tip will work for you.

Take care,

Arnold

"address@hidden" <address@hidden> wrote:

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