[ruby-core:32641] Re: Proposal for Optional Static Typing for Ruby

On Wed, Sep 29, 2010 at 8:03 AM, Bill Kelly <[e-mail]> wrote:
> As an aside -- it's been pointed out to me on occasion that
> dynamic languages don't theoretically have to be slow; that one
> could conceivably perform sophisticated run-time analysis and
> optimize certain dynamic code paths to native instructions.
>
> But in practical terms, if types are known at compile time,
> generation of efficient native code is a well understood
> problem.

This is the crux of the problem. Ruby is dynamic to a great enough
extent that global optimization is not always possible (or at least
not feasible) since anything, anywhere in the system can change. Not
only can new types be introduced, but existing types can be modified,
and even individual objects only give soft guarantees about what type
they are (singletonizing an object is almost a limited "become" from
Smalltalk, and defeats most dynamic optimizations completely).

And the unfortunate truth is that those features which make Ruby hard
to optimize are also some of the nicest features. I use them myself,
knowing that no implementation can cope with them perfectly.

Static types would be nice for some specific domains, like if users
want to "opt out" of Ruby's numeric overflow and mutable types to get
the fastest-possible numeric algorithm performance. For other domains
like data-structure manipulation (tree-walking, searching, etc) it
would help less but still be useful to know exactly what types were
being walked and remove some of the dynamic call overhead.

We have frequently considered experimenting with optional static types
in JRuby. The work on Mirah was not only to build another
language...it was also experimentation with doing type inference and
static typing with Ruby's code structure. It would not take much work
at all to allow localized static types in JRuby, but of course we
understand how "forky" that would seem. We have to weigh the "forky"
issue with the fact that sometimes people really do want native math
performance, and they might just leave Ruby to get it.

On structural typing:

Structural typing only gets you one dimension of typing if the
structural types aren't themselves statically specified. For example:

def foo(a: #blah)
  x = a.blah
  x.to_s
end

Perhaps this gets you the duck typing you want, but you still can't
reason about types here in any meaningful way. What type, structural
or otherwise, does blah return? If you don't know that, x.to_s can't
be structurally typed, nor can the return value of the method. What is
the arity of #blah? What argument types does it expect? It becomes a
big mess. You could specify structural types outside of the method:

type Blahful
  def blah: Fixnum
end

def foo(a:Blahful)
  x = a.blah # x can be proven to be a Fixnum
  x.to_s # known to be Fixnum#to_s
end

And this brings it closer to Mirah (which doesn't have structural
typing, but probably will soon). But you still have Ruby's
late-binding of *constants* to contend with, along with mutable types.
What is "Fixnum"? Perhaps it's going to be MyLibrary::Fixnum? And even
if it is Fixnum, what's to_s? Has it been changed or decorated?

Any static typing system added to Ruby must necessarily make
assumptions (or force restrictions) on the user's code. If you
specified something like:

def foo(a:Fixnum)

In my vision for JRuby static typing this would assume that "Fixnum"
at the time of method definition is the only Fixnum type this method
will accept, and the methods Fixnum has at that point are the ones
this method should be compiled against. Further, if you specify a
return type:

def foo(a:Fixnum):Fixnum

Then any return value must be Fixnum, which could allow you to
eliminate the Bignum overflow checks. Again, another limitation. But
perhaps people are willing to accept limitations to get better
performance in limited areas.

- Charlie