🚀 go-pugleaf

In article  <PCG.91Mar10181749@aberdb.cs.aber.ac.uk> Piercarlo Antonio Grandi writes:
]
]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,...

]<type>			The equivalence class of all <values> to which
]			a given set of operations can be meanigfully
]			applied.
...
]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'.

This only happens in a statically typed language.  In a dynamically
typed language you don't declare the types that an operator works on,
so this doesn't happen.

This definition of types originated with the implicit assumption that
the set of operations are fixed.  When operations can be added at
runtime, bizarre situations arise where the type of a value can
change.  This doesn't shouldn't prompt us to add complexity to the
language, trying to distinguish between <type> and <typing>.  Rather
we should drop this notion of <type> altogether and define

<type>			a set of values.

Then no seperate notion of <typing> is needed.  In fact, this is what
is done in most dynamically typed languages.  It makes it trivial to
do useful things like define hierarchies of types (subsets) and to
have values that are of several different types (membership in
different sets).  It also gives you powerful machinery for defining
complex types and for deciding type membership.  It also gives you a
fairly simple way to define the result of the 'typeof' function(s)
even though a value may have may types: you just define some arbitrary
(but useful) partition of the set of all values, and give each set a
name.

(There are people who complain about using the word "set" here since it
makes it problematic to make <type> a value.  (eg: T is the type that
contains all types that do not contains themselves.  Is T in the type
T?)  However, that is a problem cause by defining <type> to be a
value.  It is not inherent in defining a type as a set.)
--
					David Gudeman
gudeman@cs.arizona.edu
noao!arizona!gudeman