From: Mathieu Bouchard Date: 2001-02-20T03:06:47+09:00 Subject: [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