From: Paul Prescod <paulp@...>
Date: 2001-08-12T07:54:28+09:00
Subject: [ruby-talk:19552] Re: order and freedom in Ruby (was: Re:  Re: the  way class variables work)


Chris Uzdavinis wrote:
> 
>...
> 
> I am still trying to figure out how one can write non-trivial
> applications in Ruby, since the interfaces can dynamically change, and
> you can't find out until runtime if your code has type-errors.

If you write non-trivial Ruby code you must have well-designed test
cases. But then if you write non-trivial C++ or Java code you need
well-designed test cases also. So I don't think there is really as deep
a difference as you think.

> What I don't know very well is how to recover.  Given the dynamic
> nature of Ruby, we should be able to calculate the missing types and
> add them as necessary and try again.  However, normal error-correction
> logic usually applies toward values, not types.  I don't know if this
> kind of computing has been done enough to have a satisfactory general
> solution.

I'm not sure what you mean. Dynamically typed languages are roughly as
old as statically typed languages. I guess it is roughly Lisp versus
Fortran. People have indeed built many massive systems in dynamically
typed languages. It is arguably easier than in statically typed ones.

> Since functions are objects, it seems reasonable to be able to ask a
> function object "before I call you, what requirements must my
> parameters satisfy?"
> 
> I'll give you a function:
> 
> def foo(arg)
> # stuff
> end
> 
> Now, how can I call foo such that there is no type error?  

I'll give you back a function:

float foo(int b, int c){
   return b/c;
}

How can I call foo such that there is no value error (when C is 0)? I
read the documentation for foo. I inspect the implementation of foo etc.
The problem can get even worse:

float foo(int *b, int *c){
   return *b/*c;
}

What if b has the "type" NULL instead of the type (int *)? I'll have a
type error, right? But the compiler doesn't catch it.

>...
> If foo is dynamically created, it's my code doesn't know anything
> about it.  Assuming I have to call it, if I get a TypeError exception
> how do I discover what type I should have provided?  I'm not convinced
> that there is enough information available to actually infer the type.

You seem to want to write programs that dynamically assemble pieces of
code that were not tested together and which dynamically reconfigure
until they work. I don't see how this is possible in any language! How
does Java allow it? How would Java help with the b/c problem? The only
way to write code that works with other code, in general, is to
communicate with the other author through documentation or through
reading their code or something like that.
-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook