Bug in Lemon parser with error nonterminals

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug in Lemon parser with error nonterminals

Ludvig Strigeus-2
I got a grammar that looks like:
program ::= stmt.
stmt ::= A B.
stmt ::= error.

The log file shows this for state 0:
State 0:
          program ::= * stmt
          stmt ::= * A B
          stmt ::= * error

                             A shift  2
                         error shift  4
                       program accept
                          stmt shift  1

Yet inputting a single B token (which is invalid) doesn't cause a
shift to state 4.

This is what my tables look like:
static const signed char yy_shift_ofst[] = {
 /*     0 */     8,    3,    5,    4,   10,
};

static const YYACTIONTYPE yy_action[] = {
 /*     0 */     4,    9,    1,    5,    6,   11,   11,    3,   11,    2,
 /*    10 */     7,
};

So when state is 0, the index into yy_action will be yy_shift_ofst[0]
+ YYERRORSYMBOL which is 8+3=11, but yy_action only has 11 elements,
not 12.. the error action is missing from yy_action.

Am I understanding something wrong, or is this a bug in the Lemon parser?

/Ludvig
Reply | Threaded
Open this post in threaded view
|

PRIMARY KEY Issue

Ken & Deb Allen
I have seen frequent mention that the "most efficient" key for a  
SQLITE3 table is to declare a column as "INTEGER UNIQUE". I know from  
past experience that the primary key for any database table should  
consist of the first and contiguous column(s) in the table.

Does SQLITE3 treat the following with the same degree of efficiency,  
or will one result in better performance than the others?


1. CREATE TABLE Table1 (PKey INTEGER UNIQUE NOT NULL, Col2 VARCHAR
(32) NOT NULL, Col3 VARCHAR(64) NULL);

2. CREATE TABLE Table2 (PKey INTEGER NOT NULL PRIMARY KEY, Col2  
VARCHAR(32) NOT NULL, Col3 VARCHAR(64) NULL);

3. CREATE TABLE Table3 (PKey INTEGER NOT NULL, Col2 VARCHAR(32) NOT  
NULL, Col3 VARCHAR(64) NULL, PRIMARY KEY(PKey));

I have not used the first form, and the latter is the form that I  
tend to use since it is the most 'universal' across different  
database packages.

-ken
Reply | Threaded
Open this post in threaded view
|

Re: PRIMARY KEY Issue

Gé Weijers

On Jun 12, 2005, at 5:22 AM, Ken & Deb Allen wrote:
>
> 1. CREATE TABLE Table1 (PKey INTEGER UNIQUE NOT NULL, Col2 VARCHAR
> (32) NOT NULL, Col3 VARCHAR(64) NULL);
Creates a separate index.

>
> 2. CREATE TABLE Table2 (PKey INTEGER NOT NULL PRIMARY KEY, Col2  
> VARCHAR(32) NOT NULL, Col3 VARCHAR(64) NULL);

No separate index, this is the most efficient case. (NOT NULL is  
redundant, PRIMARY KEY implies this)

>
> 3. CREATE TABLE Table3 (PKey INTEGER NOT NULL, Col2 VARCHAR(32) NOT  
> NULL, Col3 VARCHAR(64) NULL, PRIMARY KEY(PKey));
>

No separate index. (NOT NULL again redundant)

"select * from sqlite_master where type = 'index';" will show you  
what you want to know.



> I have not used the first form, and the latter is the form that I  
> tend to use since it is the most 'universal' across different  
> database packages.
>
> -ken
>

--
Gé Weijers
e-mail: [hidden email]