parser.y:79.33-41: symbol character is used, but is not defined as a token and has no rules











up vote
0
down vote

favorite












Having an issue with my parser and I just can't wrap my head around it. I keep getting the error: parser.y:79.33-41: symbol character is used, but is not defined as a token and has no rules. I've put the line in ** **.



Below is my parser code:



%token          PLUS TIMES DIVIDE SUBTRACT BRA KET EQUALS NOT_EQUAL LESS_THAN GREATER_THAN GREATER_THAN_OR_EQUAL
%token COMA SEMICOLON ARROW DECIMAL ENDDO ENDFOR ENDIF ENDP ENDWHILE ELSE CODE OF TYPE DECLARATIONS CHARACTER
%token INTEGER REAL IF THEN DO WHILE FOR IS BY TO WRITE NEWLINE READ NOT AND OR ID LESS_THAN_OR_EQUAL APOSTROPHE

%%
Program : block
| ENDP
| ID
;
block : DECLARATIONS declaration_block CODE statement_list
| CODE statement_list
;
declaration_block : ID OF TYPE SEMICOLON
| ID_list OF TYPE SEMICOLON
| ID_list OF TYPE SEMICOLON declaration_block
;
ID_list : ID
| ID COMA ID_list
;
type : CHARACTER
| INTEGER
| REAL
;
statement_list : statement
| statement_list SEMICOLON statement
;
statement : assignment_statement
| if_statement
| do_statement
| while_statement
| for_statement
| write_statement
| read_statement
;
assignment_statement : expression ARROW ID
;
if_statement : IF conditional THEN statement_list ELSE statement_list ENDIF
;
do_statement : DO statement_list WHILE conditional ENDDO
;
while_statement : WHILE conditional DO statement_list ENDWHILE
;
for_statement : FOR ID IS expression BY expression TO expression DO statement_list ENDFOR
;
write_statement : WRITE BRA output_list KET write_statement NEWLINE
;
read_statement : READ BRA ID KET
;
output_list : value
| output_list COMA value
;
conditional : expression comparator expression
| NOT conditional
| expression comparator expression AND conditional
| expression comparator expression OR conditional
;
comparator : EQUALS
| NOT_EQUAL
| LESS_THAN
| GREATER_THAN
| LESS_THAN_OR_EQUAL
| GREATER_THAN_OR_EQUAL
;
expression : term
| expression PLUS term
| expression SUBTRACT term
;
term : value
| term TIMES value
| term DIVIDE value
;
value : ID
| constant
| BRA expression KET
;
constant : number_constant
| character_constant
;
**character_constant : APOSTROPHE character APOSTROPHE**
;
number_constant : INTEGER
| SUBTRACT INTEGER
| SUBTRACT INTEGER DECIMAL INTEGER
| INTEGER DECIMAL INTEGER
;
%%


Below is my lexical analyser:



%{
#ifdef PRINT
#define TOKEN(i) printf("Token: " #i "n");
#else
#define TOKEN(i) return (i);
#endif
%}

delim [ rnt]
ws {delim}+
digit [0-9]
character [a-zA-Z]
INTEGER {digit}+
id {character}({character}|{digit})*
character_constant ('{character}')


%%
{ws} ; /* Do Nothing */

"+" TOKEN(PLUS)
"*" TOKEN(TIMES)
"/" TOKEN(DIVIDE)
"-" TOKEN(SUBTRACT)
"(" TOKEN(BRA)
")" TOKEN(KET)
...
"'" TOKEN(APOSTROPHE)
ENDP TOKEN(ENDP)
CODE TOKEN(CODE)
OF TOKEN(OF)
TYPE TOKEN(TYPE)
DECLARATIONS TOKEN(DECLARATIONS)
character TOKEN(CHARACTER)
{INTEGER} TOKEN(INTEGER)
...
{id} TOKEN(ID)
{character_constant} TOKEN(character_constant)
%%


The spelling is correct throughout my files from my BNF to my parser, does anyone know what seems to be the issue here. I've tried changing it to letter instead of character but that just gives me another error.










