Re: Combining dynamic and static typing

[eachus@spectre.mitre.org (Robert I. Eachus)]

In article <E4G92y.1CD@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:

  > Dynamic and static typing both seem to have their place. Devotees
  > of the former extol the virtues of rapid development and devotees
  > of the latter praise its greater reliability.

  > What I'm wondering is whether it would be useful to have a development 
  > environment in which you had the option of using either...

    There are several languages which support this.  In particular
Ada 95 tagged types were designed so that it takes explicit coding to
create a situation where a dynamic type check must be made that could
fail.  You can of course create Ada 95 programs where all type
checking is static.  In fact, it is quite easy to do this by
recompiling Ada 83 programs. ;-)

    This is not to say that an Ada 95 program won't have dynamic
dispatching all over, just that cases where the type check must be
dynamic and can fail are rare.  Basically the compiler makes a type
check once at a known point, when a method is called with an object
whose type is (explicitly in Ada) dynamic.  Nested calls are
implicitly dynamic, and often dispatch in practice.  But the language
rules insure that implicit dispatches can be statically checked, even
though the call may require run-time dispatching.

     Hmmm... An example may be required.  (Note this is for example
purposes, not how I recommend implementing Matrix operations in Ada):

     type Matrix(Height, Width: Integer := 0) is tagged ...;

     function "+" (L,R: Matrix) return Matrix;
     ...

     type Square_Matrix is new Matrix with ...;

     function Inverse(S: in Square_Matrix) return Square_Matrix;
     function Discriminant(S: in Square_Matrix) return Float;
     ...

     X: Matrix'Class := ...;
     Y: Matrix'Class := Inverse(X);

     There must be a type check on the call to Inverse, since X is not
known to be of type Square_Matrix.  Within Inverse, there may be many
calls to operations, perhaps some recursive.  But as long as the type
mark is not class wide, there is no need to do an additional check.
This is true even if Inverse contains a call to Discriminant on the
result of a call to (the derived) "+".  (Again, I'd probably use LUP
decomposition, but this is not about how to implement matrix
operations.)
     
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...