🚀 go-pugleaf

In article <49907@nigel.ee.udel.edu> new@ee.udel.edu (Darren New) writes:
>
>Dynamic typing is when the type of a *variable* is unknown (and unspecified)
>at compile time.  Any given value assigned to that variable will have
>a type, but the variable does not restrict what types of values may
>be assigned to it.  Contrast these:
>
>int f(float f, int i) { blah blah blah }
>/* here, f must only get floats and i must only get ints. */
>
>(defun f (f i) (blah blah ))
>Here, f may be a float, and integer, a bignum, a list, a closure, etc.
>
>Basically, expressions, variables, function names, and so on do not have
>types.  Nothing that is purely syntactical has types.  Only actual
>values have types.               -- Darren

Makes sense. But, then I don't believe that dynamic typing  is similar
to standard mathematical usage. In fact, it seems that the trend in mathematics
has been towards greater use of "static typing". 
The problem with "untyped" expressions is that they are inherently
ambiguous. If I'm writing about  semigroups and regular languages I must
tell you when a*b is concatenation and when it is semigroup addition.
Figuring this out from the context alone is difficult for most people.
What makes 
classical programming languages so annoying, however, is that the
type schemes are so much more clumsy than we are used to in mathematics.

	At the simplest level, one might have a hierarchy of types of
	objects, and demand that when two objects appear together, they are
	always converted to the type that appears highest on the hierarchy.
	In practice, however,  types of mathematical objects do not form any
	kind of strict hierarchy, In some respects,they form a network, or
	directed graph, and one could imagine always converting objects to
	the type of their common ancestor" in the network. But even this
	much more elaborate mechanism does not adequately capture
	mathematical usage. Different forms of algebraic expressions, say
	factored and expanded out, can be thought of as different types. In
	most cases, the rules for when to convert between these types are
	much more complicated than you can represent by a simple fixed
	network of type conversions.
               Stephen Wolfram, Mathematica