[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: User Token Numbers
From: |
Paul Eggert |
Subject: |
Re: User Token Numbers |
Date: |
Tue, 9 Apr 2002 17:41:27 -0700 (PDT) |
> From: Akim Demaille <address@hidden>
> Date: 09 Apr 2002 11:59:42 +0200
>
> the user _has_ to write
>
> %token error 257
> %token FOO 256
Yes, that's my reading of it, if they want it to be portable to all
POSIX implementations. Admittedly the standard doesn't contain this
particular example.
I think it's OK for Bison to accept
%token FOO 256
%token error 257
as an extension. I don't think a diagnostic is required when
accepting the extension.
> Should the token error be #define'd in the .h?
Unix yacc does not do that. Like Bison, it puts `#define YYERRCODE
256' into the .c file, but nothing in the .h file. With Unix yacc, if
you have `%token error 1000' in the input, this changes the .c #define
to be 1000 instead of 256, and it redoes the tables accordingly, but
the .h file stays the same.
The lexical analyzer is not supposed to return the error token, so
that probably explains why historically the token was not in the .h
file. The standard does not explicitly prohibit putting `#define
YYERRCODE whatever' into the .h file, so I guess it'd be OK to do that
if there's a good reason to.
> Why does it matter to map error to 256?
My guess is that it's so that this:
%token FOO 257
will work even on single-pass implementations of yacc. Otherwise, a
single-pass implementation that by default mapped error to 257 would
reject `%token FOO 257'. Historically, grammars just used numbers
greater than 256, and my guess is that the POSIX authors wanted such
grammars to work on single-pass implementationms.
- User Token Numbers, Akim Demaille, 2002/04/08
- Re: User Token Numbers, Paul Eggert, 2002/04/08
- Re: User Token Numbers, Akim Demaille, 2002/04/08
- Re: User Token Numbers, Paul Eggert, 2002/04/08
- Re: User Token Numbers, Akim Demaille, 2002/04/09
- Re: User Token Numbers,
Paul Eggert <=
- Re: User Token Numbers, Akim Demaille, 2002/04/10
- Re: User Token Numbers, Hans Aberg, 2002/04/10
- Re: User Token Numbers, Paul Eggert, 2002/04/10
Re: User Token Numbers, Florian Krohm, 2002/04/08
Re: POSIX and reduce/reduce conflicts, Paul Eggert, 2002/04/08