Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!samsung!uakari.primate.wisc.edu!sdd.hp.com!elroy.jpl.nasa.gov!usc!rpi!uupsi!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.lang.misc
Subject: Re: Dynamic typing (part 3)
Message-ID: <3073:Mar2820:38:5191@kramden.acf.nyu.edu>
Date: 28 Mar 91 20:38:51 GMT
References: <1211@optima.cs.arizona.edu>
Organization: IR
Lines: 80

In article <1211@optima.cs.arizona.edu> gudeman@cs.arizona.edu (David Gudeman) writes:
> In article  <25317:Mar2803:26:1291@kramden.acf.nyu.edu> Dan Bernstein writes:
> ]In article <1162@optima.cs.arizona.edu> gudeman@cs.arizona.edu (David Gudeman) writes:
> ]#define max(a,b,lt) ((lt)((a),(b)) ? (b) : (a))
> Not a proper function on args with side effects.

Fair enough; the problem here is that C doesn't let you make a variable
without making a block. (``The data scope matches the control scope,''
or something like that.) If you don't want to use a static variable
(like Fortran parameter passing) here, and you need an expression rather
than a block, then you'd better use a true expression language. This is
independent of static versus dynamic typing, though.

  [ function version, given a polymorphic ``any'' type ]
> That is a tiny fraction of the whole solution.  The whole solution
> requires implementation of tagged structures, and garbage collection,
> and requires that all of your numbers be specified with constructors
> of some type.

Yes, so? All of this is hidden below the implementation of ``any'' and
operations on it.

> First, dynamic typing is a simpler, more general, and more expressive
> underlying semantic model.  It makes no sense to design a language
> under a less satisfactory model and then to patch on the better model
> with libraries and preprocessors.

First, static typing is a simpler, more general, and more expressive
underlying semantic model. (After all, it lets you say what your
variable types are, without worrying about some screwy syntax for the
job.) It makes no sense to design a language under a less satisfactory
model and then to patch on the better model with libraries and
preprocessors. (Ya know, assertions like ``x is an int. Really!'')

The problem with this argument is that neither model is more general
than the other, or simpler, or much more expressive. Given a statically
typed language with structs, an ``all'' type, and the set of types, you
can set up pairs (value,type) and poof! there's dynamic typing. Given a
dynamically typed language with assertions, you can assert that a value
has some type and poof! there's static typing. A good preprocessor will
smooth out the differences either way; so, all else being equal, you
might as well choose the model that produces better code, i.e., static
typing (at least with current technology).

> Second, it is not possible to tack dynamic typing on a statically
> typed language (using a preprocessor and a library) without paying
> some penalty somewhere.  Dynamic typing needs direct support from the
> debugger, for one thing.

Yeah, so? As long as your debugger is built in to your interpreter, this
is not a problem.

> For another, there are optimizations that
> the compiler can't do without understanding dynamic typing.  For
> example if
>   if (integer(i)) { /* a bunch of code using i */ }
  [ vs. ]
>   if (i.tag == INTEGER) { /* a bunch of code using i */ }

Ah! A real issue! In Q's any.h, an ``any'' variable comes with a number
of constraints: if x.type == anytype(int), for example, then
eq(typeof(x.value),int). (Here anytype and typeof are functions
evaluated at the preprocessing level; anytype is defined by any.h and
produces a run-time value, but typeof merely produces a token that must
be used at compile time.) So in your example, it just takes simple data
flow analysis for the compiler to understand that i.type won't change
inside the block, and hence all operations on i are integer operations.

> ]> (4) it is not clear the the ability of
> ]> static type declarations to catch errors outweighs the number of
> ]> errors that occur in the declarations.
> ]Fair enough. However, just in case the benefits of static typing *do*
> ]outweigh the errors---possibly by a lot---doesn't it seem wise to
> ]provide the support?
> Did you see number (3)?

Okay, I was just making sure that you didn't mean (4) as a
recommendation of any sort.

---Dan