Re: Proposal: runtime-modifying Kernel methods should be keywords

Calamitas wrote:
> I was going to reply to this In a detailed manner, but I'm not. (I
> actually just deleted a lot of writings...) You speak with a certain
> vehemence that makes me interpret your words differently from how you
> intend them. The reverse is probably true too. We would keep picking
> on details, and that gets us nowhere.
> 
> I understand your vigor though; JRuby is your brain child, you've
> lived and breathed it for quite a while now. I know how it feels. I'm
> impressed with what you are doing; what I thought you did has gone
> from generating Java source code to actually working right on top of
> the JVM and exploiting the HotSpot compiler and all. I actually envy
> you a little.

Feel free to contribute :) I wouldn't mind a few more eyes on the 
compiler design. Before this project I knew nothing about implementing a 
language. Before this past February I knew nothing about compiler 
design. Before a couple months ago I knew nothing about optimizing code 
for the HotSpot JVM. With your help I'm sure I'll have new things to 
know nothing about. And that's a Very Good Thing.

> What you could do in the short term is provide a compiler switch that
> makes JRuby stricter to allow more optimizations. That should be
> pretty easy to do. But rather than making eval and all keywords, you
> could simply disallow aliasing them. This is much less restrictive,
> and it does solve your problem because the built-in eval can only be
> called eval so you can safely detect its presence. This means you'll
> have some false positives, but that's OK, and programmers can avoid
> this by not using eval as a method name, but then it's the
> programmer's choice. Not being able to alias eval feels much less of a
> problem to me, especially if you can distinguish between aliasing the
> built-in eval and a user-defined eval. It's not ideal, but at least
> you can keep on going.

This is the path I'm likely to take in the short term, as well as for 
the other troublesome methods. It also sounds like the IronRuby team is 
doing this. But I'm certainly not going to run away from a 
challenge...I'm continuing to work on improving the entire call chain 
and reducing the overhead of heap-based framing and scoping to as great 
a degree as possible.

- Charlie