----- Original Message -----
From: "Joseph Ryan" <[EMAIL PROTECTED]>
To: "Michal Wallace" <[EMAIL PROTECTED]>
Cc: "K Stol" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, August 05, 2003 12:24 AM
Subject: Re: generic code generator? [was: subroutines and python status]
> Michal Wallace wrote:
>
> >On Sun, 3 Aug 2003, K Stol wrote:
> >
> >
> >
> >>>What do you think? Want to try squishing pirate/python
> >>>and pirate/lua together? :)
> >>>
> >>>
> >>Yeah, I like the idea. Let's try this out.
> >>
> >>
> >
> >
> >Well, I finished reading your report[1] and
> >posted some of my (rather unorganized) thoughts
> >up at [2]
> >
> >It does seem like there are some snags getting
> >languages to talk to each other, even with the
> >calling conventions, but even so, I'm even more
> >convinced now that a generic, overridable
> >code-generator is the way to go.
> >
> >It seems to me that if we want to maximize the
> >number of languages using it, the generic
> >compiler shouldn't depend on anything but
> >C and parrot... But until we get it working,
> >I'd like to stick to a dynamic language like
> >python/perl/lua/scheme. And, well, my code's
> >already in python... :) [though I'd actually
> >love to try out some lua 5]
> >
> >What I'm picturing is a template system for
> >specifying chunks of IMCC. Something like this:
> >
> >
> >ast generic:
> > on @while(test, body):
> > % while = gensym("while")
> > % endwhile = gensym("endwhile")
> > % test = gensym("$I")
> >
> > {while}:
> > {test} = @expr
> > unless {test} goto {endwhile}
> > @body
> > {endwhile}:
> >
> > on @if(test, elif*, else?):
> > ...
> >
> >ast python(generic):
> > on @while(test, body, else?):
> > ...
> >
Yeah, I like the template idea.
> >
> >Okay, I don't have a good syntax in mind yet,
> >the point is it's a template language and you
> >can subclass/override/extend the template.
> >Maybe there's no syntax and it just uses
> >cleanly coded classes in some oo language.
> >Or perl6 with it's grammars and rules. I
> >don't know.
> >
>
> I think that trying to define a new syntax for a new meta-language is a
bad
> idea. The goal of a GCG (Generic Code Generator) should be to
> allieviate the
> compiler writers of the responsiblity of generating code. Forcing them to
> generate different code doesn't help solve the problem. (-:
>
> However, at the risk of sounding lame, what if the GCG syntax was
> instead some
> sort of standard meta-language structure like YAML or XML?
XML also has a syntax...sounds just like the template idea to me.
As in, the
> syntax
> wouldn't be a syntax at all, but just a dump of the AST with
> standardized node
> names. I think this would have a number of benefits:
>
> 1.) Instead of forcing the compiler writer to generate code, the
> compiler writer
> would only have to transform the parse tree into a structure that is
> name-consistant with the GCG's standard, and then use any of a number of
> existing libraries to dump the tree as YAML/XML.
>
> 2.) Since there are more YAML/XML parsers than I can count implemented in
> nearly modern useful language I can think of, the GCG could be generated
in
> any language without causing a stall on starting on the generic code
> generation
> part of the project. (you know, the important part)
The parsing should not be a problem (well, unless we come up with a really
nasty syntax)
Using a tool such as Yacc really helps for fast prototyping.
>
> 3.) It would be possible to handle language-specific nodes by defining
some
> sort of "raw" node whose value could be raw imcc code.
This would be really handy.
>
> Anyways, just a few thoughts. A tool like this would be *very* useful,
> I think. Good luck. (-:
>
> - Joe
>
I quickly scanned all messages on this topic, so I really read it fast (and
probably missed some things I guess).
Here are my ideas. I have to think things over well, but here are my quick
thoughts.
I like the ideas of templates. Furthermore, ...
> I think that trying to define a new syntax for a new meta-language is a
bad
> idea. The goal of a GCG (Generic Code Generator) should be to
> allieviate the
> compiler writers of the responsiblity of generating code. Forcing them to
> generate different code doesn't help solve the problem. (-:
I don't think the compiler writer has to *generate* this metacode, but it
can be used just like YACC and LEX:
just create a code generater generater based on some file. Most ideal would
of course be a compiler that can be constructed like:
LEX input file -> Lex -> scanner
YACC input file -> Yacc -> parser
TREECC input file -> TreeCC -> AST code
PIRATE[1] input file -> Pirate -> Code generator
But that's for later :-)
[1] I just called this project "pirate" because of the similarly named
compilers for which it could be used (Lua/Python, and this "pirate" is
Taking Over the Ship of Code generation :-P, oh well....)
Well, just got home, so I'll go read it better soon.
Klaas-Jan