share|improve this question
























  • You know you can just come and ask me about my assessed coursework. I'm just here....
    – Brian Tompsett - 汤莱恩
    Nov 7 at 12:21















up vote
0
down vote

favorite












Having an issue with my parser and I just can't wrap my head around it. I keep getting the error: parser.y:79.33-41: symbol character is used, but is not defined as a token and has no rules. I've put the line in ** **.



Below is my parser code:



%token          PLUS TIMES DIVIDE SUBTRACT BRA KET EQUALS NOT_EQUAL LESS_THAN GREATER_THAN GREATER_THAN_OR_EQUAL
%token COMA SEMICOLON ARROW DECIMAL ENDDO ENDFOR ENDIF ENDP ENDWHILE ELSE CODE OF TYPE DECLARATIONS CHARACTER
%token INTEGER REAL IF THEN DO WHILE FOR IS BY TO WRITE NEWLINE READ NOT AND OR ID LESS_THAN_OR_EQUAL APOSTROPHE

%%
Program : block
| ENDP
| ID
;
block : DECLARATIONS declaration_block CODE statement_list
| CODE statement_list
;
declaration_block : ID OF TYPE SEMICOLON
| ID_list OF TYPE SEMICOLON
| ID_list OF TYPE SEMICOLON declaration_block
;
ID_list : ID
| ID COMA ID_list
;
type : CHARACTER
| INTEGER
| REAL
;
statement_list : statement
| statement_list SEMICOLON statement
;
statement : assignment_statement
| if_statement
| do_statement
| while_statement
| for_statement
| write_statement
| read_statement
;
assignment_statement : expression ARROW ID
;
if_statement : IF conditional THEN statement_list ELSE statement_list ENDIF
;
do_statement : DO statement_list WHILE conditional ENDDO
;
while_statement : WHILE conditional DO statement_list ENDWHILE
;
for_statement : FOR ID IS expression BY expression TO expression DO statement_list ENDFOR
;
write_statement : WRITE BRA output_list KET write_statement NEWLINE
;
read_statement : READ BRA ID KET
;
output_list : value
| output_list COMA value
;
conditional : expression comparator expression
| NOT conditional
| expression comparator expression AND conditional
| expression comparator expression OR conditional
;
comparator : EQUALS
| NOT_EQUAL
| LESS_THAN
| GREATER_THAN
| LESS_THAN_OR_EQUAL
| GREATER_THAN_OR_EQUAL
;
expression : term
| expression PLUS term
| expression SUBTRACT term
;
term : value
| term TIMES value
| term DIVIDE value
;
value : ID
| constant
| BRA expression KET
;
constant : number_constant
| character_constant
;
**character_constant : APOSTROPHE character APOSTROPHE**
;
number_constant : INTEGER
| SUBTRACT INTEGER
| SUBTRACT INTEGER DECIMAL INTEGER
| INTEGER DECIMAL INTEGER
;
%%


Below is my lexical analyser:



%{
#ifdef PRINT
#define TOKEN(i) printf("Token: " #i "n");
#else
#define TOKEN(i) return (i);
#endif
%}

delim [ rnt]
ws {delim}+
digit [0-9]
character [a-zA-Z]
INTEGER {digit}+
id {character}({character}|{digit})*
character_constant ('{character}')


%%
{ws} ; /* Do Nothing */

"+" TOKEN(PLUS)
"*" TOKEN(TIMES)
"/" TOKEN(DIVIDE)
"-" TOKEN(SUBTRACT)
"(" TOKEN(BRA)
")" TOKEN(KET)
...
"'" TOKEN(APOSTROPHE)
ENDP TOKEN(ENDP)
CODE TOKEN(CODE)
OF TOKEN(OF)
TYPE TOKEN(TYPE)
DECLARATIONS TOKEN(DECLARATIONS)
character TOKEN(CHARACTER)
{INTEGER} TOKEN(INTEGER)
...
{id} TOKEN(ID)
{character_constant} TOKEN(character_constant)
%%


The spelling is correct throughout my files from my BNF to my parser, does anyone know what seems to be the issue here. I've tried changing it to letter instead of character but that just gives me another error.










