Re: the forward method [dynamic vs. static typing]

[Steve Dekorte <address@hidden>]

On Nov 25, 2003, at 11:55 PM, Anton van Straaten wrote:
>> 1. forwarding is a very flexible and powerful mechanism
>
> For what purposes?  You haven't made any case for it yet.

Ah, every conversation I've ever had with a ST-er has always involved 
them scratching their head at some point and saying "but why would you 
want to do that?". :-) I'd suggest looking into how much easier it is 
to implement distributed objects in a language with forwarding. Either 
the language supports it, or you end up implementing a runtime on top 
of the language that supports it (which is a big mess). Which reminds 
me of Greenspun's Tenth Rule of Programming:

"any sufficiently complicated C or Fortran program contains an ad hoc 
informally-specified bug-ridden slow implementation of half of Common 
Lisp."

Which in our case might be:

"any sufficiently complicated program written in a static system 
contains an ad hoc informally-specified bug-ridden slow implementation 
of half of a dynamic system"

>> 2. you agree that a type system is useless with forwarding
>
>  it's possible to have
> certain kinds of objects which support forwarding and others which 
> don't.
> In previous posts, I described approaches in languages like C++ that
> actually do that sort of thing in practice.

Are you saying C++ supports forwarding? Btw, I don't mean "can it be 
implemented?". This isn't a question of Turing completeness. The 
question is if it's a natural part of the language. For example, C++ 
doesn't even compile the method names into the executable, so 
forwarding is impossible at the level of native C++ message calls.

> In a higher-level language than C++, static type analysis could be 
> used to
> detect messages that are likely to need to be handled by forwarding, 
> and an
> IDE could flag them as such, perhaps with a color.  For example, the
> DrScheme IDE flags undefined variables in red, even though Scheme is
> sufficiently dynamic that it cannot normally be sure that a variable is
> undefined until it is accessed at runtime.  This can help a developer 
> notice
> issues while editing code, and decide whether any action needs to be 
> taken.
> What's the downside here?  Is it (a) impossible, (b) not important, 
> (c) too
> ambitious for insufficient payoff, (d) other?

The more dynamic the system, the fewer assumptions you can make at 
compile time and the less useful compile-time checks become. (for 
example, in systems where any object can forward messages, all compile 
time bets are off)

  The more static the system, the more assumptions you can make at 
compile time and the more useful compile-time checks become.

So the two are a bit at odds. Now the problem for real-world 
programming is how to build good systems quickly and easily. Does the 
ideal system lean heavily or completely toward static or dynamic 
systems or off in some other direction entirely?

If it's extremely dynamic, then your (a) is true. If it's heavily 
dynamic, then your (b) and/or (c) is true. If the ideal is off in some 
other direction then your (d) is true.

Without good empirical data, we don't know what the ideal system is so 
doesn't seem prudent to dismiss either position (even in it's extreme) 
as simply the result of ignorance or capriciousness (as was done in the 
post that started this thread).

Btw, I'm not entirely against the notion of any form of type checking. 
I just suspect that the ideal system is highly dynamic and so ST is 
unlikely to contribute enough to be worth focusing on at this point.

I'd guess the reason it's still given so much attention has to do with 
the fact that historically, weakly typed systems preceded strongly 
typed ones. Static typing is extremely useful in weakly typed systems 
as a type error that writes on the wrong memory can result in very 
difficult to trace bugs. It seems to be unconsciously assumed that this 
value extends to strongly typed systems despite the fact that strong 
typing eliminates this class of problems.

-- Steve