[ruby-talk:11126] Re: RFC: RubyVM (long)

On Tue, 13 Feb 2001, Robert Feldt wrote:

> > In a Ruby-in-Ruby perspective, that's precisely why I'm doing those first: 
> > they are outer layers, and therefore they are easier to rewrite, less code
> > depends on them, and they are the big weight that make it quite effortful
> > to, say, write a Ruby interpreter in Java (or in Scheme, Caml, etc).
> Ok, but IMHO you dont need very many of these outer classes to start
> working on the core stuff. Basically String, Array and Hash from my
> limited understanding of Matz Ruby interpreter.

Q: What are the contents of MetaRuby right now?
A:
 * ArrayMixin
 * HashMixin
 * StringMixin

> I don't see the need for for example Bignum arithmetic in the core
> classes so for me it might be ok to simply translate arithmetic directly
> to C ditto. 

There's another reason not to write Bignum right away: it's that there is
much less benefit to having it (outside of porting the interpreter). And
there's yet another one: it is very much tied with Fixnum. So Bignum will
be done much later.

> I really don't think we disagree very much.

I really don't think we do either.

> Instead of arguing over the "right way" we should probably each work from
> our preferred end.

Well I'm not really arguing =) I don't expect that we keep our efforts
separate; and I don't expect that we work both on exactly the same thing.

> I'll tell you what I've done so far on this parser gen:
> 
> * Specified a grammar for grammars (its similar to SableCC's format, but
> even simpler with Ruby RegExp'sfor the tokens)
> * Hand-coded this grammar
> * Implemented the LALR(1)-gen algs in Dragon book
> * A really simple lexer gen that simply applies the token regexps in
> order until a match is found (This may not give good enough performance
> but we can do a more traditional DFA-based gen later...)
>  * Generated a grammar parser from the handcoded grammar

Could you send me that?

> Next is extensive testing (Ok, in the name of pragmatism I wrote
> some tests prior to implementation but sadly they dont cover
> everything... ;-)

Don't forget peer review. Automated tests are not sufficient. They never
cover everything. They are there to ensure that you've got a minimum of
things working.

> Next step is getting a Ruby parser by converting parse.y to the grammar
> format of the parser gen. 

Oh. I thought you had started doing this as well. This would be a good
thing to do soon. Whatever. What I recommend is that you publish what you
have ASAP. =)

> > Actually, a strict subset of Ruby syntax, in such a way that the Ruby
> > parser class can inherit from the Ruby-- parser class.
> The Grammar class I've used supports this kind of "merging" of grammars
> (and thus of parsers).

Yippee!!! nau zat iz kewl!

(sorry for this burst of enthusiasm)

> > Basically, Ruby-- would lack at least:
> > * for, case..when
> > * flip-flop operator
> > * reversed form of if, unless, while, until
> > * multiple assignment
> > * yield (use & declarator and .call() instead)

> Why these? I guess yield and the flip-flop may not be straightforward to
> translate to C but IMHO the other ones should be possible?

It's possible that people reimplement all the features of Array#[],
Array#[]= for their own class; it's possible, but it's not funny.

Look at the amount of code that was necessary to write BitArray (sample
usage of MetaRuby). This supports most of Array's features.

I see no reason why the language itself should not have a restricted
version and a full version. The pattern is exactly the same. 

> I think excluding yield would be a major hindrance since it is
> frequently used in iterators.

Well it's not a hindrance at all for me. I just use the & declarator to
pick up the special parameter, and then perform a .call on it where i
could do yield.

> I've translated gc.c (not all of it but doing a OO design
> based on the existing stuff) so far.

This will be interesting to see.

> memory. I think it would not be natural for a Ruby developer to use
> something different than an iterator for this => yield is needed in
> RootSet implementation => yield is needed in sRuby/Ruby--.

Ok, see above. "Iterators" are a library feature. "yield" is just
sugar. As long as we have closures (and the & declarator) I don't think
we've got a problem.

> This is an example of the kind of thinking I do to try to nail down
> what needs to be in sRuby/Ruby--. 
> Ok, if we really can't find a way to
> translate yields to C code then we'll have to restrict sRuby/Ruby--. 

This is not the kind of thinking I'm doing. If we really can't find a way
to avoid translating yields directly to C code then we'll have to let it
make its way to "Ruby--".

> (links are on my RubyVM page)

What's the URL ? (ok, got it: 
http://www.ce.chalmers.se/~feldt/ruby/ideas/rubyvm/)

> The resulting objects are then translated to C directly in a
> simpler/faster form (instance varsa can be made C globals etc).

Just a small note: on nineties computers, relative addressing is as fast
as absolute addressing. Plus, you don't need globals to have absolute
addressing. You only need your object to be at a compile-time-known
location.

> > Send me a version of your parser when you're done.
> I'll do that but I've been working a bit on coding interpreter stuff 
> in Ruby for a while so it might be a couple of weeks.

Ok, send me a version of your parser now instead. =)

> BTW, do you have any ideas on the "types" of the nodes in AST? [...]

I don't have a precise idea on this yet.

> rb2c uses parse.y directly I think.

Ok

> Whats ruby.y

Actually, typo, that's parse.y

> and do you know what irb
> uses?

lib/irb/ruby-lex.rb
lib/irb/ruby-token.rb
lib/irb/slex.rb



matju