Re: incorrect yychar for unambiguous GLR

On Mon, 30 Jan 2006, Joel E. Denny wrote: > On Mon, 30 Jan 2006, Paul Eggert wrote: > > > I still mildly prefer "lookahead". However, I'd rather put this off > > until after 2.2 is out, to be honest. > > That's fine. In case it matters, the Open Group also drops the hyphen: http://www.openg

Re: incorrect yychar for unambiguous GLR

"Joel E. Denny" <[EMAIL PROTECTED]> writes: > So, token numbers might be greater than 2^16 (int yyrawchar), Yes. It's longstanding practice that token numbers must be 'int' values. They have to be positive, as nonpositive values represent EOF. > the number of tokens cannot be greater than 2^16

Re: incorrect yychar for unambiguous GLR

On Mon, 30 Jan 2006, Paul Eggert wrote: > I still mildly prefer "lookahead". However, I'd rather put this off > until after 2.2 is out, to be honest. That's fine. > > Also, I have this feeling there's a special procedure associated with > > editing "po/". Or can I just (carefully) search and

Re: incorrect yychar for unambiguous GLR

"Joel E. Denny" <[EMAIL PROTECTED]> writes: > I just noticed that this changes yyrawchar from int to short. I'm not > smart enough to know if this matters. yyrawchar is what yylex returned, right? If so, it must be int, since users can specify token numbers greater than 2**16. __

Re: incorrect yychar for unambiguous GLR

On Mon, 30 Jan 2006, Paul Eggert wrote: > "Joel E. Denny" <[EMAIL PROTECTED]> writes: > > > I just noticed that this changes yyrawchar from int to short. I'm not > > smart enough to know if this matters. > > yyrawchar is what yylex returned, right? If so, it must be int, since > users can spe

Re: incorrect yychar for unambiguous GLR

"Joel E. Denny" <[EMAIL PROTECTED]> writes: > I'm taking a look at doing this. > > Before I start, are we sure? I noticed this in NEWS under 2.0: That was my failed attempt to standardize on "look-ahead" in 2004; see . My 20

Re: incorrect yychar for unambiguous GLR

On Wed, 11 Jan 2006, Joel E. Denny wrote: > On Tue, 10 Jan 2006, Paul Eggert wrote: > > > Clearly either spelling is acceptable. It would make sense to > > standardize on one. Personally I find myself in the (slight) > > majority, and prefer "lookahead" without the hyphen > > I prefer it too.

Re: incorrect yychar for unambiguous GLR

On Wed, 11 Jan 2006, Joel E. Denny wrote: > On Tue, 10 Jan 2006, Joel E. Denny wrote: > > > On Tue, 10 Jan 2006, Paul Hilfinger wrote: > > > > > As things stand, this organization will slightly expand the size of a > > > yyGLRStackItem in some cases. How about the following definition of > > >

Re: incorrect yychar for unambiguous GLR

"Joel E. Denny" <[EMAIL PROTECTED]> writes: > Why must the lookahead token be maintained in two variables? Why not just > maintain yychar and invoke YYTRANSLATE whenever yytoken is needed? In the case of yacc.c, it's most likely efficiency: the desire to avoid reinvoking YYTRANSLATE. The trade

Re: incorrect yychar for unambiguous GLR

On Tue, 10 Jan 2006, Joel E. Denny wrote: > On Tue, 10 Jan 2006, Paul Hilfinger wrote: > > > As things stand, this organization will slightly expand the size of a > > yyGLRStackItem in some cases. How about the following definition of > > yySemanticOption instead? > > > > struct yySemantic

Re: incorrect yychar for unambiguous GLR

On Wed, 11 Jan 2006, Joel E. Denny wrote: > On Wed, 11 Jan 2006, Paul Hilfinger wrote: > > > > I agree about yylookaheadStatuses. However, yylookaheadAvailable sounds > > > like it means yychar != YYEMPTY. The polarity of yylookaheadUnused is > > > confusing, and it sounds like it might indic

Re: incorrect yychar for unambiguous GLR

On Wed, 11 Jan 2006, Paul Hilfinger wrote: > > I agree about yylookaheadStatuses. However, yylookaheadAvailable sounds > > like it means yychar != YYEMPTY. The polarity of yylookaheadUnused is > > confusing, and it sounds like it might indicate whether the lookahead has > > been shifted. How

Re: incorrect yychar for unambiguous GLR

> I agree about yylookaheadStatuses. However, yylookaheadAvailable sounds > like it means yychar != YYEMPTY. The polarity of yylookaheadUnused is > confusing, and it sounds like it might indicate whether the lookahead has > been shifted. How about yylookaheadNeeds, which follows from my comm

Re: incorrect yychar for unambiguous GLR

