Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Antonio Grandi) Newsgroups: comp.lang.misc Subject: Re: Dynamic typing -- To Have and Have Not (was Runti Message-ID: Date: 10 Mar 91 18:17:49 GMT References: <593@optima.cs.arizona.edu> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 88 Nntp-Posting-Host: aberdb In-reply-to: gudeman@cs.arizona.edu's message of 10 Mar 91 00:21:37 GMT 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: The equivalence class of all to which a given set of operations can be meanigfully applied. The ability to give an explicit name to a , and to have a 'typeof' operator (either explicit or implicit) that returns the appropriate name given a value. Being able to do for the denoted by (i.e. variables) at compiletime. When the denoted by a has a that cannot be determined at compiletime. When the of a cannot change. When the of a 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 and is artificial but necessary, and it causes trouble. Suppose that we have the 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 , 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