From Newsgroup: comp.lang.awk

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
--- Synchronet 3.19c-Linux NewsLink 1.113

From Newsgroup: comp.lang.awk

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

--- Synchronet 3.19c-Linux NewsLink 1.113

From Newsgroup: comp.lang.awk

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.
--- Synchronet 3.19c-Linux NewsLink 1.113

From Newsgroup: comp.lang.awk

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
--- Synchronet 3.19c-Linux NewsLink 1.113

From Newsgroup: comp.lang.awk

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
--- Synchronet 3.19c-Linux NewsLink 1.113

From Newsgroup: comp.lang.awk

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.
--- Synchronet 3.19c-Linux NewsLink 1.113