🚀 go-pugleaf

Dr. A. N. Walker writes:
>	If *I* can look at (say) "a+b" and decide whether the operation
>is defined, and what types the operands might have, and what the
>consequences might be for the rest of the program, so can the compiler.
>If you intend to make use of the *freedom* that dynamic typing can give
>you [and I agree that it is sometimes, even often, useful], then it
>follows that you *can't* know what your expression might do (except in
>the very boring sense that a particular language might define otherwise
>undefined operations to deliver 0, or some such).

Er, what do you mean by "make use of the *freedom* that dynamic typing
can give"?

I'd think that using a primitive which has meaning for more than one
type would qualify.  And so should writing some operation intended to
have the same effect on different types of data.  And so should using
a primitive which would be impossible to define if it's results had to
be of some singular type.

My first thought is rather weak, I know.  Statically typed languages
usually let you do things like check equality between objects of the
same type.  And a died-in-wool static-typing-hardliner would claim
that it is meaningless to find out that objects of different types are
not equal.

Examples of the second also can be done in statically typed languages,
things like sorting, searching, and selection.  But even C (which some
people have said we shouldn't be using as an example of a statically
typed language) doesn't have a hashed search (for un-ordered items) in
any of the libraries I know of.  And I'd like to hear about such
things in a language other than C...  Who knows, I might be in an
environment where I'll have to use another language.

For the last one (primitives returning data of any type), I'll give
two examples:

(1)  Typed data on file (including array bounds, which some people
might claim is not type information).  (For those who haven't read my
earlier postings, I've been claiming that static type checking isn't
strong enough).

(2)  An 'Eval' primitive.  Before this is safe, I know, you have to be
able to validate each of the symbols used (make sure they are
appropriate for the problem).  But how could you even provide such a
service in some other language?  Or is somebody going to claim that if
I need the semantics of Eval, I'm supposed to write my own from ground
up?

Also, I know that with C you can write a meta-program which writes
another program, and that often serves the same purpose.  But how do
you validate that the meta-program wrote the right stuff into the
dynamically created program?  I find these more of a pain to write and
debug than they should be.  I've also found other people's work along
the same lines to often be a little non-portable (address errors from
lex/yacc code, for instance).

Finally, there are a number of things that I'd dread even trying to
describe in a statically typed language (things which take functions
as arguments and yield new functions as a result).  Yet I claim that I
can understand what the derived functions would do when applied to my
code.  Of course, I suppose many of these are equivalent to control
structures in a static language (but control structures have their own
problems... )

    The world of statements is a disorderly one, with few useful
    mathematical properties.  Structured programming can be seen as a
    modest effort to introduce some order into this chaotic world, but
    it accomplishes little in attacking the fundamental problems
    created by the word-at-a-time von Neumann style of programming,
    with its primitive use of loops, subscripts, and branching flow of
    control.
                    John Backus -- 1977 Turing Award Lecture

Raul Rockwell