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.
I'd much rather go for the AST directly for a number of reasons. Not the least of which is a deep personal loathing for XML, but putting that aside it seems sub-optimal to have a binary structure which we then serialize to text and then deserialize all as part of a single parse and compile stage. XML has the added disadvantage of needing a good XML parser, which probably means expat or something like it. (Yeah, I know, we could restrict ourselves to a subset of XML so we don't have to have a full parser, but that'll never last--someone'll expand it to a full parser at some point)
Going for a full-fledged AST builder/flattener meets some of the long-term goals as well, as it's been planned to be the stage between the parser and IMCC for ages (pretty much since IMCC first appeared) so it'd be worthwhile.
We should consider AST transforms as well, since a number of optimizations are best performed on the AST, and many languages will want to get hold of the AST before it goes any further and process it in some way. (This would be how Lisp macros would act, for example)
> 1.) Instead of forcing the compiler writer to generate code, thecompiler 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! :)
This'd be a cool thing to be sure, and useful as a human-readable form. (Though I'd prefer the AST that's frozen into the bytecode be in a form that's more efficient to deserialize) I'd best go and update the license terms then, to make sure there aren't any problems. (Old issues raised by GCC an age ago)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
