Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.c++,comp.lang.smalltalk,comp.lang.objective-c,comp.object
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!cam-news-feed3.bbnplanet.com!cam-news-hub1.bbnplanet.com!news.bbnplanet.com!cpk-news-hub1.bbnplanet.com!feed1.news.erols.com!news.ecn.uoknor.edu!munnari.OZ.AU!news.mel.connect.com.au!news.syd.connect.com.au!syd.csa.com.au!news
From: donh@syd.csa.com.au (Don Harrison)
Subject: Re: Combining dynamic and static typing
X-Nntp-Posting-Host: dev50
Message-ID: <E4uFo5.38C@syd.csa.com.au>
Sender: news@syd.csa.com.au
Reply-To: donh@syd.csa.com.au
Organization: CSC Australia, Sydney
References: <EACHUS.97Jan27115439@spectre.mitre.org>
Date: Thu, 30 Jan 1997 22:55:16 GMT
Lines: 92
Xref: glinda.oz.cs.cmu.edu comp.lang.eiffel:18014 comp.lang.ada:56895 comp.lang.c++:244472 comp.lang.smalltalk:50536 comp.lang.objective-c:6316 comp.object:60607

Robert I. Eachus writes:

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

Should this be:
     function Determinant(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.)

I was actually thinking of something more radical than this. The idea is to 
initially leave out most of the type information out and supply only what is 
pertinent to object creation/initialisation. Static type checks would be 
suppressed where types are not given. Typing would then be added during
the course of development with progressively more static checks being made 
and when development is completed, the system would be completely typed and 
statically checked.

Taking your code above as an example, you might initially have:

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

     function "+" (L,R);
     ...

     type Square_Matrix is new Matrix with ...;

     function Inverse(S);
     function Determinant(S);
     ...

     X := ...;
     Y := Inverse(X);

and when the type information is filled in, it would then become your 
original fully typed code. Whether the idea would work or not I don't know, 
but the aim is to facilitate rapid prototyping. No doubt, the idea may be 
heretical to some. :)


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au


