🚀 go-pugleaf

In article  <3073:Mar2820:38:5191@kramden.acf.nyu.edu> Dan Bernstein writes:
]First, static typing is a simpler, more general, and more expressive
]underlying semantic model.

Nonsense.  How can it be simpler if it requires more details from the
programmer?  Statically typed languages are always more complicated in
the sense that they impose extra restrictions on expressions to make
static typing typing possible.  These extra restrictions are
complications.  By the same argument, static typing cannot possibly be
more general or more expressive.  You can write any expression with
dynamic typing that you can write with static typing, the reverse is
not true.  I will not credit the notion that being able to have the
computer check the static types of variables adds to the power or
expressiveness of a language.  Those terms are not rigorously defined
at this point, but my intuition rebels at the very notion.  Creating
restrictions cannot add to power or expressiveness.

]Ah! A real issue!

If you don't think the other issues are "real", why do you keep
arguing them?

] 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.)

I thought so.  Your preprocessor is not a preprocessor at all.

If you can write expressions that look just like dynamic typing, then
you have dynamic typing.  Implementation details are unimportant.  It
is of no value to the programmer to know at what stage of the compiler
the dynamic typing gets done.  Dividing compilation into transparent
stages is an unnecessary complexity.
--
					David Gudeman
gudeman@cs.arizona.edu
noao!arizona!gudeman