Re: dynamic vs. static typing

[Joe Marshall <address@hidden>]

"Anton van Straaten" <anton@appsolutions.com> writes:

> 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.

Er, yes, but whether an object is identical to itself isn't usually
considered a property or interface of the object.

In any case, the value part of the association need not have any
knowledge whatsoever of what the value is.

> 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.

I wasn't arguing the utility of doing some sort of static analysis on
them, I was just pointing out that lists of unknown objects are
interesting in and of themselves.

> 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.

This is true, but shifting them around (and adding some, replacing
some, deleting some) is a very useful thing, and has very little to do
with *what* you are shifting around!

>> 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.

*Provided* that you need to get back into the realm of numbers!  If
you look upon the wedge product as an operator on vector spaces, then
there are a lot of interesting things you can do *without* knowing
what the underlying objects are (it may be useful to shift the objects
around *even if* there is no way to ever determine what the objects
are.)  So there is no reason that the wedge product needs to know the
concrete types.  It can (and ought to) treat the objects it
manipulates as black boxes.