🚀 go-pugleaf

In article <ROCKWELL.91Apr25193638@socrates.socrates.umd.edu> rockwell@socrates.umd.edu (Raul Rockwell) writes:
>If C++ is strongly typed because of the lack of this error, then so is
>machine language.  I'm not sure I see the point of calling this
>property "strongly typed".

Machine language is weakly and dynamically typed. C++ is (mostly) strongly
statically typed. They both have similar effects on "message not understood"
errors.  Isn't "segmentation violation" a "message not understood" message?
It all depends on how you look at it. From the point of view of the
programmer who didn't expect this error, this is a type error (e.g.,
that "mov.l (a4)+,d0" didn't put a long into d0). From the point of
view of the OS, usually only bus errors trying to access the interrupt
vector are "undefined" resulting usually in a CPU halt which can only
be recovered by a reset.

>My own definition of "strongly typed" was that the language will not
>return a result for applying a function to values which are outside
>its domain.  Note that except for trivial cases you most definitely
>can get "domain errors" (or "message not understood") at runtime.

Sounds like a good definition.  I'll give some examples below.

>Now, I understand that classic works have claimed that a type error is
>a value which puts the program in an infinite loop.  

How else are you going to "not return a value"?

>However, I would
>say that a language where this happens is weakly typed.  In fact, I
>think that from this point of view, a "strongly typed" language is one
>which only allows finite looping constructs, and which guarantees a
>well-behaved "run-time error" whenever a partial function is applied
>incorrectly (or maybe we should call this "absolutely typed"?).

Terrible example.  Smalltalk is "strongly typed" and when you get
a type error, the message call does not return any value; instead,
it goes into an infinite loop reading the keyboard and interpreting
what the debugger says to do and so on. Why restrict yourself to
finite looping constructs?  Why not just guarantee a well-behaved
"run-time error"?  

Of course, this gets kind of hairy, because the computer never really
gets into an infinite loop, so some value is always returned somewhere
(unless the computer can never ever be made to work again, at which
point the question again appears moot).  Hence, when you say "doesn't
return a value" you have to clarify it.  If I catch "message not
understood" have I returned a value or have I had a type mismatch or
both? This is part of the confusion in this discussion.

Let's use these definitions, or at least choose *some* definitions
before we start another round of "yes it is"/"no it isn't".
(Somebody want to save these so I don't have to keep reposting the
definitions?:-)

Dynamic typing (one more time for the expiration-impaired :-):
syntactic elements (like variables or expressions) do not have types.

Static typing:
syntactic elements (like variables or expressions) do have types and these
types can be determined at compile time. It doesn't matter whether the
use specifies the types implicitly or explicitly or a combination
of both. It *does* matter that each variable is supposed to hold
one type of data only, and the representation of that data is assumed
to be known at compile time.

Strong typing:
values of the wrong type cannot be stored into accessors (i.e.,
lvalues, function parameters, etc) and functions may not be applied to
values outside of their domain without a compiletime or runtime error.
(Note: a catchable runtime error (or exception), like "message not
understood" in Smalltalk, is not a runtime error. A non-catchable
error, like "new" running out of space in Pascal, is a runtime error.)
Values of the wrong type are assumed to possibly have incompatible
representations; i.e., valid integers may not be valid floats, etc.

Weak typing
values of the wrong type can be stored into accessors and/or functions
may be applied to values outside their range without an immediately
detectable error.

Examples of all four combinations:

Static weak typing: K&R (pre-ANSI C)
Array subscripting, bad pointers, passing int's as float's into separately
compiled functions, etc, etc, etc are all not caught, but each and
every syntactic value-carrying expression (function calls, variables, etc)
has a declared or determinable type.

Static strong typing: Modula-3 (safe subset)
There are no operations (supposedly) which cause the wrong type
of value to be stored into a variable; variables are initialized to legal
values; dangling pointers cannot dangle, etc.

Dynamic weak typing: Most machine languages (as seen from the OS point of view)
The same memory location can hold both integers or addresses, and checks
are not made that the value is used in the right way. 

Dynamic strong typing: Smalltalk
Every operation returns a defined result for every value, yet no variable
or function needs to know the "type" it will hold, explicitly or implicitly.
(Note again that "message not understood" in Smalltalk is a defined catchable
error and therefore returns a value.)


-- 
--- Darren New --- Grad Student --- CIS --- Univ. of Delaware ---
----- Network Protocols, Graphics, Programming Languages, FDTs -----
+=+ Nails work better than screws, when both are driven with hammers +=+