share|improve this question
























  • You know you can just come and ask me about my assessed coursework. I'm just here....
    – Brian Tompsett - 汤莱恩
    Nov 7 at 12:21













up vote
0
down vote

favorite









up vote
0
down vote

favorite











Having an issue with my parser and I just can't wrap my head around it. I keep getting the error: parser.y:79.33-41: symbol character is used, but is not defined as a token and has no rules. I've put the line in ** **.



Below is my parser code:



%token          PLUS TIMES DIVIDE SUBTRACT BRA KET EQUALS NOT_EQUAL LESS_THAN GREATER_THAN GREATER_THAN_OR_EQUAL
%token COMA SEMICOLON ARROW DECIMAL ENDDO ENDFOR ENDIF ENDP ENDWHILE ELSE CODE OF TYPE DECLARATIONS CHARACTER
%token INTEGER REAL IF THEN DO WHILE FOR IS BY TO WRITE NEWLINE READ NOT AND OR ID LESS_THAN_OR_EQUAL APOSTROPHE

%%
Program : block
| ENDP
| ID
;
block : DECLARATIONS declaration_block CODE statement_list
| CODE statement_list
;
declaration_block : ID OF TYPE SEMICOLON
| ID_list OF TYPE SEMICOLON
| ID_list OF TYPE SEMICOLON declaration_block
;
ID_list : ID
| ID COMA ID_list
;
type : CHARACTER
| INTEGER
| REAL
;
statement_list : statement
| statement_list SEMICOLON statement
;
statement : assignment_statement
| if_statement
| do_statement
| while_statement
| for_statement
| write_statement
| read_statement
;
assignment_statement : expression ARROW ID
;
if_statement : IF conditional THEN statement_list ELSE statement_list ENDIF
;
do_statement : DO statement_list WHILE conditional ENDDO
;
while_statement : WHILE conditional DO statement_list ENDWHILE
;
for_statement : FOR ID IS expression BY expression TO expression DO statement_list ENDFOR
;
write_statement : WRITE BRA output_list KET write_statement NEWLINE
;
read_statement : READ BRA ID KET
;
output_list : value
| output_list COMA value
;
conditional : expression comparator expression
| NOT conditional
| expression comparator expression AND conditional
| expression comparator expression OR conditional
;
comparator : EQUALS
| NOT_EQUAL
| LESS_THAN
| GREATER_THAN
| LESS_THAN_OR_EQUAL
| GREATER_THAN_OR_EQUAL
;
expression : term
| expression PLUS term
| expression SUBTRACT term
;
term : value
| term TIMES value
| term DIVIDE value
;
value : ID
| constant
| BRA expression KET
;
constant : number_constant
| character_constant
;
**character_constant : APOSTROPHE character APOSTROPHE**
;
number_constant : INTEGER
| SUBTRACT INTEGER
| SUBTRACT INTEGER DECIMAL INTEGER
| INTEGER DECIMAL INTEGER
;
%%


Below is my lexical analyser:



%{
#ifdef PRINT
#define TOKEN(i) printf("Token: " #i "n");
#else
#define TOKEN(i) return (i);
#endif
%}

delim [ rnt]
ws {delim}+
digit [0-9]
character [a-zA-Z]
INTEGER {digit}+
id {character}({character}|{digit})*
character_constant ('{character}')


%%
{ws} ; /* Do Nothing */

"+" TOKEN(PLUS)
"*" TOKEN(TIMES)
"/" TOKEN(DIVIDE)
"-" TOKEN(SUBTRACT)
"(" TOKEN(BRA)
")" TOKEN(KET)
...
"'" TOKEN(APOSTROPHE)
ENDP TOKEN(ENDP)
CODE TOKEN(CODE)
OF TOKEN(OF)
TYPE TOKEN(TYPE)
DECLARATIONS TOKEN(DECLARATIONS)
character TOKEN(CHARACTER)
{INTEGER} TOKEN(INTEGER)
...
{id} TOKEN(ID)
{character_constant} TOKEN(character_constant)
%%


The spelling is correct throughout my files from my BNF to my parser, does anyone know what seems to be the issue here. I've tried changing it to letter instead of character but that just gives me another error.










share|improve this question















