[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: prologue alternatives
From: |
Joel E. Denny |
Subject: |
Re: prologue alternatives |
Date: |
Mon, 18 Sep 2006 17:48:11 -0400 (EDT) |
On Sun, 17 Sep 2006, Paul Eggert wrote:
> "Joel E. Denny" <address@hidden> writes:
>
> > Are you suggesting YYSTYPE shouldn't be a single union?
>
> Yes, if that's a better way to handle multiple uses of %union.
I'm not sure how that would go.
> > I see the Bison grammar file language as something of a meta language that
> > can do better than C... and %type-code{...} seems to make that possible.
>
> I guess that's where we disagree. I think Bison's grammar language is
> inherently linked to the underlying implementation language (C or Java
> or whatnot), and that people can't make sensible use of one without
> understanding the other.
I don't mean to say that people can use one without understanding the
other. I just think Bison can sometimes help alleviate some of the
limitations in C (or whatever) in order to improve the maintainability of
parser specifications.
> It's possible to design things differently, but that would be a major
> redesign, and arguably it wouldn't be Yacc-like (or Bison-like :-) any
> more.
Of course, I haven't used Bison as long as you have, so I don't have the
same sense of what's Bison-like. However, I think we're discussing
reasonably small steps towards a better Bison.
> > If I suddenly realized that I needed to add a header that contained
> > YYSTYPE,
>
> This is not a normal small change that one would make to a grammar.
> It's all right if a disruptive change like that causes, well,
> disruption.
I agree that it's a minor point.
> > if we're going for maximum flexibility in all areas, we could
> > take your proposal and extend your $declare{YYSTYPE} to a general variable
> > language. Where "stype-code" is a user variable and "YYSTYPE" is a Bison
> > variable:
> >
> > %header {
> > $var{stype-code}
> > $var{YYSTYPE}
> > }
>
> Something like that might be reasonable, yes.
>
> Also, it might make sense to let the user specify the name of
> the header, or even to generate multiple (different) headers.
>
> More generally, perhaps we should have a sublanguage to let the user
> generate arbitrary files containing information of interest.
So, replace %header with:
%file "my_parser.h" {
$var{stype-code}
$var{YYSTYPE}
}
In this case, the user might wish not to use %defines. However, some of
the skeletons require %defines. In order to get the declaration order
right in that required header file, it might be necessary to have:
%defines "my_parser.h" {
$var{stype-code}
$var{YYSTYPE}
}
to tell Bison that "my_parser.h" is the header file it requires.
- Re: prologue alternatives, (continued)
- Re: prologue alternatives, Paul Eggert, 2006/09/15
- Re: prologue alternatives, Joel E. Denny, 2006/09/15
- Re: prologue alternatives, Paul Eggert, 2006/09/16
- Re: prologue alternatives, Joel E. Denny, 2006/09/16
- Re: prologue alternatives, Paul Eggert, 2006/09/16
- Re: prologue alternatives, Joel E. Denny, 2006/09/16
- Re: prologue alternatives, Joel E. Denny, 2006/09/16
- Re: prologue alternatives, Paul Eggert, 2006/09/16
- Re: prologue alternatives, Joel E. Denny, 2006/09/16
- Re: prologue alternatives, Paul Eggert, 2006/09/17
- Re: prologue alternatives,
Joel E. Denny <=
- Re: prologue alternatives, Paul Eggert, 2006/09/18
- Re: prologue alternatives, Joel E. Denny, 2006/09/18