Re: [PATCH] Feature: parameters declared in body

[david kerns]

What's with the @?? (we already chose awk over Pearl because Pearl reads
like a swear word @#$%&...)
Why not just make a new keyword "local" that limits a variable's scope to
the block {} it's in?

thus:
$ cat l.awk
function f(p1)
{
  local i, j = 7;
  for (i = 1; i < p1; i++) {
    j += p1;
  }
  return j;
}
BEGIN   {
        for (local i = 3; i < 4; i++) {
          q += f(i);
        }
        print q;
}
        { local i = $1; }
        { print "i = ", i }
$ echo 42 | awk -f l1.awk
13
i =

(which I faked with)
$ cat l1.awk
function f(p1,     i,j)
{
  j = 7;
  for (i = 1; i < p1; i++) {
    j += p1;
  }
  return j;
}
BEGIN   {
        for (i = 3; i < 4; i++) {
          q += f(i);
        }
        print q;
}
        { i = $1; }
        { print "i = ", j }

 which, frankly, doesn't read that bad, with the exception of the last line



On Fri, Apr 8, 2022 at 4:38 AM Ed Morton <mortoneccc@comcast.net> wrote:

> On 4/8/2022 3:00 AM, arnold@skeeve.com wrote:
> > Thanks for this submission.  I will think about it for a bit.
> >
> > Arnold
> >
> > Kaz Kylheku<kaz@kylheku.com>  wrote:
> >
> >> Hi,
> >>
> >> I'm posting this as a proposal. If this is accepted, in some
> >> shape, then of course there will be test cases and
> >> documentation.
> >>
> >> The idea is that there is a new kind of attribute syntax
> >> whereby, inside a function, if we put the @param: prefix
> >> before a variable, that variable is added as a parameter
> >> to the surrounding function, which has the effect of making
> >> it a local variable.
> >>
> >> This effectively extends the Awk language with a nice way
> >> of defining locals, that is easy to use from code generators
> >> and macro preprocessors, and is based in the existing model
> >> of Awk local variables being parameters.
> >>
> >> A bit of a cautionary word: this relies on knowing the order
> >> in which things are parsed.  If a language construct mentions
> >> a certain variable several times, and one of those mentions
> >> has a @parm: prefix, that mention had better be processed by
> >> the parser before the others, otherwise those others will be
> >> compiled in a scope in which the variable was not defined
> >> as a parameter yet.
> >>
> >> For instance if we write:
> >>
> >>     for (@param:i = 0; i < 10; i++)
> >>
> >> we are relying on the parser processing @param:i
> >> before i < 10 or i+i. We can infer that from knowing
> >> the phrase structure rule, and how it is processed by the
> >> LALR(1) algorithm.
> >>
> >>
> >> Cheers ...
> >>
> >> P.S. Small demo showing how the variables are local:
> >>
> >> $ ./gawk -d '
> >> function add(n, m) {
> >>     for (@param:i = n; i <= m; i++)
> >>        @param:sum += i;
> >>     return sum
> >> }
> >>
> >> BEGIN { print add(2, 5); }'
> >> 14
> >> $ grep '^[a-z]' awkvars.out
> >> $
> >>
> >> Now remove @param:
> >>
> >> $ ./gawk -d '
> >> function add(n, m) {
> >>     for (i = n; i <= m; i++)
> >>       sum += i;
> >>     return sum
> >> }
> >>
> >> BEGIN { print add(2, 5); }'
> >> 14
> >> $ grep '^[a-z]' awkvars.out
> >> i: 6
> >> sum: 14
> >>
> >>
> >> Argument passing works with the @param variables:
> >>
> >> $ ./gawk -d '
> >> function add() {
> >>     return @param:a + @param:b
> >> }
> >>
> >> BEGIN { print add(2, 5); }
> >> '
> >> 7
> >>
> >> I almost feel this just wants to be @:a + @:b.
> >>
> >>
> >>
>
> If there's going to be a construct to declare local variables as in:
>
>     function add(n, m) {
>         for (@param:i = n; i <= m; i++)
>            @param:sum += i;
>         return sum
>     }
>
> then obviously it should be named "@local" instead of "@param" but IMHO
> it's not worth adding an extra keyword just for that given the mantra
> you've mentioned before that awk avoids language bloat by only having
> constructs to do things that are hard to do with other constructs.
>
> Also, please don't introduce a construct that lets you declare a
> variable as a parameter without it appearing in the function declaration
> as in:
>
>     function add() {
>         return @param:a + @param:b
>     }
>
> as that makes the code noticeably harder to read - I want to see the
> function parameters and the order they have to be provided where the
> function is declared, not have to look through the body of the function
> for "@param" statements and have to think about the order those
> statements will be parsed to figure out what arguments the function
> requires in what order.
>
>      Ed.
>