Re: dynamic vs. static typing

[Joe Marshall <address@hidden>]

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

> On 2003-11-20T17:06:56-0500, Joe Marshall wrote:
>> Ken Shan <ken@digitas.harvard.edu> writes:
>> > 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.
>
> I have never said that the client of a list length function needs to
> convert the list to a list of NILs.  To the contrary, you can easily
> call the same list length function on all sorts of homogeneous or
> heterogeneous lists in say Haskell.

I understand.  I wasn't suggesting that any implementation actually
required this.

>> 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.
>
> I don't know what you mean by "parameterize".  Could you please
> elaborate?

Many statically typed languages have parameterized types where, for
instance, you could have a list of integers as distinguished from a
list of strings.  You can statically guarantee that the first element
in a list of integers was an integer, or that the element you are
appending to a list of integers is itself an integer.

It would therefore be an error to attempt to call the `list of
strings' append function on an integer, but it would be ok to call the
`list of integers' append function.

Likewise, it would be ok to call the `list of strings' permute
function on a list of strings, but not ok to call the `list of
integers' permute function on a list of strings.

> The wedge product needs to know that the objects in the matrix can be
> multiplied.  The easiest way to provide the wedge product with such a
> guarantee is to provide it with a multiplication function.  

The wedge product doesn't actually multiply anything (well, you can do
a partial reduction on the coefficients), it just figures out what
*would* be multiplied if you wanted to do so.  In most cases, there
are an infinite number of possible multiplication routines, any of
which would be suitable.  But since the wedge product doesn't
*actually* multiply, why should it need to know which one you have in
mind?  Maybe you don't have one in mind yet.  Maybe you never will,
and you just want to know if term A ever ends up next to term B.  So
the wedge product doesn't *need* to know *anything* about what is
being multiplied.