Having an issue with my parser and I just can't wrap my head around it. I keep getting the error: parser.y:79.33-41: symbol character is used, but is not defined as a token and has no rules. I've put the line in ** **.



Below is my parser code:



%token          PLUS TIMES DIVIDE SUBTRACT BRA KET EQUALS NOT_EQUAL LESS_THAN GREATER_THAN GREATER_THAN_OR_EQUAL
%token COMA SEMICOLON ARROW DECIMAL ENDDO ENDFOR ENDIF ENDP ENDWHILE ELSE CODE OF TYPE DECLARATIONS CHARACTER
%token INTEGER REAL IF THEN DO WHILE FOR IS BY TO WRITE NEWLINE READ NOT AND OR ID LESS_THAN_OR_EQUAL APOSTROPHE

%%
Program : block
| ENDP
| ID
;
block : DECLARATIONS declaration_block CODE statement_list
| CODE statement_list
;
declaration_block : ID OF TYPE SEMICOLON
| ID_list OF TYPE SEMICOLON
| ID_list OF TYPE SEMICOLON declaration_block
;
ID_list : ID
| ID COMA ID_list
;
type : CHARACTER
| INTEGER
| REAL
;
statement_list : statement
| statement_list SEMICOLON statement
;
statement : assignment_statement
| if_statement
| do_statement
| while_statement
| for_statement
| write_statement
| read_statement
;
assignment_statement : expression ARROW ID
;
if_statement : IF conditional THEN statement_list ELSE statement_list ENDIF
;
do_statement : DO statement_list WHILE conditional ENDDO
;
while_statement : WHILE conditional DO statement_list ENDWHILE
;
for_statement : FOR ID IS expression BY expression TO expression DO statement_list ENDFOR
;
write_statement : WRITE BRA output_list KET write_statement NEWLINE
;
read_statement : READ BRA ID KET
;
output_list : value
| output_list COMA value
;
conditional : expression comparator expression
| NOT conditional
| expression comparator expression AND conditional
| expression comparator expression OR conditional
;
comparator : EQUALS
| NOT_EQUAL
| LESS_THAN
| GREATER_THAN
| LESS_THAN_OR_EQUAL
| GREATER_THAN_OR_EQUAL
;
expression : term
| expression PLUS term
| expression SUBTRACT term
;
term : value
| term TIMES value
| term DIVIDE value
;
value : ID
| constant
| BRA expression KET
;
constant : number_constant
| character_constant
;
**character_constant : APOSTROPHE character APOSTROPHE**
;
number_constant : INTEGER
| SUBTRACT INTEGER
| SUBTRACT INTEGER DECIMAL INTEGER
| INTEGER DECIMAL INTEGER
;
%%


Below is my lexical analyser:



%{
#ifdef PRINT
#define TOKEN(i) printf("Token: " #i "n");
#else
#define TOKEN(i) return (i);
#endif
%}

delim [ rnt]
ws {delim}+
digit [0-9]
character [a-zA-Z]
INTEGER {digit}+
id {character}({character}|{digit})*
character_constant ('{character}')


%%
{ws} ; /* Do Nothing */

"+" TOKEN(PLUS)
"*" TOKEN(TIMES)
"/" TOKEN(DIVIDE)
"-" TOKEN(SUBTRACT)
"(" TOKEN(BRA)
")" TOKEN(KET)
...
"'" TOKEN(APOSTROPHE)
ENDP TOKEN(ENDP)
CODE TOKEN(CODE)
OF TOKEN(OF)
TYPE TOKEN(TYPE)
DECLARATIONS TOKEN(DECLARATIONS)
character TOKEN(CHARACTER)
{INTEGER} TOKEN(INTEGER)
...
{id} TOKEN(ID)
{character_constant} TOKEN(character_constant)
%%


The spelling is correct throughout my files from my BNF to my parser, does anyone know what seems to be the issue here. I've tried changing it to letter instead of character but that just gives me another error.







c bison flex-lexer yacc lexical-analysis






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 7 at 6:27









rici

149k19128192




149k19128192










asked Nov 7 at 6:10









Master Chef

125




