Re: [DotGNU]Can treecc help me?

[Adam Treat]

On Sunday 02 February 2003 04:26 pm, Rhys Weatherley wrote:
> Treecc works best where there are common operations across the entire set
> of nodes.  Also, each case needs to be relatively independent.  That is,
> the operation for a particular node type should be written in terms of just
> the fields in the node, and recursive calls on the children.
>
> Binge may be a good candidate for this - I'd have to study it more closely.
> The generators could probably be turned into node operations fairly easily.
>
> The nodes themselves in Binge.Bits are currently a mixture of data and
> utility routines.  The utility routines would have to be ejected to
> somewhere else, as either node operations, or static methods in some
> separate utility class.

Ah, then you know what I'm doing with binge.  It is correct that the nodes in 
Binge/Bits have utility functions.  I've been thinking of putting ever more 
utility functions in the nodes and getting rid of the conversion funcitons in 
CSConverter ... etc, etc.  This is what I mean by moving to more of an 
inheritance pattern.

> > Currently, I am using a
> > visitor pattern with a little mix of the inheritance pattern.  I've
> > seriously thought about moving to an inheritance pattern completely, but
> > now I'm in doubt.  Let me describe Binge a little more:
>
> Treecc allows you to easily switch between the inheritance and visitor
> styles. Or have some operations be inheritance, and others be visitors.

This sounds like a good match, but I'll have to look into it a bit more.

> > I don't entirely understand treecc.  It seems that you write input files
> > for treecc that use an internal treecc language and then treecc will
> > generate scaffolding for your compiler in whatever output language you
> > choose. Surely, this scaffolding is just stub code and you'd have to
> > actually modify the scaffolding to produce a compiler ... but then you
> > are likely to regenerate the scaffolding as you flesh out the compiler so
> > then you'd have to reinsert the implementation code ... What am I
> > missing?
>
> It doesn't generate scaffolding that you then modify.  It is similar to
> bison in that you insert the implementation code directly into the input
> files, and the tool generates the final scaffolding+implementation. 
> Consider the following from CSConverter.cs:
>
>         public override void Convert (Field field)
>         {
>             field.TargetName = ReservedName (field.NativeName);
>         }
>
> This would turn into something like this:
>
>      %node BingeObject %abstract %typedef
>      %node Field BingeObject = { ... }
>
>      %operation %virtual void CSConvert(BingeObject this)
>
>      CSConvert(Field)
>      {
>             this.TargetName = ReservedName (this.NativeName);
>      }
>
> As you can see, the original code is in the treecc input, and will get
> inserted at the correct place when treecc is run.  You then compile the
> output as-is.  There is no need to modify the output further.

Ok, I'll have to look into this and see if I can't write a prototype to 
understand what I've *gained* by writing it this way.

> As Gopal mentioned, you may want to have a look at the JScript code, as it
> shows using treecc in C# on a substantial system.

I'll have a look at this example, but I have another question.  You wrote in 
your paper that you don't want to create an entirely new language for the 
Aspect Oriented treecc, because that would have a bootstrapping problem in 
compiler writing.  Well, wouldn't it be possible to add language level 
support for Aspect Oriented programming to C# alla AspectC# ??  Now, I don't 
know much about Aspect Oriented programming other than what you've written 
and browsed the AspectJ site, but it seems that this could be another 
tool/option for cscc that might be kinda cool..

Cheers,
Adam