Re: dynamic vs. static typing

[Joe Marshall <address@hidden>]

Ken Shan <ken@digitas.harvard.edu> writes:

> Let me make my previous claim a bit more concrete: any function that
> you can write, that can take as input a list of elements, where the
> only thing you know you can do to every element is to pass it around,
> and that always returns without error a boolean as output, must always
> return the same boolean for all input values of the same "shape".  In
> other words, replacing every element with an empty data structure would
> never change the output of such a function.  (I use "boolean" here
> to model observations on the result of a program.  Another type like
> "character" or "integer" would do fine.)
>
> The intuition that I am trying to get at is, -some- part of your program
> needs to assume -something- about the interface supported by your list
> elements in order for the program overall to observably operate on the
> list and its elements.  You can very well reverse a list, throw out
> every third element, concatenate the string keys in an association list,
> etc., but in the end if you can't assume anything about the elements,
> then you might as well not keep the elements around at all.

This is true, and you could discard the objects and manipulate an
abstraction of them, but the client shouldn't have to do this part of
the work.  Consider computing the cardinality of a set that is
represented as a list of items.  The client shouldn't be required to
convert this to a list of NILs just to ask the list library what
the length of the list is.  It seems equally absurd to parameterize
the list length function over the kind of elements in the list.

Another idea, for example, is a function that permutes a list of
elements.  The permute function doesn't need to know what the list
holds.  Sure you can parameterize the permute function on the type of
list, but isn't this passing inessential information?  Permute
certainly doesn't care.

> The wedge product (or for that matter if I understand correctly, the
> function that takes a list of values and computes their product) doesn't
> require knowing the object types, but it does require knowing that the
> object types are "the same" in that it requires knowing a multiplication
> function that takes two elements and produces a new one.

The wedge product doesn't need to know about the multiplication, it is the
`Hodge *' operator that does.