[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] %language declaration

From: Paolo Bonzini
Subject: Re: [RFC] %language declaration
Date: Thu, 14 Sep 2006 14:46:41 +0200
User-agent: Thunderbird (Macintosh/20060719)

Akim Demaille wrote:
"Paolo" == Paolo Bonzini <address@hidden> writes:
 > I agree with Tim.  Bison should avoid as much as possible any
 > *dependence* on the output language in the input (e.g. it would be
 > crazy to change the definition of identifiers, or expecting [] instead
 > of {} in a hypotetical Smalltalk parser), but this is just syntactic
 > sugar for choosing a skeleton.

Sugar?  In my book syntactic sugar means providing convenient
Convenient abbreviations, or convenient forms. In this case, in C you only need to add "%glr-parser" for example. In C++, you have to change

   %skeleton ""


   %skeleton ""

With %language, the change would be the same -- add "%glr-parser".
But if that's a common demand, I won't stop you here.  I just feel
like we're not KISS.  I foresee the code that will be needed to report
that a given skeleton type does not exists for a given language, that
a given language is not supported (which will require browsing the
file system as I am against open-coding any material related to the
skeletons/languages in Bison etc.).
Note that I agreed with Tim only on the "a grammar is inherently language dependent" part. The Perl complaints you had will find me totally deaf to them, it's the language that has problems there... ;-)

I'm also not going to delve into naming schemes for skeletons, and so on. It's not worth for sure while we have only two grammar kinds, and if anything I'd rather have a config file in /usr/share/bison than doing file system scanning.

You can already look at the patch I posted. The only difference between that one and the patch for which I will ask for approval, is a change to not add the .tab part to the filename in Java (because that's not allowed by the language's rules for file names) -- I can see that it is a bit more than syntactic sugar then. If that's already too much, we're in disagreement and I'll look for an alternative solution. Otherwise, so far so good...


reply via email to

[Prev in Thread] Current Thread [Next in Thread]