On Wed, 11 Jan 2006, Joel E. Denny wrote: > +In any semantic action, you can examine @code{yychar} to determine the type > of > +the look-ahead token present at the time of the associated reduction. > +After checking that @code{yychar} is not set to @code{YYEMPTY} or > @code{YYEOF}, > +you can t

Re: incorrect yychar for unambiguous GLR

I installed this. 2006-01-11 Joel E. Denny <[EMAIL PROTECTED]> * doc/bison.texinfo: Fix some typos. (GLR Semantic Actions): New subsection discussing special considerations because GLR semantic actions might be deferred. (Actions): Mention look-ahead usage of yyl

Re: incorrect yychar for unambiguous GLR

> > Let's say instead > > > >In a deferred semantic action, its effect is undefined. > > I was trying to leave the door open for others to pursue this feature > because, even though it doesn't interest me, it might be reasonable. But > `undefined' seems accurate. Actually, I ki

Re: incorrect yychar for unambiguous GLR

On Tue, 10 Jan 2006, Paul Eggert wrote: > "Joel E. Denny" <[EMAIL PROTECTED]> writes: > > > 3. I tend to follow the usual LaTeX and HTML coding style: one line break > > after a sentence, two line breaks after a paragraph. This makes editing > > much easier for me: it's easier to reorder sente

Re: incorrect yychar for unambiguous GLR

> 1. I've documented the use of YYEOF, yylval, and yylloc in semantic > actions. Was this intentionally omitted before? Why? Nah, just never got around to it, I guess. > +During deterministic @acronym{GLR} operation, the effect of @code{YYERROR} > is > +similar to its effect in an @acro

Re: incorrect yychar for unambiguous GLR

> This is a complex patch. More pairs of eyes would be helpful. Always a good idea. > @@ -761,6 +761,11 @@ struct yyGLRState { > > struct yyGLRStateSet { >yyGLRState** yystates; > + /** During nondeterministic operation, yylookaheadStatuses tracks which > + * stacks have actually ne

Re: incorrect yychar for unambiguous GLR

"Joel E. Denny" <[EMAIL PROTECTED]> writes: > 3. I tend to follow the usual LaTeX and HTML coding style: one line break > after a sentence, two line breaks after a paragraph. This makes editing > much easier for me: it's easier to reorder sentences, and it's easier to > fix line-wrapping after

Re: incorrect yychar for unambiguous GLR

On Tue, 10 Jan 2006, Paul Eggert wrote: > Clearly either spelling is acceptable. It would make sense to > standardize on one. Personally I find myself in the (slight) > majority, and prefer "lookahead" without the hyphen I prefer it too. > but I'm too lazy to change everything myself. I suppo

Re: incorrect yychar for unambiguous GLR

On Tue, 10 Jan 2006, Paul Hilfinger wrote: > > 1. I've documented the use of YYEOF, yylval, and yylloc in semantic > > actions. Was this intentionally omitted before? Why? > > Nah, just never got around to it, I guess. That's the answer I was hoping for. > > +During deterministic @acronym

Re: incorrect yychar for unambiguous GLR

"Joel E. Denny" <[EMAIL PROTECTED]> writes: > Also, the documentation likes to hyphenate `look-ahead'. Should it be > yylookAheadNeeds (capital 'A')? Is Paul Eggert the authority on this > issue? Naah, I just used my spelling checker, which didn't have "lookahead". I just now checked Google

Re: incorrect yychar for unambiguous GLR

On Tue, 10 Jan 2006, Paul Hilfinger wrote: > > @@ -761,6 +761,11 @@ struct yyGLRState { > > > > struct yyGLRStateSet { > >yyGLRState** yystates; > > + /** During nondeterministic operation, yylookaheadStatuses tracks which > > + * stacks have actually needed the current lookahead. Duri

Re: incorrect yychar for unambiguous GLR

On Fri, 6 Jan 2006, Joel E. Denny wrote: > On Tue, 19 Jul 2005, Joel E. Denny wrote: > > > Should yychar be reliable in semantic actions when declaring %glr-parser? > > I've installed this patch, which fixes the GLR lookahead bugs I've > encountered and adds some related test cases. Although m

Re: incorrect yychar for unambiguous GLR

On Tue, 19 Jul 2005, Joel E. Denny wrote: > Should yychar be reliable in semantic actions when declaring %glr-parser? I've installed this patch, which fixes the GLR lookahead bugs I've encountered and adds some related test cases. Although my original post was mainly about deterministic operat

incorrect yychar for unambiguous GLR

Should yychar be reliable in semantic actions when declaring %glr-parser? It gives results that I do not expect for both bison 1.875 and 2.0. I can understand that delayed semantic actions might cause trouble in the case of ambiguous grammars (although it would be nice if they didn't). However, fo