🚀 go-pugleaf

In article <2450@optima.cs.arizona.edu> gudeman@cs.arizona.edu (David Gudeman) writes:
|There is a difference between weak typing and dynamic typing.  Lack of
|understanding of this has resulted in far too much controversy,
|especially since the definitions have been posted.
|
|To repeat: weak typing means that the language may have undefined
|behavior like infinite loops or core dumps from a type error.  Dynamic
|typing means that it is not generally possible to assign a machine
|representation to the values that will be returned by all syntactic
|expressions.  You can still get strong typing in this case by
|including type information with the data at runtime.

This statement confuses the *hell* out of me. I thought I knew all
about this issue; goodness knows I've been immersed in enough of it.
But it seems to me that it is **DYNAMIC** typing that is generally
implemented with every object an (underlying) dependant product - i.e.
with every type having the SAME and thus PREDICATBLE machine
representation; and it is **STATIC** typing which permits the
representational consistency constraints to be optimised out so that
the machine representations are arbitrary and NOT interpretable except
by reference to the inductive type structure of the actual code!

DYNAMIC typing uses tags always, STATIC typing uses tags on programmer
request (i.e. in unoptimisable discriminant fields).  DYNAMIC typing
uses uniform representation, STATIC typing uses variant
representation. It's just what you'd expect: the more work the
compiler does, the more "compiled" the result.

Look at the identity function. In a dynamically typed system (assuming
strong typing throughout, here) it has "type" OBJECT -> OBJECT (i.e.,
it's a monadic function, that's the whole story). OBJECT has an
underlying representation like this:
	[TYPE T; T t]
(though maybe the tag T is moved up into the pointer in some cases),
and this is true whether the value of T is Integer, Float, List,
whatever. Conversely, in a statically typed system, I has type 
FORALL T:TYPE. T -> T, and the underlying representation of the
argument and of the result can ONLY be determined by examination of
the lexical call site (or, presumably, in the machine representation,
by the examination of the particular instance of T passed in as an
extra, hidden, parameter). In particular, while the value of the
formal argument type T may be passed in as part of the calling
convention, I don't see why it should ever be passed out again....

-very confused stephen
----------------------------------------------------------------------
stephen p spackman         Center for Information and Language Studies
systems analyst                                  University of Chicago
----------------------------------------------------------------------