On Tue, 5 Aug 2003, Joseph Ryan wrote:

> >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. (-:
 

Good point. I don't think I was very clear yesterday. Let
me try again. Let's say you're generating... I dunno.. haskell:



 haskell_parser -> ast -> pirate -> parrot_code --> imcc -> pbc
                            ^
                            |
                  parrot_code__templates
                                 
                                
So the haskell parser only has to generate a pirate ast structure.
Either that's a very basic string (I like your XML idea) *or*, in
the future, the parser calls pirate tree-building-methods directly.

The tree-building methods are why I was talking about C, but for
now, I don't mind doing a bunch of xml-generation every time we
call eval/exec. (It's probably the simplest thing to do right now
and should be pretty easy for everyone)


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

I like it! :)

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

Agreed!


> 3.) It would be possible to handle language-specific nodes by
> defining some sort of "raw" node whose value could be raw imcc code.

That's where the templates come in, but since my crack
at a template language last night sucked so bad, I'm
thinking that at least for prototyping I'm going to 
use a python class.

So I'm thinking I'm going to try refactoring so that 
I can do this:

   pypirate something.py > something.xml
   cat something.xml > pirate -l python  > something.imc
   imcc something.imc

or just:

   pypirate something.py | pirate -l python | imcc

or just:

   pypyrate -r something.py 

That also means the "pirate" command can be written in
any language we like. Probably eventually that'll be 
perl6, but for now (unless someone else wants to 
volunteer some code) I plan to work from the code
I have for python.

Sincerely,
 
Michal J Wallace
Sabren Enterprises, Inc.
-------------------------------------
contact: [EMAIL PROTECTED]
hosting: http://www.cornerhost.com/
my site: http://www.withoutane.com/
--------------------------------------


Reply via email to