I have started a repository called Enhanced GNU Awk.

https://www.kylheku.com/cgit/egawk/about/

This adds true local variables to Gawk, in the form of a @let
construct. @let is block scoped, not function scoped, and
may be used outside of functions, e.g.

BEGIN {
@let (here_only = 42) {
print here_only
}
}

I need this for the cppawk project, which has macros. macros sometimes
need hidden temporary variables. It's very bad if these are global.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On 13.04.2022 03:50, Kaz Kylheku wrote:
> I have started a repository called Enhanced GNU Awk.
>
> https://www.kylheku.com/cgit/egawk/about/
>
> This adds true local variables to Gawk, in the form of a @let
> construct. @let is block scoped, not function scoped, and
> may be used outside of functions, e.g.
>
> BEGIN {
> @let (here_only = 42) {
> print here_only
> }
> }
>
> I need this for the cppawk project, which has macros. macros sometimes
> need hidden temporary variables. It's very bad if these are global.

Understood.

Are GNU Awk Namespaces[*] not sufficient to address the problem?

Janis

[*] https://www.gnu.org/software/gawk/manual/gawk.html#Namespaces

On 4/12/2022 8:50 PM, Kaz Kylheku wrote:
> I have started a repository called Enhanced GNU Awk.
>
> https://www.kylheku.com/cgit/egawk/about/
>
> This adds true local variables to Gawk, in the form of a @let
> construct. @let is block scoped, not function scoped, and
> may be used outside of functions, e.g.
>
> BEGIN {
> @let (here_only = 42) {
> print here_only
> }
> }
>
> I need this for the cppawk project, which has macros. macros sometimes
> need hidden temporary variables. It's very bad if these are global.
>

Much like the now ancient "New awk", nawk, "Enhanced awk" isn't a great
name as it could be used for any project that adds functionality and
doesn't tell you anything about the tool. I have my own Extended Print
awk (epawk) tool that allows "here" documents in an awk script (see
https://stackoverflow.com/a/24597515/1745001) that I could have named
"Enhanced awk" instead of "Extended print awk" but that's not
descriptive of the functionality it provides.

Maybe you could follow in the footsteps of Mike's Awk, mawk, and
Thompson's awk, tawk, and name this Kaz/Kyheku's awk, kawk? Or maybe
"Let awk", lawk, or "Local Variables awk", lvawk, to really capture what
this awk is for unless you plan to add more functionality later?

Ed.

On 2022-04-13, Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
> On 13.04.2022 03:50, Kaz Kylheku wrote:
>> I have started a repository called Enhanced GNU Awk.
>>
>> https://www.kylheku.com/cgit/egawk/about/
>>
>> This adds true local variables to Gawk, in the form of a @let
>> construct. @let is block scoped, not function scoped, and
>> may be used outside of functions, e.g.
>>
>> BEGIN {
>> @let (here_only = 42) {
>> print here_only
>> }
>> }
>>
>> I need this for the cppawk project, which has macros. macros sometimes
>> need hidden temporary variables. It's very bad if these are global.
>
> Understood.
>
> Are GNU Awk Namespaces[*] not sufficient to address the problem?

For the above specific example situation (module variables), yes.
For macros, no.

I'm already using a portable namespacing mechanism which is to prepend two
underscores on all private symbols, including macro-generated temporaries.

GNU Awk prohibits namespaced identifiers from being used as function
parameters, so all namespaced variables are necessarily global.
(I preserved this restriction in @let: it won't allow names like
foo::bar).

At first I implemented a @local mechanism which had function-wide scope
for variables. That was less work, but it doesn't solve the problem in
situations when constructs nest and happen to choose the same variable.

In the C preprocessor, the options are very limited for generating
temporary names. You're looking at something like

#define __temp(pfx) __ ## pfx ## __LINE__

The __LINE__ is derived from the top-level macro invocation. So
if you have a bunch of nested syntax in that macro call which contains
__temp(x), all the __temp(x) will generate to the same thing: __x42 if the
macro is called on line 42.

With true lexical scope, this becomes a non-issue. E.g.
if we generate, say, some nested loops like this, we have a problem:

for (__x42 = 0; __x42 < ...;__x42++)
for (__x42 = 0; __x42 < ...; __x42++)

but it goes away if we add @let:

@let (__x42) for (__x42 = 0; __x42 < ...; __x42++)
@let (__x42) for (__x42 = 0; __x42 < ...; __x42++)

The reuse of __x42 and _n42 isn't a problem now (with certain
additional care).

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On 2022-04-13, Ed Morton <mortonspam@gmail.com> wrote:
> On 4/12/2022 8:50 PM, Kaz Kylheku wrote:
>> I have started a repository called Enhanced GNU Awk.
>>
>> https://www.kylheku.com/cgit/egawk/about/
>>
>> This adds true local variables to Gawk, in the form of a @let
>> construct. @let is block scoped, not function scoped, and
>> may be used outside of functions, e.g.
>>
>> BEGIN {
>> @let (here_only = 42) {
>> print here_only
>> }
>> }
>>
>> I need this for the cppawk project, which has macros. macros sometimes
>> need hidden temporary variables. It's very bad if these are global.
>>
>
> Much like the now ancient "New awk", nawk, "Enhanced awk" isn't a great
> name as it could be used for any project that adds functionality and

Right, which is why the name is "Enhanced GNU Awk" (egawk), not
"Enhanced Awk", which would be a terrible name.

I believe that the space of things that are "fork of GNU Awk"
is tiny; this might be the only one.

If someone else makes a fork of GNU Awk and also wants to call it
egawk, we can work it out. Possibly by merging projects into one.

(Forks are not so good, by the way; I'd *much* rather have this upstreamed,
but the project isn't interested.)

> Maybe you could follow in the footsteps of Mike's Awk, mawk, and
> Thompson's awk, tawk, and name this Kaz/Kyheku's awk, kawk? Or maybe

In today's prudish social justice environment teeming with snowflakes
who are perpetually on the verge of tears, "kawk" would likely
be regarded in many projects as a "CoC" violation.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On Wednesday, April 13, 2022 at 4:33:21 PM UTC-5, Kaz Kylheku wrote:
> On 2022-04-13, Ed Morton <morto...@gmail.com> wrote:
<snip>
> > Maybe you could follow in the footsteps of Mike's Awk, mawk, and
> > Thompson's awk, tawk, and name this Kaz/Kyheku's awk, kawk? Or maybe
> In today's prudish social justice environment teeming with snowflakes
> who are perpetually on the verge of tears, "kawk" would likely
> be regarded in many projects as a "CoC" violation.

Ah, good point, then you should name it Forked Awk - fawk :-).

Ed.