bug-gawk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gawk] GAWK feature suggestions


From: arnold
Subject: Re: [bug-gawk] GAWK feature suggestions
Date: Wed, 28 Aug 2019 12:23:01 -0600
User-agent: Heirloom mailx 12.5 7/5/10

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]