🚀 go-pugleaf

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> <reference>		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