On Mon, 11 Jun 2001, Wayne Blair wrote:
> > # An AST definition is similar to a grammar, except that:
> > # it doesn't care about syntax differences; it does care
> > # about its meaning-conveying parts, and their naming.

> Very interesting.  I checked out the source you sent, and if I understand
> you correctly, these are definitions for concrete AST nodes that would be
> generated by a yet to be produced lexer-parser.

Yes.

> How much ruby must be implemented in another language (eg. C or java) to
> be able to bootstrap the (ruby?) parser that will generate the trees? 

It depends on what the ruby parser requires, and I'm not writing a ruby
parser.

The bootstrapping would look like this: you parse the parser using that
same parser. You unparse it into the target language (as a bunch of nested
object constructors). You compile/link that with the interpreter.

Now if the parser depends on Ruby code, you can process that code in the
same way (of parse, unparse, compile, link). I'm thinking of MetaRuby's
Hollow Classes (formerly ArrayMixin, etc.) 

> Is having two mechanisms for parsing not less simple than
> having the entire grammar described for the first level parser?

There's only one level of parsing. The grammar defines what is valid
to-be-parsed-code, the AST schema defines that is valid parsed-code.

> Or is your draft just to describe the concrete nodes that would be
> parsed/interpreted by an implementation in a different language, like most
> DOM implementations?

The metatype classes are going to be the "DOM implementation", and are not
written yet. The definitions specific to Ruby are going to be a "schema"
or "dtd" that is relevant to Ruby in particular.

> If this is the case, I assume the ast definition is
> not intended for use by the initial parser/interpreter,

Well, those class definitions have to be put somewhere, so if you don't
bootstrap RubyAST or otherwise convert it to Java, you'll have to write a
lot of dummy code in Java. 

> This would mean that the ast definition or schema is
> only useful for post parsing utilities or interpreted interpreters and
> documentation??

Well, that would already be a big step, but I wish the schema to be as
useful as possible =)

> In any case, please discard the stupid questions I am asking and answer the
> ones that are not stupid so I can start to visualize this with you then ask
> some more stupid questions.

Look, we have this Tower of Babel that is called Computer Science. Half of
the time *will* be spent figuring out each other's mismatching
definitions. There is no fish. ;-)

matju