🚀 go-pugleaf

Victor Yodaiken >
 [responding to an illustration of how constructing a function
  specifies the type of the function]
>This makes sense, but it seems to be an instance of an abbreviation
>or convention. There is a preface: all functions are asumed to be
>over balogna sandwiches, implied in what you write.  If what you mean
>by "dynamic typing" is simply greater facility in defining domains
>and higher level declarations of type (e.g., all functions in the
>block are over integers), then I believe that I understand. But, it
>appeared from earlier discussion that dynamic typing was more
>involved.

Dynamic typing is simple in *concept*.  The problem is that it often
does not map well onto machine architecture.  For example, if you have
a function which is defined over the domain of numbers (take addition,
for example), then you usually see a dynamic typing system faithfully
providing that functionality for a variety of machine implementations
of numeric types.

There is no reason you couldn't have just a single numeric type (say
complex numbers where both real and imaginary components are 96 bit
IEEE floats).  Except that's pretty silly when all you want to do is
represent array indices.  Or worse, 1's and 0's.

>>Another advantage of dynamic typing is that you get a defined behavior
>>when a function gets a value which is out of its domain (e.g. divide
>>by zero, or array index with index too large).  Again, this is not
>>unique to DTLs -- and again, DTLs are more consistent about this than
>>STLs.

>I'm really lost now. What is the connection between type dynamism and
>well definedness of operations?

Another implementation detail of dynamic types is that there is a lot
more information present than is usually acted on.  For example, if
you have a function f(x) defined as F(g(x), h(x)), and g(x) is valid
over the integer domain, and h(x) is valid only for non-negative
numbers, then the domain of f is unsigned integers.  If f where
compiled, the compiler could probably make good use of this fact, and
issue warnings or error messages if f where used (a) where it is
possible to give f values outside of its domain or (b) where it is
guaranteed that f will be given values outside of its domain.  A
similar situation might be where the domain of f is integers greater
than negative 8.

In a statically typed language, type is considered to be a property of
variables, so if a variable can have a value outside the domain of a
function then that is not considered a type error.  In a dynamically
typed language, where practically all functions have type checks to
ensure their arguments' validity, more is usually checked than just
the "wordsize" or the "typetag" of the arguments.

Statically typed languages leave many such details to the programmer.
The advantage is that it is possible to write fast programs, simply by
leaving out some of the type-checks.  The costs are that errors may
not be caught as soon as they would be otherwise, and that the
programmer must spend a fair bit of his time programming and debugging
type structures.

Raul Rockwell