--- Eivind Eklund <eeklund / gmail.com> wrote:

> On 10/3/05, Tanner Burson <tanner.burson / gmail.com> wrote:
> > On 10/3/05, Eivind Eklund <eeklund / gmail.com> wrote:
> > > If you don't, please stop scaring people - we want them
> to go
> > > implement type inference for Ruby :)
> >
> > 'We' do?
> 
> Yes, "we" do.  As in the Ruby community.  And I'm willing to
> be that
> presumptious because I happen to have spent time looking into
> how this
> can function as an enabling technology for both the
> possibility to
> compile Ruby (though I don't think that that should be to
> C++),  for
> static analysis, and possibly for better introspection.  I'm
> somewhat
> uncertain about the latter, because there are cases where the
> types
> cannot be inferred perfectly (perfect inference of types in
> Ruby is a
> reformulation of the halting problem).  There are immediate
> speedups
> possible from type inference, even with an interpreter: We
> could lose
> dynamic dispatch for most cases "under the hood" - we would
> still have
> duck typing, it's just that the interpretation would go
> faster (it
> would probably be necessary with a prescanning step, though,
> as the
> inference can take time.)
> 
> I think there might be more uses, too - though the above is
> more than
> enough to make this important.

I kind of talked about this before in a previous thread:

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/5563

To take advantage of type (really class) inference in an
optimal way, you'd need to know that the methods aren't
changing.  There may be some very difficult ways to handle
changing methods, but you will burn performance (runtime and/or
memory).  I was basically proposing that there be a way to
freeze methods and prevent certain methods from being
overridden (java: final, c++: non-virtual).  All of those
methods would have good optimization potential.



		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com