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.

> 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 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.

> 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".

> 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've experimented with an implementation for fairly free form
description, and I've written an approx 10 page paper with a taxonomy
of various ways of changing "things around types" in Ruby.  That's
unfortunately been lying dormant for a year or so - it just lack final
editing to be possible to release as an overview paper.

My experimentation indicated that the use of type declarations inside
normal Ruby code was just in the way during programming, at least the
ways I tried out (programming alone over a fairly short time period.)

The analysis I ended up with in the paper shows some cases where
declaration may be useful anyway, especially at the edge of modules,
used as communication tool between programmers.  There's also a
suggestion for a new way to use this; one of the reasons it's delayed
is that I'd like to do a test implementation of that, too, and have
been too bogged down in Perl at work to do more work on this.

Eivind.