From: Joshua Ballanco <jballanc@...>
Date: 2010-09-30T03:10:22+09:00
Subject: [ruby-core:32638] Re: Proposal for Optional Static Typing for Ruby

On Sep 29, 2010, at 6:03 AM, Bill Kelly wrote:

> But consider Float, which is the same type as the JVM's double.
> 
> Ruby floats are allocated on Ruby's heap, just like ordinary
> objects.  And Float methods like :+, :*, etc., go through
> dynamic method dispatch.
> 
> By contrast, if types are known at compile time, it is common to
> generate code that neither allocates floats on the heap, nor
> performs dynamic dispatch on method calls, but rather generates
> native machine instructions to add, multiply, etc. (or, in this
> case, generates JVM opcodes which can be JIT'd to native
> instructions.)

Ah-ha! I think you have made my point for me (better than I have, apparently). Specifically, this part:

> "if types are known at compile time"

Yes, yes! A hundred times yes! This is really the key to the puzzle. However, type annotations are NOT the only way to achieve this goal. They are a quick, lazy way to achieve this goal, but it makes your code ugly and your programmers unhappy. Consider OCaml:

---
# let rec fact x = 
    if x == 0 then
      1
    else 
      x * fact (x - 1)
    ;; 
val fact : int -> int = <fun>
---

See that? OCaml knew that factorial should be a function that takes an int and returns an int, yet nowhere in the definition of the factorial function did I ever indicate that "x" should be an int. How'd it do that? Easy...OCaml has the ability to *reason about the code* that you write.

I guess I should clarify a bit:
-- I, too, would like it if Ruby could warn me when I pass the wrong thing to a method
-- I don't want to have to annotate types. Ruby should do this for me automatically
-- The real problem is that Ruby is "too open" to be able to infer types in advance
-- We should fix the root problem, not apply a band-aid like type annotations

Cheers,

Josh