RE: dynamic vs. static typing

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

Joe Marshall wrote:
> "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.

Then I'd argue that those doing the "usual considering" are missing
something important.  The fact is, equality is an operation on values, which
makes it part of the interface to those values.  Many languages recognize
this explicitly, because they have to, to get their semantics right.
Haskell, C++, and Smalltalk all explicitly define equality as part of the
interface of a type or class.

The Haskell example I referenced includes the enumeration of a number of
seemingly trivial identity relationships, such as "Monday == Monday", i.e.
specifying, for the benefit of a type definition, "whether an object is
identical to itself".

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

I agree with this point, but I was trying to show that it doesn't really
affect the point I was making.  I was saying that if you don't know
*anything* about an object, then you can't safely perform operations on that
object (not even equality tests).  In these cases, you can use a parameter
to represent the types of the objects, and not worry about concrete types.
As soon as you need to perform an operation on an object, though, you need
to know something about its type, and that's as true in a DT language as an
ST language.

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

Yes, you're right.  So this is all an argument in favor of easy to use
parameterized types.  :)

Anton