Re: [RFC] %language declaration

[Paolo Bonzini]

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
> abbreviations.
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 "lalr1.cc"

to

   %glr-parser
   %skeleton "glr.cc"

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...

Paolo