🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.misc
Article #2985

Re: Dynamic typing (part 3)

#2985
From: Piercarlo Antonio Grandi
Date: Wed, 13 Mar 1991 18:31
45 lines
2730 bytes
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
Technical Details
Message-ID: <PCG.91Mar13183143@aberdb.test.aber.ac.uk>
Path: arc1-ca.pugleaf.net!utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg
References: <615@optima.cs.arizona.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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: <PCG.91Mar13183143@aberdb.test.aber.ac.uk>
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