125












  • You know you can just come and ask me about my assessed coursework. I'm just here....
    – Brian Tompsett - 汤莱恩
    Nov 7 at 12:21


















  • You know you can just come and ask me about my assessed coursework. I'm just here....
    – Brian Tompsett - 汤莱恩
    Nov 7 at 12:21
















You know you can just come and ask me about my assessed coursework. I'm just here....
– Brian Tompsett - 汤莱恩
Nov 7 at 12:21




You know you can just come and ask me about my assessed coursework. I'm just here....
– Brian Tompsett - 汤莱恩
Nov 7 at 12:21












2 Answers
2






active

oldest

votes

















up vote
1
down vote



accepted










The fault is that the single character cannot be differentiated from an identifier in the lexer. You have correctly added a lexer rule to match it which returns a token named character_constant, however you have also put a parser rule for character constant which is not needed, as its already matched in the lexer. The lexer should not be returning an APOSTROPHE as a token as it would have been matched in the character_constant token.



You should just delete the rule from bison for character_constant and add character_constant to the list of tokens matched by the lexer in the %token declaration.



I'd normally recommend using uppercase for the token names to avoid any ambiguity of which is a terminal and which a non-terminal.






share|improve this answer





















  • APOSTROPHE will be returned if '{character}' doesn't match (for example '0'). CHARACTER will be returned instead of ID for the literal identifier character; if that were "corrected" to the macro expansion, it would be favoured for single-character identifiers like x. Of course, you are right about removing character_constant from the grammar, but I don't think either of our answers provides a solid didactic explanation. :-(
    – rici
    Nov 7 at 14:56


















up vote
1
down vote













The message means exactly what it says. You use the symbol character but you have neither declared it to be a token nor have you provided a production for it. So it is neither a terminal nor a non-terminal, and the parser generator complains when it is used.



What happens in your lexer is not visible to the parser generator. So the fact that you have (pointlessly, IMHO) created a lexer definition of {character} is only of interest inside the lexer file. (It's pointless because you could equivalently use the Posix character class [[:alpha:]] which has a clear meaning and is just as readable as {character}.) And really the parser doesn't need to know anything about how the lexer comes up with the token code value. So when you declare a token in the parser definition, the parser generator puts a definition for that symbol in a header file; the lexer #includes that header file, and that lets it use that symbol as a return value for the parser. No other communication is necessary.






share|improve this answer





















  • I have not taught them about the POSIX [[:alpha:]] so they wouldn't know that from class, but of course you are correct. I'll also answer as they person who is running the student labs! Brian
    – Brian Tompsett - 汤莱恩
    Nov 7 at 12:24










  • @brian: frankly, I think you would be doing them a better favour by teaching them about character classes and leaving "definitions" (i.e. macros) for some other moment. In the unicode world, a-z is bereft of meaning and at some point its use will be an automatic demerit. (Yes, flex is different. But still.) Meanwhile, definitions are badly- and over-used and your student's character is just one more example. It is called character but it's an alpha; with the proper name, the error in '[[:alpha:]]' becomes evident.
    – rici
    Nov 7 at 14:41










  • We can continue in chat if you like but I'm going to reluctantly board an airplane soon.
    – rici
    Nov 7 at 14:42











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














 

draft saved


draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53184359%2fparser-y79-33-41-symbol-character-is-used-but-is-not-defined-as-a-token-and-h%23new-answer', 'question_page');
}
);

Post as a guest
































2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
1
down vote



accepted










The fault is that the single character cannot be differentiated from an identifier in the lexer. You have correctly added a lexer rule to match it which returns a token named character_constant, however you have also put a parser rule for character constant which is not needed, as its already matched in the lexer. The lexer should not be returning an APOSTROPHE as a token as it would have been matched in the character_constant token.



You should just delete the rule from bison for character_constant and add character_constant to the list of tokens matched by the lexer in the %token declaration.



I'd normally recommend using uppercase for the token names to avoid any ambiguity of which is a terminal and which a non-terminal.






