matz / ruby-lang.org (Yukihiro Matsumoto) wrote in message news:<1084872320.683534.4537.nullmailer / picachu.netlab.jp>...
> I buy the flexibility from dynamic typing at the cost of compile-time
> type check.  I don't think I am going to change my mind.

I want to make sure we're all on the same page.

My proposed solution is to have Ruby do a duck-typing check as part of
the syntax checker ("-c").  This would be duck-type inferrence, so it
doesn't require the programmer to declare variables or give them
types.  It would simply raise a warning if someone tries to call
"5.collect".  That is, ruby will load the parse tree as it does with
-c, and then check to make sure that method calls are consistant with
expected duck types.  It would issue warnings where it can, but
remember -- this is a debugging/development tool, not a runtime tool. 
I don't want Ruby doing this sort of type checking all the time.

I'd like to clarify that I'm in total agreement with Ben's comments,
especially in

http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&threadm=64FDC9A2-A9C4-11D8-A38F-000A95676A62%40pragprog.com&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26group%3Dcomp.lang.ruby
http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&threadm=64FDC9A2-A9C4-11D8-A38F-000A95676A62%40pragprog.com&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26group%3Dcomp.lang.ruby

regarding the ability to catch classes of errors *outside* of running
code.  "-c" catches one class: syntax errors.  Another class of error
is type errors that can be caught with type inferrence.  Another class
is variable typo warnings like Ben's example.

--- SER