Re: flex reg exp help

Russ Ramsey <rr61335@goodnet.com>
3 Jun 2000 17:32:58 -0400

          From comp.compilers

Related articles
flex reg exp help rr61335@goodnet.com (Russ Ramsey) (2000-06-01)
Re: flex reg exp help rr61335@goodnet.com (Russ Ramsey) (2000-06-03)
| List of all articles for this month |

From: Russ Ramsey <rr61335@goodnet.com>
Newsgroups: comp.compilers
Date: 3 Jun 2000 17:32:58 -0400
Organization: WinStar GoodNet, Inc.
References: 00-06-006
Keywords: lex, comment

>[Your question would be easier to answer if you explained what the
>syntax for these comments is supposed to be, and how you can tell a
>star that starts a comment from a multiplication operator. -John]


The syntax for SAS version 6.12 comments are:
*any text;
            or
/* any text */


The second type of comment follows all the same rules as C style comments,
so I have the proper flex code for them. The first style requires that
only white space can precede the asterisk and the comment text can span
several lines.


SAS syntax rules are defined to allow any arithmetic operator to be the
first token on a line, EXCEPT for the multi. and exp. operators (* and
**). They must be preceded by a paren or variable name or some other token
first.


So my question is how do I tell lex to only match * to the multi when it is
not the first token on a line?


Also, why is bison so picky with the "type clash (' ' 'string') on default
action" errors?
AT&T Yacc on AIX and Solaris doesn't care on the same code if you mix the
token value types. (Like Example 4-4 on p87 of O'Reilly book.)


Thanks,
          Russ
[For the first question, I'd take advantage of lex's longest match rule
like this:


%x SCMNT
%%
^[ \t]*"*" { BEGIN SCMNT; } /* start a comment */
<SCMNT>";" { BEGIN INITIAL; } /* end a comment */
<SCMNT>.|\n { /* inside a comment */ }
  ... blah blah ...


"**" { return EXPOP; } /* only matches if rule above didn't */
"*" { return MULOP; } /* only if neither rule above matched */


For the second question, any yacc rule without an action gets an
implicit action of { $$ = $1; }, but AT&T yacc has a bug in that it
doesn't do the type checks on the implicit action that it does on
explicit ones. Bison is doing the right thing here, so declare your
types correctly or explicitly throw away values you're not using with
empty actions. -John]





Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.