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

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

Steve Dekorte wrote:
> On Nov 20, 2003, at 6:29 PM, Ken Shan wrote:
> > Indeed, in a system like Smalltalk, there is no such thing as a compile
> > time type error.
> So we can't have the functionality of forward without serious problems
> for ST?

No, I think the conclusion is that Smalltalk itself doesn't provide very
good ST support.  :)

If you want to implement something like 'forward' in an ST language, you can
do it with an infrastructure that supports dynamic operations.  I gave an
example of this re C++ and COM - a very real world example with thousands of
applications that exploit it.  Ken Shan referred to a similar thing when he
said "implementing respondsToX (for all X at once) on top of a statically
typed encoding of object orientation."

Pierce discusses the issue briefly in TAPL, in Chapter 11, "Simple
Extensions", which deals with extending the simply typed lambda calculus
with "familiar features that have straightforward treatment at the level of
typing".  Dealing with "data whose type cannot be determined at compile
time" is counted as one of those features.

> It seems all the types in the system would have to be declared to
> respond to all methods, in which case, they tell us nothing and
> there is no such thing as a compile time type error.

That assumes there are no circumstances in which you might wish to perform a
statically typed operation.  In a dynamic system built on top of an ST
system, you can have a choice - for example, by providing a distinct
mechanism for dynamic dispatch.  There's nothing to prevent you from having
a dynamic system which reflects the entire underlying static system.  But
you can still have static typing for situations which in which sufficient
information is available - which, in any real program, are much more
plentiful than you might think.

These examples have been moving progressively away from performing some
useful task, in the direction of finding extreme situations in which no
static typing is possible.  They haven't quite succeeded at that, but
they're getting about as close as it is reasonable to get, if not closer.
The underlying question seems to be "can I construct a scenario in which
static typing is difficult".  Of course, the answer is yes.  But does this
tell us anything useful?  It doesn't say anything about expressiveness, for
example, since the problems haven't been phrased in a way that permit
alternative solutions which might prove equally expressive, but which are
more compatible with static typing.