[Types-sig] Static typing: Towards closure?

Vladimir.Marangozov@inrialpes.fr Vladimir.Marangozov@inrialpes.fr
Fri, 21 Jan 2000 20:12:05 +0100 (CET)

Bah. Forgot to cc the list, sorry.


Subject: Re: [Types-sig] Static typing: Towards closure?
To: guido@CNRI.Reston.VA.US (Guido van Rossum)
Date: Fri, 21 Jan 2000 20:12:05 +0100 (CET)
Reply-To: Vladimir.Marangozov@inrialpes.fr

Guido van Rossum wrote:
> I've had an off-line discussion with Greg Stein (mostly) and Paul
> Prescod about trying to converge on a single proposal.

Thanks for the proposal. It contains a lot of worthy points that I need
to digest. BTW, I found the slides quite helpful in building an overall
picture of the proposal.

Without going into the details, here's my overall impression:

1. If static type checking pretends to be optional, you'd really, really,
   really want to forget the inline form and remain with the explicit one.
   (at least as a start).

   I understand that type declarations tend to "penetrate" the code in
   order to allow more checks, but if we allow this, I predict that the
   end of the story will be that we'll silently cross the point of no
   return where Python code will look like C++. And I'll regret this.
   At some point in the future, you'll regret it too.

   Retaining only the explicit form of type declarations will keeps us
   on the safe side, preventing us to "pollute" the main code with
   "optional" constructs. This will also defer the whole discussion on
   'decl: def' shortcuts and the like. Let's keep the original code
   (the dynamic/unchecked one) clean!

   I definitely perceive the inline form as Python code pollution and
   believe that it is potentially unappropriate in a number of areas.

   If you still like the inline notation, please make sure that you
   build a tool first, which can convert automatically all inline
   typedecls into explicit ones. If the tool cannot handle an inline
   decl, you've crossed the critical point, and "optional" won't hold

2. I like the <name> : <type> notation. It seems concise unless you
   see Guido's slide No. 8 :-), where there's an example of a typed

   It's not very clear which colon is part of the proposed notation
   and which one separates the text from the examples. (Guido: i'd
   suggest changing the color or font style for the examples in the
   whole presentation)

3. After reading the proposal 2 times, I still feel uncomfortable with
   the "decl" keyword. This term is too generic. Python is a declarative
   language, class and def are defacto declarations (with a default type
   of "any"), etc. In this context, "decl" is not very clear and the newbie
   following a CP4E course would have to read the docs, not the source,
   to understand that "decl" means a type declaration.

   It seemed to me that in a number of places in the proposal, "decl" is
   not sound at all and that it may well be replaced by "typedecl" or simply
   "typed" (abbrev. of "type declaration" ;-).

   Thus, a typed module would start with the "typed" keyword alone, which is
   more logical than "decl" alone.

   Also, typed var declarations seem to be easily readable for me:

   typed i : int
   typed m : str, n : str
   typed f : def(int, {str : {str : str}}) -> dict (???)

   typed kw_type = {str : {str : str}}
   typed f : def(int, kw_type) -> dict

   (???) is this correct

   This is simply a matter of clarity. I won't push too much for "typed"
   though, because static type checking in Python is, of course, optional

       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252