Python from Wise Guy's Viewpoint

Matthias Blume find at my.address.elsewhere
Tue Oct 28 17:24:32 EST 2003


Pascal Costanza <costanza at web.de> writes:

> Matthias Blume wrote:
> > Pascal Costanza <costanza at web.de> writes:
> > 
> >>Can you give a better example of a program that would render
> >>meaningless without type annotations?
> >    fun f A = "A"
> 
> >      | f B = "B"
> > 
> 
> I don't find this convincing. This is similar to the 20 * 30 example.
> 
> The resolution in both cases would be to define a default meaning if
> no explicit type annotation exists. Done.

Of course, you can always define a default meaning for the case that
no explicit (type) information is available.  But what you are doing
is essentially providing such information: no explicit type annotation
amounts to having an implicit annotation.

By the way, this is how, e.g., SML does it anyway: If you write just
20*30 and nothing else is known, then the type is resolved to be
Int.int.

This does not invalidate the claim that you know the semantics of the
phrase only if you know the type.  It just so happens that you always
know the type.

> I think that Neelakantan has better examples for programs that are
> possible to write with a statically typed language, but not with
> dynamically typed ones. (Not 100% sure yet, though.)

There are no such programs, obviously.  You can always translate a
statically typed program into a dynamically typed one (and vice
versa).

The advantage (as far as I am concerned) of the statically typed
program is in the guarantees that it provides:  If I write

   fun foo x = ...

and x is declared or inferred to be of type t, then I never again have
to worry about what happens should someone pass a non-t to foo
because that simply cannot happen.  This all by itself is useful, but
it gets even more useful if t is an abstract type so that I have full
control over how and where t values are generated.

This sort of thing is most useful when designing libraries because in
this case you don't know yet (who will call foo and how (and you might
in fact never know). But you do know that whoever it is and however he
does it, he must pass a value of type t.

Matthias




More information about the Python-list mailing list