Pascal Bourguignon <[EMAIL PROTECTED]> writes: > Matthias Blume <[EMAIL PROTECTED]> writes: > >> Pascal Bourguignon <[EMAIL PROTECTED]> writes: >> >>> Moreover, a good proportion of the program and a good number of >>> algorithms don't even need to know the type of the objects they >>> manipulate. >>> >>> For example, sort doesn't need to know what type the objects it sorts >>> are. It only needs to be given a function that is able to compare the >>> objects. >> >> Of course, some statically typed languages handle this sort of thing >> routinely. >> >>> Only a few "primitive" functions need specific types. >> >> Your sort function from above also has a specific type -- a type which >> represents the fact that the objects to be sorted must be acceptable >> input to the comparison function. > > Well, not exactly.
What do you mean by "not exactly". > sort is a higher level function. The type of its > arguments is an implicit parameter of the sort function. What do you mean by "higher-level"? Maybe you meant "higher-order" or "polymorphic"? [ rest snipped ] You might want to look up "System F". >>> So basically, you've got a big black box of applicaition code in the >>> middle that doesn't care what type of value they get, and you've got a >>> few input values of a specific type, a few processing functions >>> needing a specific type and returning a specific type, and a few >>> output values that are expected to be of a specific type. At anytime, >>> you may change the type of the input values, and ensure that the >>> needed processing functions will be able to handle this new input >>> type, and the output gets mapped to the expected type. >> >> ...or you type-check your "black box" and make sure that no matter how >> you will ever change the type of the inputs (in accordance with the >> interface type of the box) you get a valid program. > > When? When what? -- http://mail.python.org/mailman/listinfo/python-list
