🚀 go-pugleaf

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.  Though it does
demonstrate that macros can sometimes be used to simulate static
polymorphism.

]any max(a,b,lt)
]any a;
]any b;
]int lt();
]{
] if (lt(a,b))
]   return a;
] else
]   return b;
]}

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.  That is, you can't just write for your dynamically
typed value, you have to write something like integer(3).  Of course,
integer(3) is completely different from 3 and you can't do normal C
arithmetic on it, so you have to define all the arithmetic functions
in dynamic form.  And your code becomes almost unreadable since
everything has to be done in function call syntax.

Yes, I know the syntax wouldn't be a problem in C++.  Everything else
still is.

]... In contrast,
]``will eventually lead to a type-error'' is not particularly comforting.
]Your program may be doing something entirely different in the meantime,
]and lots of other data may be corrupted.

I should have said "will eventually lead to a type-error, almost
certainly during the first few test runs", since testing with bogus
input should be high on the agenda.  (Although it is true that an
exception handling machanism is the best solution.)

]> (1) dynamic typing
]> is useful enough that it should be supported directly by programming
]> languages,
]
]Supported, yes; but why does the support have to be direct? Why can't it
]just be a set of library routines, plus the syntactic sugar necessary to
]make you happy?

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.  Static typing is a hack to gain
efficiency on current architectures, so if anything it is static
typing that should be an add-on.  And type declarations are often
superfluous so they should not be required in the underlying model.

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.  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 */ }

is understood by the compiler, then it can optimize the use of i,
by generating integer arithmetic and not checking the type for each
operation.  But if gets translated to

  if (i.tag == INTEGER) { /* a bunch of code using i */ }

then the compiler doesn't have any idea what's going on.  Of course
you could have the preprocessor do some optimization itself and
provide debugging information to the compiler; but then what you are
calling a "preprocessor", I'd call an analysis phase of the compiler,
and what you call your "language", I'd call an intermediate
implementation language.

]> (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)?
--
					David Gudeman
gudeman@cs.arizona.edu
noao!arizona!gudeman