[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: dynamic vs. static typing



On 2003-11-21T10:30:49-0500, Joe Marshall wrote:
> Ken Shan <ken@digitas.harvard.edu> writes:
> > On 2003-11-20T17:06:56-0500, Joe Marshall wrote:
> >> It seems equally absurd to parameterize
> >> the list length function over the kind of elements in the list.

> [elaboration on "parameterize":]
> 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.

I'm sorry but I'm losing your point here.  You have explained what it
means to parameterize a type ("list of strings" vs "list of integers"),
but not what it means to parameterize a function ("take the length of a
string list" vs "take the length of an integer list").  The reason the
latter is crucial is because in many statically typed languages these
two functions can be the same.

Taking a step, I'm confused what you mean above when you say that it
is "absurd to parameterize the list length function over the kind of
elements in the list".  Do you mean that it is absurd to have to write
one function for taking the length of string lists, and another function
(with pretty much the same code) for taking the length of integer lists?
If so, I agree with you, but no longer see the connection of this
absurdity to my earlier "condemnation".

Or do you mean that it is absurd to give the list-length function a type
such as

    forall a. ([a] -> Int)

when it could just have the type

    [exists a. a] -> Int

?  Given that the latter is subsumed by the former, I'm not sure what is
absurd about the situation.  Besides, giving the list-reverse function
the type

    forall a. ([a] -> [a])

allows us to type more programs than giving it the type

    [exists a. a] -> [exists a. a]

when invoked, the list-length and list-reverse functions don't "have to
know" the type of list elements they are manipulating.

Or maybe you meant something else that I haven't thought of...

I think the list-length and list-reverse examples are sufficient to
cover concerns with other data structures like associative lists and
matrices, and the wedge product.

	Ken

-- 
Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig
http://www.daybydaycartoon.com/
"vi has two modes: one where it beeps and one where it doesn't"

Attachment: signature.asc
Description: Digital signature