On Fri, Dec 05, 2008 at 10:29:53AM +0900, Jan Wedekind wrote:
>    Of course one could think about interpreting the code of the method 
> "plus" using ruby2ruby or obtaining a parse-tree of "plus" in some
> way. However this is not really satisfactory. According to [3] this
> does not really address the problem since this approach leads to
> an endless tower of reflective interpreters (language interpreted by
> an interpreter, which is in turn interpreted by an interpreter).

It depends on what you mean by "the problem".  If the problem is that
you want improved performance, compiling by walking the AST is
satisfactory.  This is what Ludicrous does (or in the case of YARV, by
iterating over the YARV bytecode instead).

>    I don't really know Smalltalk. But for example if "while" and "if"
> where methods, one could optimise more sophisticated Ruby programs
> by manipulating the behaviour of the Ruby VM in a particular context.
> Currently I need to write programs which are calling special methods
> which imitate loops and conditionals (also see Paul Brannan's
> ruby-libjit):
>
> def inc( p, pend, x, f )
>   f.until( proc { p == pend } ) do
>     LINT.jit_store(  LINT.jit_load( f, p ) + x, p )
>     p.inc!( LINT.size )
>   end
> end

IMO the syntax ruby-libjit uses for until is slightly less verbose:

  f.until { p == pend }. do
    ...
  end

BTW, does your jit_store method know to use insn_store_relative instead
of insn_store?

> Has this already been considered before?
> I'd be interested if there is anything related I should know about.

Yes, it's been discussed before:

[ruby-talk:38802]
[ruby-talk:168164]

It would be interesting if the if keyword were just syntactic sugar for
if_true:

  if <condition> then <body> end
  #=>
  <condition>.if_true { <body> }

or the while keyword were syntactic sugar for a while_true method:

  while <condition> do <body> end
  #=>
  proc { <condition> }.while_true { <body> }

It would be possible using RedParse or Ripper to perform this
transformation before code is executed; code in the resulting new
language could then easily run alongside existing Ruby code.

Paul