[ruby-talk:19559] Re: order and freedom in Ruby (was: Re: Re: the way class variables work)

Paul Prescod <[e-mail]> writes:

> 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.

Dynamic typing is only a tangent to what I'm talking about.

I'm asking how to deal with dynamic mutation of behavior, the dynamic
addition and removal of methods from objects.  The dynamic
changing-the-meaning-of-a-function-call.

Dynamic typing deals with type RESOLUTION.

I'm talking about behavior and type MUTATION.

> > 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)?

Your question is a diversion.  I'm not asking how to force an errones
call to succeed.  I'm asking how, given a function (whose behavior may
change from one call to the next) I can determine what needs to be
passed in in order to produce a valid call.

The answer to your question is to call foo when c is not zero.
Otherwise you're simply asking a loaded question.  Your foo has a bug,
and that is the implementor's responsibility.

The situation I'm talking about is the CALLER's problem, not the
function implementor's problem.

> 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;
> }

So your foo requires that its arguments be non-null pointers-to-int,
with c being a pointer to a non-zero integral value.

Once that is established, that doesn't changed.  It's compiled code,
and foos implementation doesn't change.  Once you know the
restrictions on how it works, you can write code that works within
those restrictions.

Ruby's dynamic method mutation capabilities, means that all bets are
off.  I could be calling completely different functions from one
invocation to the next, it can have changing requirements.  Heck, it
can have requirements that are unique every time the program is run.

I might THINK I know what it does, but I can never know.  I just have
to hope that no code has actually changed the meaning out from under
my feet.

> 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.

Huh?  NULL is a value, not a type.


> > 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.

It's an idea.  Considering that Ruby programs are capable of
dynamically changing, I'm just thinking about dynamic adaptions to
that change.  I think it's interesting to think about.

Also, you seem to be convinced that testing is sufficient.  Unless
your tests show 100% coverage of every line of every file that your
Ruby program uses, you don't know if one of those untested lines may
change your environemnt and break your code.  Further, even 100%
coverage doesn't really mean much, since it could be a series of
calls, or only particular values of certain function calls, which
trigger the kinds of change that can be destructive.

Finally, I'm thinking about a call to eval, which opens up the world
to unknown code.  (I know about safe-levels of ruby, and tainted
objects, but that's a band aid, not a real solution.)

There is no amount of testing that can prove correctness over
dynamically changing problems.

> 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.

I think you're missing my point entirely.

-- 
Chris