On 5/31/05, gabriele renzi <surrender_it / remove-yahoo.it> wrote:
> Austin Ziegler ha scritto:
>>> Type Inferencing is still almost impossible for far to many
>>> situations and this will not change because it is fundamental
>>> problem.
>> Mmm. I'm not sure that I agree. Part of what I'm thinking here
>> has to do with what Microsoft has done with the .NET platform and
>> Java has done with Hotspot compiling. Programs are shipped as
>> MSIL. There is then an initial compile phase of the MSIL to
>> processor-specific *optimized* instructions. An implementation of
>> Ruby 2.0 could do something similar, where long-running programs,
>> or programs that are run often, have cached compiled versions of
>> code that are based on type inferencing.
> Sorry, but If I recall correctly MSIL brings explicit type
> informations, so that is not the same thing. The runtime inference
> may happen, at least in HotSpot, when you are doing stuff like
> using boxed structures and the JIT can transform them in a native
> array once it figures they will hold integers.

Mmmm. Not really. See my rather pointed post to Caleb. Self managed
this as an dynamically typed language. HotSpot is based on Self's
VM. Self would reoptimize based on cache and analysis. That's all
I'm saying would have to happen here, in Ruby. Easy? Not at all. But
a lot easier than changing the very nature of Ruby into something it
isn't.

HotSpot, as I understand it, took *longer* to get working right
because it now had to work on a statically typed language.

Additionally, the example of MSIL is just that: an example. It's an
intermediate step that results in an optimized binary.

(And, really, it's not anything like #method_missing that makes Ruby
a hard language to optimize; it's #eval. The reality is that even
things like #method_missing can be optimized because they will be
called in a predictable way in most programs.)

> But some informations can't be inferred that easily. Think for
> example of the information about an object representing a
> 32bit/nativesize integer. We will always pay the penalty due to
> the need to consider that it could, at any moment, become a
> Bignum, even if there is a guarantee that this will never happen.

Mmmm. Disagree. You only pay the penalty when you make the switch,
just as you do now in Ruby. Again, see the response to Caleb which
points out Self's optimization.

> (not that I care too much about performance, but I still think
> optional typing is great for documentation)

If it's made in a documentation format. That's my whole point --
typing as documentation is good. Anything else is bad.

-austin
-- 
Austin Ziegler * halostatue / gmail.com
               * Alternate: austin / halostatue.ca