Mike Gold wrote:
> Tony Arcieri wrote:
>   
>> Once you have the Ruby parser's sexps, the same class of transformations 
>> are still available, as they are in any language which allows you to
>> programatically retrieve parser output and invoke the compiler from 
>> within the language itself.
>>     
> [snipped]
> How
> will you relate the sexps to the running code?  If someone gives you a
> Method instance, how will you find its sexp?

That's solvable -- easy enough just to add an instance method to Method 
objects. After all, we already have things like #arity, on Method and on 
Proc objects.

> Or if your sexp says how
> Foo.bar was defined, how do you know the definition has not changed
> during run-time?

Of course you don't. How do you know this hasn't happened in Lisp?

That's like insisting that we can know that

class Foo
  def bar
    ...
  end
end

hasn't changed. Of course it can:

Foo.send :remove_method, :bar

> Or when you are inside a method, how can you get the
> sexps of the argument expressions before they were passed?
>   

Ah, that would be trickier, and depends very much on how much order of 
execution is allowed to change.

I see no reason to believe it wouldn't be possible with a slight 
departure from current Ruby syntax -- as an alternate way to accept 
arguments. The question is whether that's worth the potential confusion 
-- after all, we can already get explicit lazy evaluation easily enough 
by passing a block instead of arguments.

For example, it's possible to imagine a construct like this:

if foo(a = b)
  # do something with a
end

If a method is allowed to lazily evaluate its arguments -- or not 
evaluate them at all -- I can't count on 'a' being set, there, if 'foo' 
decides to do something strange. I'm guessing this kind of thing 
wouldn't come up much in practice, but I'm not sure.