🚀 go-pugleaf

In article <1991Mar28.124634.28106@mathrt0.math.chalmers.se> augustss@cs.chalmers.se (Lennart Augustsson) writes:
>In article <1991Mar27.161304.17666@daffy.cs.wisc.edu> quale@saavik.cs.wisc.edu (Douglas E. Quale) writes:
>>In Common Lisp,
>>
>>(defun compose (f g)
>>  (lambda (&rest) (funcall f (apply g &rest))))
>>
>>I think it looks better in Scheme,
>>
>>(define (compose f g)
>>  (lambda x (f (apply g x))))
>>
>>These definitions use dynamic typing to obtain polymorphism.
>>
>Yes, in LISP it's dynamic typing that gives you the polymorphism, but
>you don't have to have dynamic typing.  Let's do the same definition
>in ML, which is statically typed:
>  - fun compose(f,g) x = f(g x);
>  > val compose = fn : (('a -> 'b) * ('c -> 'a)) -> ('c -> 'b)

Actually the SML code isn't an exact replacement for the lisp code.
In SML the function g must be unary, while the lisp code uses a rest arg so
that g is n-ary.  I don't know if the type inferencing algorithm used in
SML (or in Haskell, re: an earlier post mentioning the same point) can be
extended to handle functions that take a variable number of arguments.  Some
people would say that varargs are bad.  I think that they're useful, but I
can live without them.

I never claimed dynamic typing was *required* for polymorphism, just that it
is an inherent benefit.

Dan Bernstein doesn't believe that programs written in languages with dynamic
typing are shorter than those written in C.  My example (which was originally
posted by someone else) is merely to show that polymorphism which is automatic
for a dynamically typed language makes it easy to write code that is very
difficult to duplicate in C.  With the exception of the varargs situation,
SML and Haskell and Hope and Miranda and Ponder and Orwell and probably many
other modern languages have no difficulty with this example.

I probably shouldn't use such a mature language as lisp to pick on C, but all
the languages mentioned above are younger than C and their type systems are
much more powerful.  The ANSII C type system would have been state of the art
20 years ago when C was invented, but today it's just a 20 year old type
system.  I have no bones to pick with modern type systems -- I like SML.
The problem with C's type system is that it falls between two stools:  it
doesn't give you the power and freedom of expression of a dynamic type system,
and it also doesn't give you the type safety of a truly strong type system
like SML's.  (And it certainly doesn't give the polymorphism of either.)
The lack of type safety across separately compiled modules is the last nail
in C's coffin.

Twenty years ago, when C was invented, many programmers thought that they had
to program in assembly language because high level languages were too
inefficient.  Fortunately, some folks looked into the future instead of the
past.  The success of C helped changed that attitude.  Today it's time to
look past C.  Some won't, of course, but progress is usually slow.

-- Doug Quale
quale@saavik.cs.wisc.edu