🚀 go-pugleaf

In article <8960013@hpfcso.HP.COM> mjs@hpfcso.HP.COM (Marc Sabatella) writes:
> C uses (mostly) "structural equivalence" for determining when two types
> are compatible.  You seem to be saying that "strong typing" implies "name
> equivalence", which is not the way we learned it.  There are three sets of
> completely orthogonal distinctions here
> 
> strong vs weak typing (does everything have a type at compile time?)
> name vs structural equivalence (when are two types equivalent?)
> strict vs non-strict type checking (does the compiler allow type mismatches?)
> 
> C is strong, non-strict, and structural

I prefer another definition of strongly-typed.

My term for "does everything have a type at compile time" is
"statically typed", and I use "strongly typed" for: to what extent
does the compiler disallow illegal operations on values at
compile-time.

Examples of 'illegal operations' are: indexing a non-array or
selecting a field from a non-structure, dereferencing a non-pointer,
assigning incompatible types, and so on.

The fact that languages only check certain subsets of all possible
illegal operations allows you talk in terms of degrees of strong
typing: certain languages are weakly typed, others are strongly typed;
you coudn't do this with the definition of strongly typed as
"whether everything is statically typed".

Again in my opinion, most languages that are today called
strongly-typed are really only firmly-typed, because there are still
loads of illegal operations that are only identified at run-time.
Examples of operations that could be reduced to compile-time type
errors are: dereferencing nil, array indexing errors and sub-range
errors in general.

On the name equivalence front, I believe that name equivalence is in
general more useful from an abstract point of view than structure
equivalence, since it allows you to say:
	type height: integer
	type weight: integer

	height h; weight w;

and to let the compiler prevent you from accidentally saying:

	h= w

(Note, I'm not proposing that the compiler prevent you from assigning w
to h, only from you doing it accidentally; a well-designed language
with strong typing should allow you to do anything you want, and as
little as possible you don't want).

Indeed, C doesn't use entirely structure equivalence, because you can
always say
	typedef struct{int height_value;} height;
	typedef struct{int weight_value;} weight;

	height h;
	weight w;

	h.height_value= 175;
	w.weight_value= 60;

and the compiler complains about
	w= h;

But still, who goes to this trouble?

----------------
Disclaimer 1:
I appreciate that saying that dereferencing nil can be reduced to a
static typing problem is going to start a flurry in this group. For
this I apologise. To try and reduce the clamour, let me just say in
advance to anyone contemplating replying "This is impossible, because
it's equivalent to the halting problem": if you think this is so, you
don't understand the halting problem properly. Try and show that
static type checking is equivalent to the halting problem using the
same arguments, and I think you'll see the problem. Note that I most
certainly did not say "you can write a program that confirms that a
given C program is dereference safe".

Disclaimer 2:
I think that most languages that are today called "high-level" are
actually only "medium-level", too.

Disclaimer 3:
You could make the definition of strongly typed orthogonal by removing
the bit about "at compile-time". Then you could talk about "strong
dynamic typing", "weak static typing", and so on. This however would
be too much at odds with current usage, I think.

Steven Pemberton, CWI, Amsterdam; steven@cwi.nl
   Waiting for a compilation to finish, the C programmer switched the TV on.
   "Shoot first, ask questions later!" yelled the sheriff.
   At this the programmer gained enlightenment.