Xref: utzoo comp.lang.misc:6862 comp.object:2722 Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@test.aber.ac.uk (Piercarlo Antonio Grandi) Newsgroups: comp.lang.misc,comp.object Subject: Re: Dynamic typing -- To Have and Have Not (was Runti Message-ID: Date: 13 Mar 91 18:58:55 GMT References: <601@optima.cs.arizona.edu> <19728:Mar1208:45:2291@kramden.acf.nyu.edu> Sender: aro@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 75 Nntp-Posting-Host: aberdb In-reply-to: brnstnd@kramden.acf.nyu.edu's message of 12 Mar 91 08:45:22 GMT On 12 Mar 91 08:45:22 GMT, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) said: Incidentally, I hereby announce my defeat; I have realized that too many people are using dynamic and static typing to indicate when the type of *variables* is known. So I will use these terms like that myself. I propose the use of mutable/immutable typing for the case where the typing of *values* can or cannot be changed at runtime. brnstnd> a section of program text that refers to brnstnd> a value. Normally this is called the scope, except in Algol 68 where there is a distinction between range and reach. In all texts that I know reference is more or less synonymous with pointer. People use reference after the Algol 68 revised report, usually, or after Simula 67, which both use reference in the way indicated above. The normal definition of reference is something like "a value that may refer to another value or to no particular value". brnstnd> Note: If a statically typed language gives you ``the set of brnstnd> expressible types'' and ``the set of all values'' as basic brnstnd> types, and struct as a type composition operation, then you can brnstnd> implement runtime polymorphism in that language. [ ... ] Of course... But after you say: brnstnd> Given this, I fail to see how dynamic typing can be regarded as brnstnd> more than a syntactic feature. If you're given a program that brnstnd> uses dynamic typing, you can just convert every reference in brnstnd> the program to refer to a (type,value) pair, and poof! you have brnstnd> a statically typed program. This is entirely uninteresting! Recursion is merely a "syntactic feature" too, by the same argument, as it can always be obviated by the use of stacks or by iteration. Yet a lot of people think that recursion should be provided as a "syntactic feature". What we are interested here is in *architecture*, that is designing boundaries between layers. In our particular case the boundary between what the language provides directly and what the programmer can achieve building on top of that. Dynamic typing as a concept is simply necessary in a wide class of applications; one has four choices, with respect to it and static typing: 1) Don't provide dynamic typing as a language primitive and make it prohibitive to implement it on top of the provided language primitives. 2) Don't provide dynamic typing as a language primitive, and make it possible to implement it more or less grossly on top of the provided language primitives. 3) Provide dynamic typing only as a language primitive, and make it possible to implement static typing by explicit checks. 4) Provide *both* dynamic and static typing as language primitives, with no solution of continuity, as one becomes the other depending on which variable's values are known at compiletime. I reckon that Gudeman thinks that Bernstein advocates 1), while Bernstein really advocates 2); Gudeman himself advocates 3), and I advocate 4). While I advocate 4), I think that there are good reasons to think that 3) is acrtually a more tnable proposition than 2): an efficient implementation of dynamic typing as language primitive is not much worse (thanks to caching and hinting) than one of static typing, or at least the difference is not large for many complex *applications*, while a clean implementation of dynamic typing given static typing primitives is much harder to do, as the X windows example demonstrates so clearly. -- 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