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 Subject: Re: Dynamic typing (part 3) Message-ID: Date: 13 Mar 91 18:31:43 GMT References: <615@optima.cs.arizona.edu> Sender: aro@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 45 Nntp-Posting-Host: aberdb In-reply-to: gudeman@cs.arizona.edu's message of 13 Mar 91 01:21:07 GMT On 13 Mar 91 01:21:07 GMT, gudeman@cs.arizona.edu (David Gudeman) said: gudeman> In article <25381:Mar1221:07:3891@kramden.acf.nyu.edu> Dan gudeman> Bernstein writes: brnstnd> Compiler writers generally find it convenient to catch type brnstnd> errors. Yes, and this is simply part of the general principle that symbolic reduction should go as far as possible during compile time. Everything that is resolvable at compile time, i.e. that does not depend on variables that will be bound only at runtime, or during further compilation, should be resolved. Another principle is that the programmer should have the ability to decorate the source code with statements of his assumptions, to be checked by the compiler or runtime system as appropriate. Both principles above are embodied in something like Common Lisp's 'proclaim', on in the various type inference and explicit declaration rules of many functional languages. These two things mean that indeed static type checking should go as far as possible, which is what you say, but not that there should be no dynamic typing. gudeman> In a language with dynamic typing, everything from the parser gudeman> to the code generator tends to be much simpler. Only the gudeman> runtime system is more complex (and not much more complex if gudeman> you don't add all the extra features that dynamic typing opens gudeman> up). No, because the compiler will still have to do as much static checking as it is possible, either by symbolic reduction or by checking programmer's assumptions. I believe that compiler or runtime complexity is not an issue, because one must have *both* static and dynamic checking. Limiting onself only to one or the other seems constricting (just static checking), as dynamic checking has then to be simulated or many applications classes avoided, or hazardous (just dynamic checking), as checks that do not depend on the particular paths of program execution are not performed. -- 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