RE: dynamic vs. static typing

["Anton van Straaten" <address@hidden>]

Joe Marshall wrote:
> "Anton van Straaten" <anton@appsolutions.com> writes:
>
> > In fact, a question would arise if you *didn't* want to
> > statically type such a list.  What on earth would you want
> > to do with it that involves knowing literally nothing about
> > the types of the elements?  If your answer is that you'll
> > use introspection to figure out what to do with the objects,
> > then that presumably implies that the objects support an
> > introspection interface, and you can specify that as a type
> > constraint.
>
> Surely you can think of *something* other than simple destructuring!
>
> What about `property lists' (alternating key and values) or
> `association lists' (list of key/value pairs), or simple sets?  All of
> these are interesting sorts of objects, they may be heterogeneous, and
> useful operations exist (assoc or member, for example) that do not
> need to know the type of the object contained in the list.

Assoc and member need to know enough about the objects they're dealing with
to test them for equality.  As Ken Shan pointed out, in Scheme or Lisp
there's a rich interface which all values support.  If all values can be
tested for equality, then you effectively have a base type or typeclass
(like 'Object' or "Scheme Value"), whether or not it's explicitly
identified.

The above lists could both be typed as "lists of values that support a
particular equality test".  Haskell does exactly this with its Eq typeclass.
See e.g.
http://www.syntaxpolice.org/lectures/haskellTalk2/slides/x183.html

Regardless of typing, values that don't support the required test will
either cause an error or be unfindable in a property or assoc list.  A type
constraint allows such a situation to be detected earlier - much earlier, in
the static typing case.

> What about representing a matrix as a list of lists?  Transposing such
> a thing doesn't require knowledge of the types involved, but it can be
> useful.

That's a better example.  I didn't think of it because I represent matrices
as vectors of vectors. :oP

You're correct, there are cases where the only interface you need to an
object is the ability to hold a reference to it.  Still, my main point
stands: to actually operate on the values in a list, rather than simply
shifting them around, you need to know something about the types of the
elements, even in a DT language.

> Things like the `wedge product' from exterior algebra (thanks
> to Greg Pettyjohn for showing me this) don't require the object types
> to be known.

If the wedge product performs an "abstraction of the traversal process",
then in an ST language it can presumably be handled in a way similar to the
abstraction of iteration represented by folds.  IOW, the static type of a
wedge product function would involve parameterized types which only need to
be known when the underlying combination operation is being applied, at
which point the concrete types must be known anyway.

Of course, mainstream ST languages either don't offer parameterized types at
all, or don't provide them in a very usable form (e.g. templates in C++).
This is one of the many reasons that people who've been put off static types
by C++ or Java should check out ML or Haskell.

Anton