Re: GSoC

[Hans Aberg]

On 25 Mar 2007, at 12:14, Max Katsev wrote:

> I'm interested in applying for GSoC for extending Bison to other  
> languages.
> But I'd like to ask some questions first:
> 1. List of languages. I have strong knowledge of C/C++, Java, Pascal
> and base knowledge of C#, python, perl.

Perhaps functional languages as well, like Scheme, Haskell.

> Also, how many languages do you expect to be implemented?

I think the problem is to maintain it, and to synchronize the  
different output language versions. Therefore, I had the idea of  
creating a small common language, from which outputs i several  
different language might be produced. This might work, as the  
language features that are needed for a parser is rather limited.

But think of C and C++: They have rather different syntax of how to  
initialize objects. So one would need to separate the features only  
needed for the parser, and then write components, like stack  
implementation by hand.

> 2. I think that not rare scenario is when somebody wants to create
> grammar file to be converted to several languages, not one. But here a
> problem with user actions arises. He will have to keep several copies
> of input file with user actions in different languages.
> I propose to add following feature: user creates multiple-language
> user actions, marking different parts somehow, so that bison takes  
> only
> one part of each action when using specific skeleton.

If you have action code for multiple actions, then the code might  
look ugly. But one can think of putting the actions at different  
places than the rules. Then add a selection mechanism for the  
language. Then this becomes possible.

For example:
list:
   #list-empty-code
 | list #list-recursion-code
;

...
#list-empty-code/C {...}
...
#list-empty-code/C++ {...}

However, the syntax should be synced with other suggestions, like  
perhaps EBNF support (see this subject n the Help-Bison list).

Also, one needs to think what to do about the default actions: The  
implementation in C is untyped, also when %union is being used, so $$  
= $1 is OK. Now, with C++, one needs a typed version, $<type>$ =  
$<type>1, which means that these cannot be collected into a single  
point in the parser 'switch' statement.

Now, with your problem, it may mean that one needs to be able to  
express things like:
#default-action/C { $$ = $1; }
#default-action/C++ { $<type>$ = $<type>1; }

Just putting this up for thought - Bison cannot handle output- 
language typed versions of %union yet.

  Hans Aberg