----- 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