RE: interpreting a strongly typed regexp constant variable as literal regular expression?

[pjfarley3]

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
--