Hi Gavin,

But how about making declaring type *optional*?  Even the referenced web
page states that "A hybrid solution where you can adapt to the problem at
hand will have the highest probability of success."

Therefore, people who want to code in the current Ruby style and syntax
can do it that way (no change to Ruby at all), while people who want to
try to make the code "run faster" (and probably need some weak type
checking) can use the optional typing.

If the concern is that optional typing will make overall Ruby slower, we
can just use a switch when running Ruby interpreter, where "ruby
-no_type_check" will run the current, established, interpreter, and other
switches will invoke a new interpreter which will have optional typing.

Finally, the "Efficient-dynlang-implementer view" in the referenced web
page states it precisely:

"DynTypes are great but cost a lot since we cannot optimize for a
certain type.  To make the task of the compiler/optimizer simpler we need
hints of the actual types.  Lets give the user a way to specify/hint on
the actual types."

Ruby already takes the good things from Perl, SmallTalk, Lisp, etc.  An
experimentation with the good things from Dylan probably will not hurt, I
guess.  Only later when the experiment is deemed successful, we can
incorporate it in the mainstream Ruby, if we (or Matz to be more
precise) choose to do so.

Regards,

Bill
============================================================================
Gavin Sinclair <gsinclair / soyabean.com.au> wrote:
> It's not a Ruby thing.  Amongst experienced Rubyists (not including myself
> here) there's a belief that static typing is limiting, and the benefits of it
> are either illusory or available through other means.  In other words, Ruby has
> a certain flavour to it, a paradigm if you will.

> There's some discussion on this at
>   http://www.rubygarden.org/ruby?DynamicVsStaticTyping
> as well as other places on the Wiki (search "static typing")