Re: %include

[Akim Demaille]

> Le 30 sept. 2018 à 12:32, Bruce Mardle <address@hidden> a écrit :
> 
> > > would it be possible to implement a ‘%include' directive?
> > > It would make my most recent bison-using project less confusing.
> > 
> > It’s been on my todo list for years…  Yes, it would be good
> > to have something like that.  However, as a C/C++ programmer,
> > I have learnt to hate the concept of include, waiting eagerly
> > for import.
> 
> Perhaps it'd help if I briefly describe my project (a Z280 assembler).
> The file (everything.y) which bison processes is made by concatenating 3 file:
> beginning.y, which I wrote,
> middle.y, which is written by a C program I wrote, and
> end.y, which I wrote.

Could you describe them a bit?  Or maybe it’s public somewhere?
I’m especially interested in seing their structures.  Are the
included files only composed of rules?

> So when bison finds an error, it reports the line number in terms of
> everything.y, not 1 of the other 3 .y's.
> It'd be nice if I could have a .y file containing all the bison code I wrote
> with
> %include "middle.y"
> in the middle.
> 
> Alternatively, bison could have a %line direction, like C's #line. (Yes, I 
> know
> bison *outputs* #line directives, but it doesn't seem to allow them in .y
> files.)

That’s weird.  It is supposed to grok the #line in input too.
Maybe you’ve put some in places we failed to cover?

I agree the code for it is not reassuring:

  /* #line directives are not documented, and may be withdrawn or
     modified in future versions of Bison.  */
  ^"#line "{int}(" \"".*"\"")?"\n" {
    handle_syncline (yytext + sizeof "#line " - 1, *loc);
  }

but I don’t see why we should get rid of this.  Paul Eggert felt
uneasy with the feature, but I don’t remember why.

It turns out that I use this feature a lot: the examples in the
examples/ directory are extracted from the documentation, and
when I do something wrong, the error is properly reported in the
doc, not in the extracted file (see an example with the #line in
attachment).

parser.yy
Description: Binary data

> > For instance I would be happier if we had some form of scoping.
> > For instance, maybe not all the nonterminals should be exposed
> > from the imported grammar file to the importing one.  Maybe
> > too we should try to see if we can keep the precedence/associativity
> > directives local to each subgrammar (currently there’s a single
> > ’scale’ of precedences and precedences of the subgrammars would
> > have ’naturally’ more precedence than that of the including
> > grammar).
> 
> I think I’ll have to ponder that some more before I understand it!

You might for instance use the non terminal ‘exp’ in a subgrammar,
and maybe it’s an implementation detail.  Maybe what you export to
the main grammar is ’stmt’.  Then, if you also happen to use the
non terminal ‘exp’ (to denote something else), Bison will fuse
the rules together, as if they were a single symbol.  But maybe
it’s only an accidental identifier clash.

My idea would be to have Bison play games with such names to avoid
these collisions.  Except for the ‘exported’ symbols, of course.



> > > Other 'yaccs' have it.
> > 
> > It would be interesting to see how others have done this: what
> > tools are you thinking about?
> 
> Ermm, now I come to look again, the only variant I can find which supports
> %include is btyacc:
> https://www.siber.com/btyacc/

Amusingly, many years ago (almost 20 I think, Gosh!) I discussed
with its author, Vadim Maslov, to include back-tracking into Bison.
But all of the sudden, we were offered a full implementation of
GLR for Bison (by Paul Hilfinger).  That was an amazing gift!

Since then, I don’t see any competitive advantage to BT over GLR.


> A hasty read of the source shows that the relevant code is in the function
> get_line in file reader.c . I think it only accepts 1 level of
> inclusion.

What are the constraints?  Is the included file allowed to declare
%union members, or precedence, etc.?  Or must it be only rules
(the middle section, between both %%)?