[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: interpreting a strongly typed regexp constant variable as literal re
From: |
pjfarley3 |
Subject: |
RE: interpreting a strongly typed regexp constant variable as literal regular expression? |
Date: |
Sun, 31 May 2020 17:12:00 -0400 |
ISTM that it is the requirement for the "case" part of the switch statement to
be a *constant* that drove at least part of the misunderstanding here.
I just reviewed the relevant sections of the gawk 5.0 documentation myself, and
in the section on "strongly typed" regular expressions in section 6.1.2.2 there
is a link to the switch statement section, but nowhere in the documentation of
the switch statement is there an example of the use of a strongly typed regular
expression as a "case" constant value. Perhaps there should be such an example
there.
Indeed, after reading the documentation for strongly typed regular expressions
the first time I was convinced that this format of switch should work:
awk '{ var = @/^a/
switch($0) {
case var : ### Note intended use of a "constant" regexp but it
is NOT constant because "var" is a variable, not a constant
print "Yes"
break
default :
print "NR: " NR
break
}
}' << END
g
a
c
@/var/
END
But this mis-interpretation of the rules was rendered clearer after re-reading
the statement that "case" labels must be *constants*.
Rather than the prior poster's suggestions for extended usage of strongly typed
regular expression variables, I would instead prefer to see a new switch-like
statement that permitted variables and expressions for each "case" such that
the combination generates a TRUE value. I offer two examples of the COBOL
EVALUATE statement, where both of these forms are perfectly usable and legal:
The COBOL EVALUATE statement is like a gawk switch but expressions are allowed
for "cases" ("case" = WHEN in COBOL syntax; note that COBOL WHEN with no
statements following is like a case with no break, but the presence of any
statements at all after a WHEN *implies* a "break"):
EVALUATE variable-name
WHEN 'A'
. . . other statements . . .
WHEN other-variable ( 4 : 1 ) <--- Equivalent to gawk
substr(other-variable, 3, 1)
. . . other statements . . .
WHEN 'C'
WHEN OTHER
. . . default-case statements . . .
END-EVALUATE
EVALUATE with boolean expressions instead of constants or value expressions:
EVALUATE TRUE
WHEN variable-name = 'A'
. . . other statements . . .
WHEN variable-name = other-variable ( 4 : 1 )
. . . other statements . . .
WHEN variable-name = 'C'
WHEN OTHER
. . . default-case statements . . .
END-EVALUATE
But of course such any such new gawk extension statement is a "horse of a
different color", requiring much other discussion of semantics and syntax.
Perhaps even just provision of an "elseif" extension to the "if/else" statement
syntax would suffice to permit a COBOL EVALUATE style of conditional structure
using expressions. I.E.:
If (condition-1)
{ then-body-1 }
elseif (condition-2)
{ then-body-2 }
else
{ else-body }
Peter
> -----Original Message-----
> From: bug-gawk <bug-gawk-bounces+pjfarley3=earthlink.net@gnu.org> On
> Behalf Of arnold@skeeve.com
> Sent: Sunday, May 31, 2020 3:28 AM
> To: sargonemail@gmail.com; bug-gawk@gnu.org
> Subject: Re: interpreting a strongly typed regexp constant variable as literal
> regular expression?
>
> Hi.
>
> I've been offline for a few days.
>
> As explained in c.l.a. and here, you've misunderstood how strongly typed
> regexp
> constants work. They do not indirect to pull in values of other variables.
> (I have
> to admit, I don't understand how you came to that conclusion from the gawk
> doc. I rechecked it this morning and it doesn't say anything like that.)
>
> Your suggestions are interesting, but involve way too much implementation
> complexity for the value gained. There are other features in gawk already
> that
> will let you do similar things:
>
> a = @/^a/
> b = "a"
> foo ~ SYMTAB[b]
>
> Also, as pointed out, the values in case labels must be constants, they can't
> be
> variables, so to do the kind of checks you're looking for you must use a
> sequence of if-else statements.
>
> Thanks,
>
> Arnold
--