On Fri, 19 May 2006, Joel E. Denny wrote:
> On Fri, 19 May 2006, Derek M Jones wrote:
>
> > On the subject of new features. I have just been bitten (again)
> > by not being able to execute any actions in when multiple parse
> > stacks are in existence. Having a way of specifying a non-deferred
On Fri, 19 May 2006, Joel E. Denny wrote:
> On Fri, 19 May 2006, Derek M Jones wrote:
>
> > > Exposing internal data structures like yyGLRStack and yySemanticOption to
> > > the user is scary. Bison developers would then have to worry about
> > > backward
> > > compatibility issues as we tried
Bison version 2.2 has been released.
Aside from bug fixes, the most important changes in Bison 2.2 are in
the new parser skeletons, used to generate parsers other than the
traditional Yacc-like parsers. Among other things, the distribution
terms now permit using Bison-generated parsers in nonfree
Joel,
YYSTYPE my_reportAmbiguity(YYSTYPE yyZ0,
YYSTYPE yyZ1,
...)
...
Who writes print_reductions_func? What does it do precisely?
The intent is that my_reportAmbiguity be able to duplicate the
functionality of yyreportAmbiguity, so it w
On Fri, 19 May 2006, Derek M Jones wrote:
> On the subject of new features. I have just been bitten (again)
> by not being able to execute any actions in when multiple parse
> stacks are in existence. Having a way of specifying a non-deferred
> action would solve a recurring problem of mine.
I'
On Fri, 19 May 2006, Derek M Jones wrote:
> > Exposing internal data structures like yyGLRStack and yySemanticOption to
> > the user is scary. Bison developers would then have to worry about backward
> > compatibility issues as we tried to evolve these structures and
>
> I take it what you mean
Joel,
One possible solution would be to allow the grammar writer to
specify weights for a particular reduction. When a conflict
occurred the one with the greatest weight would be chosen.
A conflict action (which we proposed earlier) could be encoded with these
weights so it could choose a re
Joel,
The function prototype might be:
YYSTYPE my_reportAmbiguity(yySemanticOption *yyx0,
yySemanticOption *yyx1,
yyGLRStack *yyStack,
YYSTYPE yyZ0,
YYSTYPE yyZ1)
{
...
return yyZ0;
}
On Fri, 19 May 2006, Satya Kiran wrote:
> Sorry for a small digression, but are we moving toward implementing
> probablistic CFGs in bison? or is my understanding very oblique..
> thanks!
So far, I think we're just talking about how a Bison user might implement
this (and other things) himself us
Sorry for a small digression, but are we moving toward implementing
probablistic CFGs in bison? or is my understanding very oblique..
thanks!
./satya
On 5/19/06, Joel E. Denny <[EMAIL PROTECTED]> wrote:
On Fri, 19 May 2006, Derek M Jones wrote:
> likely; as least I think so until my figures sh
On Fri, 19 May 2006, Derek M Jones wrote:
> likely; as least I think so until my figures show otherwise;
> which they cannot until I have have access to both parse
> trees when an ambiguity occurs).
If you construct parse trees (a parse forest really) in your semantic
actions, you will have acce
All,
There is a request in the TODO of the 2.1a alpha
release asking if anybody knows how to get hold of
the book "LR parsing: theory and practice".
I find AddAll to be very good for locating out of
print books, and it lists two copies of this book :-)
http://www.addall.com/SuperRare/submitRare
On Fri, 19 May 2006, Derek M Jones wrote:
> Given that there will only be one instance of it perhaps it should
> go on the first rule?
>
> TU: program ; %ambiguity
>
> It could also go in the definitions section:
>
> %ambiguity my_reportAmbiguity
>
> I don't see any advantage for either way
Joel,
> In the meantime, it might be worthwhile to work out the exact
> functionality you envision by discussing it on this list. Once you (or
> someone else who gets interested) is ready to write it, it will then
stand
> a better chance of being accepted -- and being accepted without an
> ext
Joel,
Define the interface of this new function and how it should be declared.
The current definition of yyreportAmbiguity + the necessary changes
to implement the functionality of a merge.
Can you be more specific? Would it be declared in the definitions section
or alongside specific rules
15 matches
Mail list logo
