"Robert Klemme" <bob.news / gmx.net> wrote in message news:<2gs1pcF65u2uU1 / uni-berlin.de>...
> I guess due to the nature of Ruby it's impossible to check this without
> actually executing the code because of Ruby's dynamic typing.
>
> If you want compile time type safety you need to use a statically typed
> language.  Both types of programming languages have their pros and cons -
> but you can't get both at the same time.

This isn't strictly true.

The important thing to notice here is the difference between type
declarations and type inferrence.  Few non-functional languages have
type inferrence, so most people who haven't used functional languages
don't realize that there *is* a difference.

Type inferrence relies not on type declarations, but on the compiler
(or run time system) to determine types based on how objects or data
is being used.  Interpreters can also do type inferrence checking, and
there isn't anything stopping Ruby from doing it, either.  Keep in
mind that I'm not recommending that Ruby do inferrence type checking
all the time -- just when the user calls Ruby with the "-c" argument. 
I've also said numerous times that Ruby won't be able to check all
types because of it's self-modifyable nature, but it could probably
cover the majority of cases.

In fact, I'm of the opinion that type inferrence dove-tails nicely
with duck-typing.  Of course, this idea may not fly with Matz; he's
indicated that he thinks the idea is a bit of a turkey.  Still, if we
had type inferrence, we could kill two birds with one stone: Ruby
would have a stronger, more "proveable" type system, and we'd satisfy
some of the strong typing proponents in the group.  I don't want to be
pigeon-holed as a feature-whiner, but I quail at the idea of
implementing this.

I keep thinking that if I push the idea too hard, I'll be tarred and
feathered.

--- SER