On Monday, April 29, 2002, at 01:44  PM, Avi Bryant wrote:

> The second has to do with reification.  Everything (and I mean
> *everything*) in Smalltalk can be accessed and manipulated as
> Smalltalk objects.  The particular instance of this that was useful to
> me was the ability to manipulate stack frames: Seaside requires a
> particular variant of call/cc to do some cool but necessary magic (of
> which, more perhaps later).  Now, Smalltalk doesn't even have call/cc,
> in general, but I was able to implement it in about 10 lines of
> Smalltalk code because the stack was directly manipulatable.  If I
> were doing the same thing in Ruby I would have to write a fairly
> complex C module instead.  It's a little easier in Smalltalk because
> so much of the core is directly written in Smalltalk itself (including
> the compiler, standard library, development environment, etc), but I
> strongly recommend that as much of Ruby's internals be exposed as Ruby
> objects as possible.  Robert Feldt and the RubyVM folk have of course
> done some work in this direction, but I would be very happy to see it
> made more of a priority.

I too would like to see Ruby head in this direction.

Moving to a bytecode interpreter would likely make this somewhat easier, 
but even the current parse-tree interpreter could probably expose it's 
inner workings fairly cleanly. I did some poking around with an eye 
toward implementing the call/cc variant Avi talks about above, and it 
seems to me that the internal structure is fairly "objecty" already.

Of course, I don't have enough intimacy with the source to know what the 
gotcha's are. Would any one with more knowledge care to comment on the 
issues involved with creating classes along the lines of Continuation or 
Binding that wrap, say, scopes, or the stack?

Cheers,

Colin

Colin Putney
Whistler.com