On Sun, 1 Dec 2024 10:07:45 -0500
Maury Markowitz <maury.markow...@gmail.com> wrote:
> DATA 10,20,HELLO,WORLD!
>
> I am looking for ways to attack this.
To add to what Hans said, you want to extend what the scanner accepts
in a DATA statement. In your case, DATA has a slightly more expansive
view of what an expression is.
I'm just a bit skeptical. If the rule is that
> DATA 10,20,"HELLO,WORLD!"
and
> DATA 10,20,HELLO,WORLD!
are the same 3 expressions (2 numbers and 1 string), how is the user
supposed to supply 2 numbers and 2 strings? Or is it the case that the
quoted equivalent would be
> DATA 10,20,"HELLO","WORLD!"
?
In any event, I assume the latter. In you Flex file, before the first
% %, add
%s data
In your rules, when you see a DATA line, bring that start condition
into play:
DATA { yy_push_state(data); }
then define the start condition and its rules:
<data>{
[[:alpha:]]/[^,\r\n] { /* ... */ return STRING; }
[\r]?[\n] { yy_pop_state(); }
}
Because the start condition is %s, it's addititive; the rest of scanner
continues to work unchanged. Because you don't know how many strings
there will be, you don't want to cancel the start condition until EOL.
I'm not sure, but I think an "inclusive" start condition obeys the usual
"first fit" rule: if two rules both match the same "longest" input, the
first one wins. if you have two rules for "\n", you want this one to
appear first because, that way, a newline during the <data> start
condition cancels it.
HTH.
--jkl
