Newsgroups: comp.object


[I am '   >', Bob is '   '].

In article ... Bob Hathaway <objsys@netcom.com> writes:

   >I'd characterise the difference (the extremal difference, not necessarily
   >the typical one), as being that, in a ST language, types are *only* 
   >available at compile-time. In a DT language, they are *only*
   >available at run-time. [I stress; these are the *extreme* cases.]

   By this definition of static typing (with which I agree), C++, Eiffel, ...
   are all statically typed languages.

That I find acceptable (although some information I think of as type
information is presetn at run-time in both C++ and Eiffel, but since normally
you can't do a great deal with it, I'll let that pass).

  "Typeless" has been applied to your definition of dynamically typed
   languages as has "weakly typed" (although this last term can be confused
   with the possibility of type holes).  

Yes, there is an entire genus of terms that have been coined. I prefer
``typeless'' to mean the monotyped languages such as BCPL and Bliss, and use
``dynamically typed'' or ``latently typed'' for the DT languages.

   Then you'd say CLOS is "statically and dynamically typed", interesting.

Not me, guv, since it satisfies neither of my terms -- type information is
available at both compile and run time, although not always where you want.
(For example, the type of an *expression* is not available at compile-time in
CLOS. Not normally, anyhow.)

   >I read your statement above as saying that a statically typed language 
   >*cannot* make type information available at run-time. I would regard this
   >as an excessive restriction.

   Perhaps my way of putting it was off: stating certain languages only provide
   static typing may be a better way of putting it than referring to a language
   as "statically typed".  

I would regard the latter as implying the former, but no matter. I think there
are two issues here which are worth separating:

 * whether type *checks* are performed at compile or run time.

 * whether type *information* ia available (to the programmer) at compile or
	run time.

One can imagine various combinations, although some of them are rather stupid
(like doing no type-checking at all, even if the information is available).

   I assumed the confusion was over matters such as
   languages providing only static typing (with virtuals) can only perform
   static inclusion polymorphism and not the dynamic variety, meaning that
   multi-methods cannot be supported. 

By the (implied) term ``dynamic polymorphism'', do you mean the free-for-all
latent typing exemplified by Lisp and Smalltalk?

   Maybe I should have said: With static
   typing a formal object can have different functions called for a function
   invocation depending on the type or class of the actual object provided
   (dynamic binding) but only from a common set of declared base virtual
   functions and only with [...] restrictions on these function's signatures;
   restrictions which can only be lifted with dynamic typing.

I think I agree. HEY EVERYONE GET A LOOK AT THIS -- DOLLIN JUST AGREED WITH
HATHAWAY. DEATH OF THE NET PREDICTED. FILM AT ELEVEN.

   Amazingly enough, Coplien blunders pretty bad in this area.  The bottom of
   page 121 is too painful to reproduce.  He claims C++ compilers place a 
   hidden type field (unavailable to programmers) in objects whenever virtual
   functions  are present in its class and that this type is used at run-time.
   This is obviously false and can lead to the kind of confusion I've been
   trying to clear up.  Maybe his compiler uses type tags, switches, and 
   thunks instead of vtables?-)

Isn't this the usual implementation of classes-with-virtual in C++ ? The vtable
(to which you refer yourself) is just such a ``hidden type field''. Granted,
one doesn't (in general) look at it to deduce the actual type of an object, but
that's what it is.

   >   In other words (and for the last time), you can't switch on dynamic 
   >   types if (by definition) they aren't there!  And multi-methods are 
   >   dispatched at run-time (dynamically).  
   >
   >Would it be correct for me to read you as saying ``You can't have 
   >multi-methods in languages which are so statically typed that no type
   >information is available at run-time''? If so, I think you are wrong, for
   >two reasons.

   No, I am right by definition.  Your (one) justification below is based on
   a dislike of these strictly statically-typed languages and does not
   reflect on the validity of the premise.

A later message contained the accidently-omitted second case. I agree that you
are ``right by definition'', but the point I was making was that such languages
are, ipso facto, not ``interesting'' -- ie, they can't do the things that we
want to do (without the programmer being converted into a languages extension
manager). 

   To my knowledge, programming languages providing only static typing (such as
   C++) are far more commonly used than other OO languages making this point
   worthy of discussion.  Since these languages are being used, letting 
   everyone in on their deficiencies and providing better alternatives and 
   fixes should certainly be considered worthwhile, and this was my intention.

Yes (modulo earlier remarks).

   >in such a notation, where the rules have enabled us to eliminate all
   >possibility of type errros, are said to be in a statically typed notation. 

   Thats "strongly" typed.  C provides only static typing but it doesn't
   provide  strong typechecking (try lint or C++ but there's still unchecked 
   casting).

Wrrr ... well, I don't use the term like that (when I say ``static typing'', I
think I assume the ``strongness''), but I'll live with that use of words.

   >[Note also that there's a well-respected school of thought that makes
   >things like 1/0 perfectly resonable: it's a value in the range of /, but
   >you *cannot

   This sounds like what can occur with lazy evaluation.  Even 
   (non-conservative) optimizations can produce different semantics for this 
   thru code motion (watch it!).

Well, it's a little like it, but it's not the same. For one thing, lazy
evaluation is a technique for getting non-strict evaluation in a programming
language; it has as a consequence that ``erroneous'' terms whose value is never
needed are not evaluated, and hance are ``safe''.

The approach I was describing has, essentially, *no* erroneous terms. That is,
the term ``1/0'' is legal, and the term ``1/0 = 1/0'' is legal and denotes
true. ``1/0'' denotes *some* integer, but you don't know which one. Note that
this is not a matter of *programming*, but of *specification*.

   [On Hierarchical restrictions]

Well, I don't think it was me, so we'll let that drop.

[Stuff on CLOS deleted because there seem to be no further points to be made]
--

Regards,    | ``The French teacher does not threaten. She says, | Teen
Kers.       | "s'il vous plait"''.                              | Agent
Newsgroups: comp.object