[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: dynamic vs. static typing



On Wed, 26 Nov 2003, Anton van Straaten wrote:
>
> Perhaps this would be a good time for Shriram to expand on an earlier
> comment he made (on Tue 11/18/2003 at 4:58 PM):
>
> > type systems that work by inference, rather than annotation
> > checking, often do not explicitly "check".  This phenomenon
> > is why they sometimes provide incomprehensible type errors.
> > (I can explain this in a bit more detail if anyone cares.)
>
> I understand the general principle that the more abstract a piece of code
> is, the harder it becomes to produce errors (and other information) that are
> meaningful to the domain to which the code is being applied.  Is there
> anything more specific at work in the type inferencing case that makes more
> meaningful errors more difficult (or impossible)?

I can answer that one, at least in part. Since type inferencing systems
essentially trace through your code to figure out what types are returned
where, you can run into the case where the type inferencing engine has
determined that a type error's happened because of code that's eight or 10
levels deep (potentially in other source modules) and not immediately
obvious. For example:

  Foo a_var;
  a_var = some_function(x, y);

might throw a type error *only* if x and y are both integers if the engine
is clever enough to detect code paths that can only be taken based on the
types of the parameters. And x and y may only be integers (or only
*definitely* integers) based on some set of source circumstances. (Usually
ones that don't occur when you throw in debugging statements, I expect)
Using a signature-based dispatch system's the easiest way to do this, but
if the inferencing system's clever enough and there are sufficiently
specific primitives available to make analysis possible I can see ways to
do it without needing signature dispatching.

Try explaining the error, though--you're not likely to get "type error --
you did integer math on X four functions and two source modules ago" so
the source of the types causing the errors can be difficult to track down.


					Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                      teddy bears get drunk