From: Mark Hubbart <discordantus@...>
Date: 2005-01-29T05:58:07+09:00
Subject: Re: Type Inference

On Sat, 29 Jan 2005 05:36:20 +0900, Alexander Kellett
<ruby-lists@lypanov.net> wrote:
> On Jan 28, 2005, at 9:26 PM, Mark Hubbart wrote:
> > These are  just a few examples, mostly attempting to be on the extreme
> > side. But they show a few possible problems with checking types,
> > especially based on method signatures, at compile time.
> 
> i very much doubt that these corner cases will really
> play much in the real world. if something is ambiguous
> and the static type checking/introspection is really
> needed, then the inferencer can just as well warn the
> programmer of this. a baby inferencer would basically
> warn all the time, until eventually it would work.

So you are suggesting that the runtime keeps track of state between
runs? Are you thinking that this will only be used during test runs,
and won't be used when the end user runs the code?

> an interesting way to test case this would be to have
> runtime tracing report on typing during execution, and
> run the inferencer against the output of this, whenever
> something has a mismatch, the test fails.

Don't discount these cases just because they are edge cases. They are
simply shorter versions of things that are actually used. When
metaprogramming, it is common to define methods on the fly using
define_method and a string, or by using method_missing, or by adding a
singleton method. For example, an xml generation lib could take an xml
schema and create an object that refers to that schema to create it's
own methods. And I suspect that most Ruby programmers would consider
that an acceptable way of doing it. But the dynamic nature of it would
likely cause difficulties when attempting to determine what methods
that object would respond to. And that's not an edge case, that's a
real life one.

Perhaps the greatest strength of Ruby is the fact that so much can
happen at runtime. Things that you *can't* detect at compile time.
Things like dynamic definition and redefinition of methods, dynamic
code loading, etc. These will make it difficult, if impossible, to
raise meaningful errors at compile time, *ever*. Any code that
requires a library, or has an eval statement, must be suspected as
having added, removed, or changed some methods -  and so errors can't
be raised.

cheers,
Mark