🚀 go-pugleaf

On 10 Mar 91 00:21:37 GMT, gudeman@cs.arizona.edu (David Gudeman) said:

gudeman> In article <1991Mar6.024730.19073@engage.enet.dec.com>
gudeman> grier@marx.enet.dec.com writes:

grier> This is besides the point, but what's an untyped language then?

gudeman> The term is usually used to refer to dynamically typed
gudeman> languages.  I'd just as soon drop the term completely, since it
gudeman> is misleading if a language has any built-in types at all.

A point of order: I would not use 'dynamic types' here.  I would say
'latent types'. The idea is that dynamically typed should be reserved
for the (currently rare!) case where the language allows the type of a
*value* to change dynamically, not for the case where the type of the
value of a *variable* is not manifest at compile time.

I would propose the following terminology:

<type>			The equivalence class of all <values> to which
			a given set of operations can be meanigfully
			applied.

<typing>		The ability to give an explicit name to a
			<type>, and to have a 'typeof' operator (either
			explicit or implicit) that returns the appropriate
			name given a value.

<manifest typing>	Being able to do <typing> for the <values>
			denoted by <references> (i.e. variables) at
			compiletime.

<latent typing>		When the <value> denoted by a <reference> has a
			<type> that cannot be determined at compiletime.

<static typing>		When the <typing> of a <value> cannot change.

<dynamic typing>	When the <typing> of a <value> can change during
			program execution.

Examples (contrived, unfortunately):

We have the values from 0 to 2^32-1, and the operations +,-,* modulo
2^32 on these values. They form a type. We add an operation, 'typeof'
that given one such value returns a type name, say 'unsigned'.

We have typing. We write 'unsigned i'. This is manifest typing, as we
know by the inpesction of the program source that the values that the
reference bound to the 'i' identifier can only have typing 'unsigned'.

Now we switch to Scheme and we say '(define i 0)'. We have latent static
typing, because the typing of the value involved may change at runtime,
but whatever the value is, its typing will *not* change during the
execution of the program.

Now we switch to some more advanced language and we add while the
program is executing a new operation, say '/', with two arguments, one
is 'unsigned' and the other is 'positive' (nonzero).  Then we can
dynamically chang the typing of the value '1', because now it can be
*both* an 'unsigned' and a 'positive'.

So, latent typing is when 'typeof' applied to a *variable* is not a pure
function, in that given the same variable it may give different results
at different times; dynamic typing is when this happens also when it is
applied to *values*, not just to variables.


Note that the distinction I make above between <type> and <typing> is
artificial but necessary, and it causes trouble.

Suppose that we have the <type> defined by the class of values to which
operations +,-,* modulo 32 can be applied as above; we can call it the
'unsigned' class in some nice contemporary language and we have

Suppose that we now also define the % operation to the unsigned class;
we have a *different* type, but the typing remains the same, because
'typeof' will continue to return 'unsigned' when applied to values
tagged as belonging to the 'unsigned' class.

This is not very dangerous in this particular situation, but inb others
it can be highly inconvenient especially when the definition of a class,
that is the <typing>, is allowed to change dynamically. For example it
can be very dangerous if we change the encoding for the values of that
class, e.g. from binary to BCD.
--
Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk