🚀 go-pugleaf

There seems to be a body of literature out there on better static
typing systems (referenced by David Chase) so I am hesitant to say
much more before studying the issue.  (That hasnt stopped alot of
people, of course :-) But let me ask a couple more questions.

In article <2400044@otter.hpl.hp.com> sfk@otter.hpl.hp.com (Steve Knight) writes:
>   My view is that the key issues for convenience are arbitrary unions and,
>   by implication, arbitrary subtyping.  

Are statically declared, arbitrary (anonymous?) supertyping (same as
unions?) and subtyping sufficient?  They would certainly be helpful in
taking care of many static typing problems, but are they always
enough?  Suppose that for some data it is *impossible* for the
compiler or programmer to know what restrictions (i.e.  data type
constraints) may be placed on the data until run time.  Languages that
support reflection would be prone to this class of problems, I
imagine.  Debuggers (that typically reflect on some other process)
seem to require dynamic typing, no?

If you dont know what constraints may be placed on some data even at
run time, then you are out of luck - you dont know what you can safely
do with the data and may risk core dumps.  Maybe the data knows what
its limits are (the object oriented approach) and maybe exceptions are
handled gracefully, but obviously something has gone wrong.

Speaking of which, is there some study of using exceptions not as
errors but as a control mechanism.  Consider that when a message is
sent to an object and its class does not understand the message, this
is a kind of exception.  But rather than stopping there, the message
is forwarded to the super class, etc.  If no class all the way up the
hierarchy understands the message, then we give up.  But why stop
there?  Perhaps the original sender would like to try again with a
different message.

One final thought concerns another kind of convenience argument
sometimes given for using dynamic typing.  Even when a type is
statically known and the language supports its specification
conveniently, is it sometimes (or always?) better to not explicitly
specify the type?  If the type of a variable changes during the course
of development, then other uses (but not necessarily all other uses)
of the type will often need to be changed to maintain consistency -
and this is extra work, especially during early development when many
things are changing.

Part of this problem could be solved by a better programming
environment that helped the programmer mutate the program
consistently.  Another tack is languages which infer types statically.
But how about an explicit (programmer specified) static typing system
in which the types are unlikely to change, except for typos?  That
assumes that once an variable's type is declared, it is most likely
the correct type.  This doesnt seem possible.  Any ideas?

Dan LaLiberte
National Center for Supercomputing Applications
liberte@ncsa.uiuc.edu