From: shang@corp.mot.com
Newsgroups: comp.lang.c++
Date: 17 Jul 92 18:02 MDT
Subject: Re: run-time type checking (was: Re: Co
Nf-ID: #R:BrG239.7oA@apollo.hp.com:-396143030:1992Jul17.140200.15575@cadsun.co:-1066702630:001:3004
Nf-From: corp.mot.com!shang    Jul 17 18:02:00 1992


In article <TMB.92Jul16223822@arolla.idiap.ch> tmb@arolla.idiap.ch (Thomas M.  
Breuel) writes:
> 
> Frankly, I don't see why the language should make more effort to have
> built-in support for dynamic typing (a feature that most people use
> relatively rarely) before it has built-in support for arrays (meaning,
> array bounds checking and multidimensional arrays).
>

The language should provide run time type checking as well as array bounds  
checking. You can also have a switch to turn off them if you like to.
  
>    > The language cannot prevent "accidents"
>    > while still allowing valid uses.
> 
>    The current C++ can't.
> 
> Actually, no language that uses dynamic typing (as you suggest) to
> implement heterogeneous collections can "prevent 'accidents' while
> still allowing valid uses".  It is in the nature of dynamic typing
> that runtime type errors can occur (although they need not lead to the
> catastrophic consequences they leed to in C++).
>

The run time type checking that I suggested is different from those applied in  
dynamic typing languages where a type error is caught at run time. My proposal  
is specially made for strongly typed language (any type error should be caught  
at compile time ). There is no automatic run time type check. Programmers are  
responsible to write the run time type check code when they try to do something  
which usually violates the conventional static type system, for example, they  
try to use type downcast. The explicit run time type check will enssure that  
run time type error will NEVER happen, while this can be checked at compile  
time through type inference.
 
> SML in my opinion solves the problem more satisfactorily than either
> Lisp or C++: it forces you to make sure that you have at least thought
> about all the different cases of types that may occur when you build
> heterogeneous collections. It does this by requiring you to declare
> tagged union types for the objects that can occur in a heterogeneous
> collection, and by warning you if not all the possible type cases of a
> union type are handled.
> 

This is also incorporated in my proposal, though I did not memtioned. Take an  
example of class Number and its operator+, x+y may return an object of either  
type of x (thisclass) or type of y. Therefore, the operator+ should be defined  
as <Number InputType> Number{thisclass,InputType} operator+(InputType y); The  
output type is a union type tagged with Number and a list of possible type  
cases, i.e. Number{thisclass,InputType}. 

> This is not quite as general as what Lisp provides, but the
> differences are only important when new datatypes can be created after
> the program has been started (which is not a problem in C++, since C++
> development is non-incremental). Furthermore, providing Lisp-style
> dynamic typing breaks encapsulation and abstraction, which you may or
> may not care about.
>

I never advocate Lisp-style dynamic typing for strongly typed languages.

David.