From: Eric Mahurin <eric_mahurin@...>
Date: 2005-10-04T22:35:02+09:00
Subject: Re: Type inference

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

> On 10/3/05, Eric Mahurin <eric_mahurin@yahoo.com> wrote:
> > --- "David A. Black" <dblack@wobblini.net> wrote:
> > > On Tue, 4 Oct 2005, Eric Mahurin wrote:
> > > > To take advantage of type (really class) inference in
> an
> > > > optimal way, you'd need to know that the methods aren't
> > > > changing.
> > >
> > > What about type (really type) inference? :-)  There have
> been
> > > some interesting projects looking at the matter of
> checking types
> > > in Ruby (not based on class/module membership), including
> one by
> > > Eivind and I think one by Florian Gross.  It's not
> easy... but anything
> > > less is, I think inevitably and almost by definition,
> going to reduce
> > > what one can do in Ruby.
> >
> > Maybe I misunderstood what Eivind was asking for.  From the
> > last message it sounded like he was asking for the
> > interpreter/comilier/VM to try to infer what the class was
> for
> > the object of some variable.
> 
> Not class.  What is possible is to infer the binding of
> certain
> messages (method calls).  The "Class" concept in Ruby sort of
> isn't
> classes, more a way to launch an object with a predefined set
> of
> method bindings.

"class" is still closer to what you are talking about than the
ruby definition of "type" I've seen running around.  The one
I've seen is basically analogous to interfaces in Java, but
includes all methods.  For example IO and StringIO could be
considered the same "type".  I don't think that kind of "type"
inference does any good for improving performance (the methods
for IO and StringIO are completely independent).

For ruby, I'd still say class is close enough.  And if an
object changes it's meta class (initially the normal class),
that meta/singleton class should be treated as it's class for
"class" inference purposes.

> > The reason for doing this would be  to transform something
> dynamically typed (all ruby
> > variables) to something statically typed.  I think this is
> the
> > critical thing needed in dynamically typed languages to
> give
> > performance that approaches statically typed languages.
> 
> Not really.  It's possible to do this at run-time, and that's
> easier
> than doing it at "compile time".  The combination result in
> the
> fastest code, of course.

I didn't say it needed to be done at compile-time.  This
transformation can be done at compile-time or run-time.

I think that having to allow for methods of objects to change
(either by changing class methods or meta class methods) after
this transformation is done becomes problematic.  The ideal
situation for this type of optimization would be all methods
are immutable once an object comes to life.  You could still
make a clone of an object with a changed method, but not
directly change the method of an existing object.

> > I don't know of any dynamically typed languages that have
> been
> > able to do this yet, but I think it is the next threshold.
> > Maybe the "self" language has, but I still haven't found
> any
> > benchmarks for it.
> 
> This reference:
> http://research.sun.com/self/papers/chambers-thesis/t1.ps.Z
> indicate 1/3 to 1/2 the speed of optimized C (for standard
> cross-language benchmarks.)
> 
> That meshes with the claims here:
> http://research.sun.com/self/compiler.html
> 
> I have not seen any specific benchmark numbers.

This chapter has benchmarks:

http://research.sun.com/self/papers/chambers-thesis/t14.ps.Z

Performance ranges from 22% to 65% of optimized C.  Compare
that to ruby - from about 0.25% to 10% of C (language
shootout).  Seems like somebody should try implementing ruby in
the self virtual machine.  I read somewhere that smalltalk was
implemented on this VM, so why not ruby?  ruby got many of its
features from smalltalk, right?

> > It sounds like you are talking about type checking not
> class
> > inference.
> 
> These are (or can be, at least) aspects of the same thing. 
> Inference
> of the binding for messages (methods) let us do static
> inference of
> the real types (not classes) involved, and can give early
> warnings,
> like "That method call is going to result in an uncaught
> NoMethodError" or "That code branch will never ever be
> called".

Again it depends on what your definition of "type" is.  If your
method checks to make sure that an argument responds to all
that is needed (psuedo checking the "duck-type"), I don't think
that helps the type (exact method bindings) inference problem. 
If it checks for a specific class, that would trivialize this
inference.

> > I don't see a whole lot of use for specifying
> > something in the code to show the duck typing you are using
> for
> > various arguments in a method.  Maybe having rdoc scan the
> code
> > to see what methods the arguments are using would be useful
> > (somehow format this info in the generated docs).  This
> would
> > not be a trivial thing and I'm even sure how you would
> > completely describe the duck-type (I know you hate that
> term)
> > of an argument.
> 
> You cannot completely describe the duck-type of an argument
> in the general case.

I could see that since it is so recursive.  But, you may if you
limit the depth.



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