On Fri, 5 Jan 2001, Yukihiro Matsumoto wrote: > Hi, > Hi and thanks for taking time to answer. > Sevaral major things I hope to have in 1.7 are: > > * keyword argumant as in Python > Yummy, this is a nice one... I currently fake it with hashes but its awkward. > * M17N > * generational GC (patch is already available) > * bytecodify interpreter > Will the byte-code interpreter subsume the existing one or will they co-exist? What will be the main benefits from having bytecode interpreter? Speed? Drawbacks with current representation? Proprietary bytecode format or some existing one (java, amiga virtual processor assembly code)? > First two would have noticeable changes, but hopefully in the upward > compatible manner. The latter two would have no change in behavior. > In general, 1.7/1.8 would be mostly upward compatible changes, unlike > Perl6. > Thanks for making this clear. > About minor changes, I haven't decided about most of them (yet most of > my ideas listed in ToDo list). It's up to you (i.e. community). > Let's discuss what you want to see in the future. > The Ruby additions I'd value the most (most of it from previous discussions on ruby-talk): * 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'd like endless possibilities on analysing Ruby code and generating different "stuff" from it... ;-) Overriding methods in an interpreter object would allow me to build a fully secure sandbox... (?) * Agressive separation of different parts of the interpreter so that you can build a "minimal" interpreter that doesn't even include the "base library" (pickaxe book pp. 189: Array, Bignum, ...) but loads them dynamically when needed. This would be a good thing for running Ruby on "small" platforms like Palm, WindowsCe, cell phones etc and for wrapping/freezing/compiling small stand-alone programs. This looks a bit difficult with current source since there is a rather tight coupling between intepreter, language core and base lib (but I'm no expert here). So basically when the interpreter sees the first use of an array it would "require 'Array'" automatically. I'd like to run Ruby everywhere, even on my wristwatch... :-) * 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 want things to work in spite of new/uncompatible versions... * 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. I want to extend my Ruby distributed execution environment (rudee) with dynamic load-balancing and use Internet as one giant super-computer... ;-) Regards, Robert