----- Original Message -----
From: "Piers Cawley" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, August 11, 2003 5:42 AM
Subject: This Week's Summary


Perl 6 Summary for the week ending 20030810
    Another week, another summary. How predictable is that?
(...)

  Generic code generator?
    Not content with his efforts in porting Python to Parrot, Michal Wallace
    floated the idea of a generic code generator for parrot that everyone
    could use. Stephen Thorne liked the concept, but worried that it
    wouldn't necessarily play well with languages that allowed "eval
    $aString". He proposed that, whatever the code generator got written in
    should be a language that would be self-hosting.

    Joseph Ryan argued that, instead of coming up with a new meta-language
    for the GCG (Generic Code Generator), we should use something like XML
    or YAML as a way of dumping the AST (Abstract Syntax Tree) with
    standardized node names. Dan (who has a 'deep personal loathing for
    XML') was all for just building a standard datastructure and passing
    that into the code generator. (ASTnode.pmc anyone?). He also suggested
    that having some way of doing AST transforms would be handy, as many
    languages would want to get hold of the AST and munge it in some way
    before it went any further (Lisp macros are the canonical example of
    this sort of thing).

    Following the discussion, Michal and Klaas-Jan Stol apparently spiked
    out a prototype that used s-expressions.

    Your summarizer wonders if there's any overlap between this and treecc.
    Maybe I've just misunderstood what treecc was all about.

Yeah, in some way you're right.

TreeCC is a program for managing tree data structures. The user can write
the specification for the nodes (their layout: what fields do they contain)
and
the operations (if any) should be written. The program is very handy in that
it
handles memory stuff (allocation, deallocation, node constructors) and it
checks if a defined operation
is implemented for all node types (if not, an error is emitted).
 (for example, a "print_node" operation should
be implemented for each node type; nodes can extend another node for easy
inheriting)

It should be possible to use TreeCC for designing an standard AST that can
then be
created by any compiler targeting Parrot. When one has this AST, (with a
generate_code operation)
one could just call the generate_code operation, and the compiler writer
doesn't have to write
a single line of IMC. However, TreeCC is written in C, so that might be a
problem, because C isn't hosted by Parrot (yet :)





Reply via email to