Re: Bison 1.28b

[Hans Aberg]

At 11:47 +0200 2001/08/05, Axel Kittenberger wrote:
>Okay you've .y for c and .yy for c++, but the world consists of more than
>just c(++). In example I've modified bison to support another language and am
>currently at work to translate bison itself to that language, just for the
>fun of it :o)
>
>I don't know, what are the far targets of bison? Multi programming languages
>support? Support for other parser algorithms? Or maybe alternativly a
>polished input language aviable? (like the lemon parser generator in
>example).

This are some of the issues that I have in my mind, but which I did not
mention explicitly: Output file multi-language support, alternative
algorithms, and .y language extensions. These movements are already
underway by different people at different places, even though it is unclear
if it will have any bearing on Bison. From the discussions I took part in,
it might.

Should each combination have its own extension? -- Then one is onto the
road of putting every option into the input file extension.

If one should follow the practises of other computer languages, it is only
reasonable to have another extension than .y if the input language is so
different as to be wholly incompatible with the original Yacc language: For
example, on my C/C++ compiler, one can choose the output language (object
code for various CPU's), and choose different language features (like
strict/non-strict ANSI, etc), but this is not combined with different file
extensions of the input files. I doubt that GCC is doing that.

So you are introducing a wholly new principle here.

  Hans Aberg