🚀 go-pugleaf

Brian Boutel   >|>  or >
Me             <|

>|>First, let me try to define what I mean ...
>|>- A type is a set of operations.
>|>- a value has type T if it understands all the operations of type T
<| Thus a value can have multiple types?
>Yes, within a type hierarchy, a value may have a type and that type's
>supertype and so on upwards.

I'm not sure if a "type hierarchy" is always appropriate.  Consider
the following functions: factorial, sine, reciprocal, log, addition,
and multiplication.  Describe a type hierarchy which allows me to use
each of these functions (or operators, if you prefer) in a meaningful
fashion, without arbitrary restrictions.  I don't see how you can get
away from type errors occuring at runtime.

What I'm trying to say is that a general purpose function will quite
likely be able to generate different values, which have different
types.  This occurs because the definition of "type" deals with what
happens when a function is _applied_ to data.  Type tags are
implementation specific, and are not required to get run-time type
errors.

Maybe you're wondering what good it does it do to have a run-time
error?  Assuming you don't have some special case procedure to handle
a specific error (like renormalization *gack* *gack* *cough* *gasp*),
you could maybe back up to the last user input (or some generic user
prompt), and suggest, wistfully, that the user trys something else.
Much better than spewing out garbage, or crashing the program.

>|>It is possible at compile time to ensure that a value is never
>|>bound to a variable of the wrong type, and that only type-valid
>|>operations are performed on variables, thus preventing type
>|>violations.
<| How is this possible?  Especially in a machine with finite limits?
<| Note that arithmetic overflow means that addition can produce values
<| which don't have the type for addition.
>This is the cause of the misunderstanding between us. I was not
>including arithmetic exceptions such as overflow or divide by zero as
>type violations. ...

>So my type system has deficiencies, but it can still catch a lot of
>errors at compile time that might otherwise get through testing.  I
>think that is worthwhile.

I think you're on weak ground here.

Essentially, you seem to be saying:  subtle errors I don't consider,
but blatantly obvious errors are worth catching.

I also think that if you were working with a system which gave better
support to run-time testing, you might catch more errors in testing.

Finally, a statement which is formally accepted by the compiler is not
necessarily a statement which is correct in the context of a specific
program.  If a language cuts the number of branches in half (by
allowing the same statement to deal with more cases), _each_ branch
removed cuts the testing time roughly in half (or by n, in the case of
an n-way branch).  A program which has 24 independent branches may be
impossible to test adequately.  A program with no branches can be
almost trivial to test.

I should mention that I spend much of my time tracking down and
squashing lingering race conditions left by long-departed programmers.
This kind of problem, in particular, seems to be inadequately
addressed by static type checking (and I am relieved that I don't have
to bother with it when I don't want to).

Raul Rockwell