Python from Wise Guy's Viewpoint

[Lex Spoon]

"Andreas Rossberg" <rossberg at ps.uni-sb.de> writes:
> Clarification: I was talking about strong typing, i.e. full and precise
> inference. 

Please let us be careful with the terminology.  Strong typing means
that type checking happens at some point, and that a type error is
never allowed to complete (and thus do something non-sensical).
Inference is a completely independent axis -- any type system may or
may not have type inference.  If you happen to like strong
*dynamically* typed languages then it is extremely irritating when
people assume strong typing can only happen at compile time.

I don't know the exact word you are looking for, unfortunately.
"complete" doesn't seem right, because that seems to be a property of
an inferencer: an inferencer is complete if it finds a type assignment
for any program that can be type checked.  "sound" doesn't seem right,
either.  A sound type system produces *correct* types, but those types
may not be tight enough to predict an absence of type errors.

Maybe you should just say "static checking".  People will assume you
probably mean that programs get rejected if they have type errors.



> As an example of the kind of "overloading" (or type dispatch, if you want)
> you cannot express in dynamically typed lagnuages: in Haskell, you can
> naturally define functions which are overloaded on their return type, i.e.
> you don't need any value at all at runtime to do the "dispatch". For
> example, consider an overloaded function fromString, that produces values of
> potentially arbitrary types from strings.


You can do this kind of thing in dynamically typed languages, too,
though unfortunately it is not very common.  Do a web search on
"object-oriented" and "roles" and a lot comes up.  This is the same
thing: depending on the role that a requestor sees an object under,
the object can respond differently even to the same messages.  For
example, someone may respond to #requestPurchase differently depending
on whether the request treats them like a father or treats them like
the president of a company.  And it works for functional languages,
too, as is clearly exhibited by your fromString() overloaded function.
It could be viewed as acting differently depending on whether it is in
an int-producer role or a float-producer role.


(Incidentally, a lot of the results that turn up regard languages for
databases.  I was surprised at how much interesting language research
happens in the database world.  They take the view that long-lived
data is important.  This is common to Smalltalk people, and perhaps to
people who like Lisp machines, but even Scheme and Lisp people don't
seem to think a whole lot about this idea.  Database people certainly
do, however.  You can't just repopulate a database all the time!)

Anyway, depending on the role that the requestor is talking to, a
responder (be it a function or an object) can act differently.  In
some cases, the expected role can be figured out automatically,
instead of needing to be written explicitly.  This is somewhat similar
to the behavior of C++ when you invoke a non-virtual method: the type
of the *variable* decides what will happen.


Getting aside from theory and research, Matlab and Perl both allow
this kind of context sensitivity.  When you call a Matlab function,
the function knows how many return values you are expecting.  If you
call a function in Perl, it can tell whether you want a scalar or a
vector back, and it can act accordingly.  (At least, the built-in Perl
functions can do this.)



-Lex