Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!udel!ee.udel.edu
From: new@ee.udel.edu (Darren New)
Newsgroups: comp.lang.misc
Subject: Re: definitions
Message-ID: <52164@nigel.ee.udel.edu>
Date: 29 Apr 91 17:33:11 GMT
References: <2494@optima.cs.arizona.edu> <51984@nigel.ee.udel.edu> <333124@socrates.umd.edu>
Sender: usenet@ee.udel.edu
Organization: University of Delaware
Lines: 69
Nntp-Posting-Host: estelle.ee.udel.edu

In article <333124@socrates.umd.edu> rockwell@socrates.umd.edu (Raul Rockwell) writes:
>I think the definitions given for >Strong typing were a bit cloudy.
>Strong typing also means that the function will terminate.

Excuse me?  Any language implementing while loops has functions which
won't terminate, strong typing or not.  Or do you mean it will terminate
when passed values of the wrong type?

>Note that checking type tags, without checking operand values is not
>adequate for all cases.  

Nor is it in static typing.  

>Darren New ::
>:: Strong typing: values of the wrong type cannot be stored into
>:: accessors (i.e., lvalues, function parameters, etc)
>I believe this is static typing, not strong typing.

No.  Static typing is when you know what types of values are supposed
to be stored into variables.  For example, old K&R C (or old FORTRAN)
allows integers to be passed into float parameters of functions.
Hence, even tho these languages are statically typed (because each
syntactic expression (e.g., variable) has a certain type), they are
not strongly typed because the language does not guarantee that
there won't be type errors.  Similarly with printf().

Contrast this with Pascal, where function calls and writeln() calls
cannot cause the wrong type values to be stored into properly-declared
variables.

>:: and functions may not be applied to values outside of their domain
>:: without a compiletime or runtime error.
>This, however, is strong typing.

I disagree.  If I convert assignment to a function call, does this change
the fundamental strength of the typing system?  Preventing wrong-type
assignments is just as strong or dynamic as preventing invalid
function calls.

>:: (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.)
>Talk about foggy explanations ;-)
>Maybe we need to define "error" ?

My point is that if you have an exception-handling mechanism that
the programmer can use to catch "message not understood" errors, then
one cannot really say that the behavior of a function generating a
message-not-understood is "undefined".  Something that aborts the
program without giving the program a chance to clean up could be
considered a runtime error.  Undetected errors are also "errors".

>:: Values of the wrong type are assumed to possibly have incompatible
>:: representations; i.e., valid integers may not be valid floats, etc.
>"assumed to possibly" ???

Merely meaning that the strong vs weak distinction is moot if there
is only one type of value.

>In any event, I don't think this is a meaningful way of describing
>strong typing.

So how would you describe it clearly  and concisely?

-- 
--- 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 +=+