share|improve this answer





















  • APOSTROPHE will be returned if '{character}' doesn't match (for example '0'). CHARACTER will be returned instead of ID for the literal identifier character; if that were "corrected" to the macro expansion, it would be favoured for single-character identifiers like x. Of course, you are right about removing character_constant from the grammar, but I don't think either of our answers provides a solid didactic explanation. :-(
    – rici
    Nov 7 at 14:56















up vote
1
down vote



accepted










The fault is that the single character cannot be differentiated from an identifier in the lexer. You have correctly added a lexer rule to match it which returns a token named character_constant, however you have also put a parser rule for character constant which is not needed, as its already matched in the lexer. The lexer should not be returning an APOSTROPHE as a token as it would have been matched in the character_constant token.



You should just delete the rule from bison for character_constant and add character_constant to the list of tokens matched by the lexer in the %token declaration.



I'd normally recommend using uppercase for the token names to avoid any ambiguity of which is a terminal and which a non-terminal.






share|improve this answer





















  • APOSTROPHE will be returned if '{character}' doesn't match (for example '0'). CHARACTER will be returned instead of ID for the literal identifier character; if that were "corrected" to the macro expansion, it would be favoured for single-character identifiers like x. Of course, you are right about removing character_constant from the grammar, but I don't think either of our answers provides a solid didactic explanation. :-(
    – rici
    Nov 7 at 14:56













up vote
1
down vote



accepted







up vote
1
down vote



accepted






The fault is that the single character cannot be differentiated from an identifier in the lexer. You have correctly added a lexer rule to match it which returns a token named character_constant, however you have also put a parser rule for character constant which is not needed, as its already matched in the lexer. The lexer should not be returning an APOSTROPHE as a token as it would have been matched in the character_constant token.



You should just delete the rule from bison for character_constant and add character_constant to the list of tokens matched by the lexer in the %token declaration.



I'd normally recommend using uppercase for the token names to avoid any ambiguity of which is a terminal and which a non-terminal.






share|improve this answer












The fault is that the single character cannot be differentiated from an identifier in the lexer. You have correctly added a lexer rule to match it which returns a token named character_constant, however you have also put a parser rule for character constant which is not needed, as its already matched in the lexer. The lexer should not be returning an APOSTROPHE as a token as it would have been matched in the character_constant token.



You should just delete the rule from bison for character_constant and add character_constant to the list of tokens matched by the lexer in the %token declaration.



I'd normally recommend using uppercase for the token names to avoid any ambiguity of which is a terminal and which a non-terminal.







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 7 at 12:30









Brian Tompsett - 汤莱恩

4,153133699




4,153133699












  • APOSTROPHE will be returned if '{character}' doesn't match (for example '0'). CHARACTER will be returned instead of ID for the literal identifier character; if that were "corrected" to the macro expansion, it would be favoured for single-character identifiers like x. Of course, you are right about removing character_constant from the grammar, but I don't think either of our answers provides a solid didactic explanation. :-(
    – rici
    Nov 7 at 14:56


















  • APOSTROPHE will be returned if '{character}' doesn't match (for example '0'). CHARACTER will be returned instead of ID for the literal identifier character; if that were "corrected" to the macro expansion, it would be favoured for single-character identifiers like x. Of course, you are right about removing character_constant from the grammar, but I don't think either of our answers provides a solid didactic explanation. :-(
    – rici
    Nov 7 at 14:56
















APOSTROPHE will be returned if '{character}' doesn't match (for example '0'). CHARACTER will be returned instead of ID for the literal identifier character; if that were "corrected" to the macro expansion, it would be favoured for single-character identifiers like x. Of course, you are right about removing character_constant from the grammar, but I don't think either of our answers provides a solid didactic explanation. :-(
– rici
Nov 7 at 14:56




APOSTROPHE will be returned if '{character}' doesn't match (for example '0'). CHARACTER will be returned instead of ID for the literal identifier character; if that were "corrected" to the macro expansion, it would be favoured for single-character identifiers like x. Of course, you are right about removing character_constant from the grammar, but I don't think either of our answers provides a solid didactic explanation. :-(
– rici
Nov 7 at 14:56












up vote
1
down vote













The message means exactly what it says. You use the symbol character but you have neither declared it to be a token nor have you provided a production for it. So it is neither a terminal nor a non-terminal, and the parser generator complains when it is used.



What happens in your lexer is not visible to the parser generator. So the fact that you have (pointlessly, IMHO) created a lexer definition of {character} is only of interest inside the lexer file. (It's pointless because you could equivalently use the Posix character class [[:alpha:]] which has a clear meaning and is just as readable as {character}.) And really the parser doesn't need to know anything about how the lexer comes up with the token code value. So when you declare a token in the parser definition, the parser generator puts a definition for that symbol in a header file; the lexer #includes that header file, and that lets it use that symbol as a return value for the parser. No other communication is necessary.






share|improve this answer





















  • I have not taught them about the POSIX [[:alpha:]] so they wouldn't know that from class, but of course you are correct. I'll also answer as they person who is running the student labs! Brian
    – Brian Tompsett - 汤莱恩
    Nov 7 at 12:24










  • @brian: frankly, I think you would be doing them a better favour by teaching them about character classes and leaving "definitions" (i.e. macros) for some other moment. In the unicode world, a-z is bereft of meaning and at some point its use will be an automatic demerit. (Yes, flex is different. But still.) Meanwhile, definitions are badly- and over-used and your student's character is just one more example. It is called character but it's an alpha; with the proper name, the error in '[[:alpha:]]' becomes evident.
    – rici
    Nov 7 at 14:41










  • We can continue in chat if you like but I'm going to reluctantly board an airplane soon.
    – rici
    Nov 7 at 14:42















up vote
1
down vote













The message means exactly what it says. You use the symbol character but you have neither declared it to be a token nor have you provided a production for it. So it is neither a terminal nor a non-terminal, and the parser generator complains when it is used.



What happens in your lexer is not visible to the parser generator. So the fact that you have (pointlessly, IMHO) created a lexer definition of {character} is only of interest inside the lexer file. (It's pointless because you could equivalently use the Posix character class [[:alpha:]] which has a clear meaning and is just as readable as {character}.) And really the parser doesn't need to know anything about how the lexer comes up with the token code value. So when you declare a token in the parser definition, the parser generator puts a definition for that symbol in a header file; the lexer #includes that header file, and that lets it use that symbol as a return value for the parser. No other communication is necessary.






share|improve this answer





















  • I have not taught them about the POSIX [[:alpha:]] so they wouldn't know that from class, but of course you are correct. I'll also answer as they person who is running the student labs! Brian
    – Brian Tompsett - 汤莱恩
    Nov 7 at 12:24










  • @brian: frankly, I think you would be doing them a better favour by teaching them about character classes and leaving "definitions" (i.e. macros) for some other moment. In the unicode world, a-z is bereft of meaning and at some point its use will be an automatic demerit. (Yes, flex is different. But still.) Meanwhile, definitions are badly- and over-used and your student's character is just one more example. It is called character but it's an alpha; with the proper name, the error in '[[:alpha:]]' becomes evident.
    – rici
    Nov 7 at 14:41










  • We can continue in chat if you like but I'm going to reluctantly board an airplane soon.
    – rici
    Nov 7 at 14:42













up vote
1
down vote










up vote
1
down vote









The message means exactly what it says. You use the symbol character but you have neither declared it to be a token nor have you provided a production for it. So it is neither a terminal nor a non-terminal, and the parser generator complains when it is used.



What happens in your lexer is not visible to the parser generator. So the fact that you have (pointlessly, IMHO) created a lexer definition of {character} is only of interest inside the lexer file. (It's pointless because you could equivalently use the Posix character class [[:alpha:]] which has a clear meaning and is just as readable as {character}.) And really the parser doesn't need to know anything about how the lexer comes up with the token code value. So when you declare a token in the parser definition, the parser generator puts a definition for that symbol in a header file; the lexer #includes that header file, and that lets it use that symbol as a return value for the parser. No other communication is necessary.






share|improve this answer












The message means exactly what it says. You use the symbol character but you have neither declared it to be a token nor have you provided a production for it. So it is neither a terminal nor a non-terminal, and the parser generator complains when it is used.



What happens in your lexer is not visible to the parser generator. So the fact that you have (pointlessly, IMHO) created a lexer definition of {character} is only of interest inside the lexer file. (It's pointless because you could equivalently use the Posix character class [[:alpha:]] which has a clear meaning and is just as readable as {character}.) And really the parser doesn't need to know anything about how the lexer comes up with the token code value. So when you declare a token in the parser definition, the parser generator puts a definition for that symbol in a header file; the lexer #includes that header file, and that lets it use that symbol as a return value for the parser. No other communication is necessary.







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 7 at 6:33









rici

149k19128192




149k19128192












  • I have not taught them about the POSIX [[:alpha:]] so they wouldn't know that from class, but of course you are correct. I'll also answer as they person who is running the student labs! Brian
    – Brian Tompsett - 汤莱恩
    Nov 7 at 12:24










  • @brian: frankly, I think you would be doing them a better favour by teaching them about character classes and leaving "definitions" (i.e. macros) for some other moment. In the unicode world, a-z is bereft of meaning and at some point its use will be an automatic demerit. (Yes, flex is different. But still.) Meanwhile, definitions are badly- and over-used and your student's character is just one more example. It is called character but it's an alpha; with the proper name, the error in '[[:alpha:]]' becomes evident.
    – rici
    Nov 7 at 14:41










  • We can continue in chat if you like but I'm going to reluctantly board an airplane soon.
    – rici
    Nov 7 at 14:42


















  • I have not taught them about the POSIX [[:alpha:]] so they wouldn't know that from class, but of course you are correct. I'll also answer as they person who is running the student labs! Brian
    – Brian Tompsett - 汤莱恩
    Nov 7 at 12:24










  • @brian: frankly, I think you would be doing them a better favour by teaching them about character classes and leaving "definitions" (i.e. macros) for some other moment. In the unicode world, a-z is bereft of meaning and at some point its use will be an automatic demerit. (Yes, flex is different. But still.) Meanwhile, definitions are badly- and over-used and your student's character is just one more example. It is called character but it's an alpha; with the proper name, the error in '[[:alpha:]]' becomes evident.
    – rici
    Nov 7 at 14:41










  • We can continue in chat if you like but I'm going to reluctantly board an airplane soon.
    – rici
    Nov 7 at 14:42
















I have not taught them about the POSIX [[:alpha:]] so they wouldn't know that from class, but of course you are correct. I'll also answer as they person who is running the student labs! Brian
– Brian Tompsett - 汤莱恩
Nov 7 at 12:24




I have not taught them about the POSIX [[:alpha:]] so they wouldn't know that from class, but of course you are correct. I'll also answer as they person who is running the student labs! Brian
– Brian Tompsett - 汤莱恩
Nov 7 at 12:24












@brian: frankly, I think you would be doing them a better favour by teaching them about character classes and leaving "definitions" (i.e. macros) for some other moment. In the unicode world, a-z is bereft of meaning and at some point its use will be an automatic demerit. (Yes, flex is different. But still.) Meanwhile, definitions are badly- and over-used and your student's character is just one more example. It is called character but it's an alpha; with the proper name, the error in '[[:alpha:]]' becomes evident.
– rici
Nov 7 at 14:41




@brian: frankly, I think you would be doing them a better favour by teaching them about character classes and leaving "definitions" (i.e. macros) for some other moment. In the unicode world, a-z is bereft of meaning and at some point its use will be an automatic demerit. (Yes, flex is different. But still.) Meanwhile, definitions are badly- and over-used and your student's character is just one more example. It is called character but it's an alpha; with the proper name, the error in '[[:alpha:]]' becomes evident.
– rici
Nov 7 at 14:41












We can continue in chat if you like but I'm going to reluctantly board an airplane soon.
– rici
Nov 7 at 14:42




We can continue in chat if you like but I'm going to reluctantly board an airplane soon.
– rici
Nov 7 at 14:42


















 

draft saved


draft discarded



















































 


draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53184359%2fparser-y79-33-41-symbol-character-is-used-but-is-not-defined-as-a-token-and-h%23new-answer', 'question_page');
}
);

Post as a guest




















































































Popular posts from this blog

横浜市

Rostock

Europa