Hi,

In message "[ruby-talk:8673] Re: Visions for 2001/1.7.x development?"
    on 01/01/05, Robert Feldt <feldt / ce.chalmers.se> writes:

|>   * bytecodify interpreter
|>
|Will the byte-code interpreter subsume the existing one or will they
|co-exist?

I'm going to replace the interpreter.

|What will be the main benefits from having bytecode interpreter? 
|Speed? Drawbacks with current representation?

I think of two benefits:  a) performance b) maintainability.

  a) current interpreter based on recursion, which I think is the
     bottleneck of the performance.

  b) I worked and added features bit by bit on the interpreter for
     more than 7 years.  The implementation is now too complicated to
     maintain for the person other than me.  In case I hit by the bus,
     I'd better prepare and clean up the interpreter.

|Proprietary bytecode format or some existing one (java, amiga virtual
|processor assembly code)?

I'm going to design Ruby's own bytecode, since the intermediate code
is relatively higher level and influenced highly by the original
language.  If I choose existing one, it will probably restrict the
language somehow, for example, closures cannot be implemented by using
JVM.

|* Making interpreter (parser, byte-code generator, byte-code
|interpreter, etc) and internal structure of Ruby programs available in
|module/classes. Would make it possible with different back-ends as
|previously discussed on the list.

I hesitate it.  Once I opened internal structure, it should be fixed.
Even though I hope and believe I can design lasting language exterior
(e.g. syntax etc.), I don't think I'm wise enough to design lasting
language interior.  I'd like to save room for the future.

Of course you can touch it, like great Guy Decoux's ii extension.  But
it may change in the future.  Or I will wait till some other keen guy
presents wonderful internal design.

|* Agressive separation of different parts of the interpreter so that you
|can build a "minimal" interpreter...

I think MicroRuby is the interesting challenge.

|* Ruby-enforced (or at least supported) way to versioning of
|  scripts/extensions. Can be used both from Ruby code ("require
|  'BitVector' {VERSION >= 1.6}") and from RAA-installer ("raa-get
|  Bitvector 1.6.1"). Different versions can co-exist on my Ruby set-up.

I like the basic idea.  But I still don't have concrete strategy to
make it possible.

|* Marshaling of threads+bindings or interpreter with state. I'm not sure
|it's possible but my non-expert feeling is that it is if we have a
|portable bytecode format and "objectified" interpreter.

Well, I think this cannot be accomplished without OS's support.  Some
data OS provide are not portable (e.g. file descriptor).  But with
bytecode I think we can marshal in/out methods.

Oh, I have to mention, Ruby internal is astonishingly complex.  It
would take years to replace the interpreter, I hope I see it far
sooner, but I can't promise.

							matz.