CODEWITHSUNDEEP
parsingbisonflex-lexer
Alex Hoffmann
Alex Hoffmann

Reputation: 367

Flex scanning, differentiating between string (with single spaces) and padding (more than one space)

I am having trouble with flex to scan lines that looks something like this

DESCRIPTION                    This is the device description

I would like the line to be scanned such that DESCRIPTION is one token and "This is the device description" is the other.

I have been playing endlessly with my rules but cannot seem to get it to work.

From the documentation I think I want to implement a rule using

`r/s' an r but only if it is followed by an s

where spaces are only accepted is they are followed by something that is not a while space. I have no idea how to write this rule with flex's syntax. In my mind the rule should be something like

[a-zA-Z](" "/[a-zA-Z0-9]|[a-zA-Z0-9])*        return IDENTIFIER;

But this is invalid.

I can get the lines to chop up each word but I cannot get the rules to differentiate between 1 space and 1 < spaces. Halp.

Upvotes: 1

Views: 1042

Answers (2)

Serge Ballesta
Serge Ballesta

Reputation: 149185

My opinion is that you are using the wrong horse here. lex (flex) should be only used for lexical analysis and yacc (or bison) for syntactic one. Saying that one single character is not a separator but multiple are is not appropriate for a lexer.

My opinion is that lex should only reports words and padding and that yacc should later re-combine words that are not separated by padding elements.

The lex part would be as simple as:

[[:alnum:]_]+   {
        // printf("WORD: >%s<\n", yytext); // for debugging
        return WORD;
    }

[[:blank:]]{2,} {
        // printf("PADDING: >%s<\n", yytext);
        return PADDING;
    }

and the yacc part would contain:

elt: PADDING
   | ident

ident: WORD
     | ident WORD

action are omitted here because they depend too much on your actual processing.

Upvotes: 0

rici
rici

Reputation: 241941

This is not really a good match for flex, since the recognition of tokens is context-dependent. You can achieve context-dependent scanning using start conditions but excessive use of start conditions is often an indication that some other scanning mechanism would be better.

Regardless of how you do it, the key is figuring out exactly how to decide on the token division. Consider the following four lines, for example:

DEVICE      This is the device
MODE        This is the mode
DESCRIPTION This is the device description
UNDOCUMENTED FIELD

Of course, it is possible that the corner cases represented by the third and fourth lines never show up in any of your inputs.

If the first token cannot include whitespace, then the problem is relatively simple, although you still need a start condition (and I'm going to assume you read the documentation linked above):

%x WHITE WORDS
%%
  /* Possibly should be [[:alpha:]] instead of [[:upper:]] */
[[:upper:]]+   { /* copy yytext */; BEGIN(WHITE); return KEYWORD; }
  /* Handle other possible line beginnings */
<WHITE>\n      { /* Blank descriptive text */; BEGIN(INITIAL); }
<WHITE>[ \t]+  { BEGIN(WORDS); }
<WHITE>.       { /* Something not correct in this line */; ... }
<WORDS>.+      { /* copy yytext */; BEGIN(INITIAL); return DESCRIPTION; }
<WORDS>\n      { BEGIN(INITIAL); }

If there might be whitespace in the first token but never two spaces in a row, you could replace the first pattern above with:

[[:alpha:]]+( [[:alpha:]]+)*

which will match any sequence of words (consisting only of letters) where there is exactly one space between successive words. Like the original pattern above, this will end on the first non-alphabetic character found. That error will be detected by the rules in <WHITE>, because any non-whitespace character encountered when that start condition becomes active will be handled by the start condition's default rule (the <WHITE>. rule).

Upvotes: 1

Related Questions