Annotations or Grammar modification for source-to-source C++ transformation ?

>> My aim is to transform extended C++ including into standard C++. The
>> extended C++ includes new statements and expressions that deal with
>> machine-learning.
>>
>
> That's interesting. Curiously, though, I'v been slowly removing support for
> 'extended C++' from Synopsis, as I expect alternative ways to annotate C++
> code (and script synopsis) to be better approaches. May be we can discuss
> that a bit.
>
[...]
>
> Have you considered the possibility to store such annotation in separate
> files with which you would instruct Synopsis how to transform the source
> code ? Changing the parser / frontend isn't particularly flexible...
>
[...]
>
>>  * New entry points in the Parser. In order to extend the grammar, I
>> first started to explore the features related to OpenC++ in the
>> parser. As these features seemed to be half-dead, I finally added new
>> entry points to "hack" the parser (file Parser.hh and Parser.cc):  see
>> parse_user_statement() and parse_user_postfix_expr(). See file
>> CRAlgoParser.h for an example of use.
>>
>
> I will look into those when I get a chance. I'm curious how generic /
> flexible these additions are. In general I believe it to be better not to
> modify the language itself, but instead provide annotations (that could be
> stored in C++ comments, or in completely separate annotation / config files)
> that allow Synopsis to transform the Parse Tree once it is created, instead
> of handle such extensions in the parser.

As I have very specific needs in my extensions, I think that
annotations are expressive enough. For example, I need an extension
that behave as locally defined functions which do not exist in C++.
The core of my transformation is to transform a function in a class.
Local variables and arguments become class member variables, and
locally defined functions become class member functions. It is far
from being clear how to have similar features using only annotations
(either in comments or in a separate file). More than a way to
annotate C++ code, my aim is really to create a "new language", where
the new constructions play a central role. For the moment, the
solution of customizing the parser with virtual functions, is, from a
practical point of view, OK for me. The modifications are clearly
isolated and this solution seems flexible enough to fit several
different needs.
By the way, I continued in this approach by creating a new "UserScope"
class, with associated functions in the ScopeVisitor and in the
SymbolFactory classes.
Note that I only looked at the C++ parser and did not spend time to
learn the whole Synopsis system (in particular, I do not use the
Python interfaces).

Francis.