[Types-sig] PRE-PROPOSAL: Static Typing Syntax

[Martijn Faassen]

Hrm, I didn't reply to the Types-SIG but sent it to the previous poster,
I think. Here it comes my reply again, for public consumption this time
:)
I also saw adding 'PROPOSAL' to a message draws attention, so I put that
in the title. :)

Xiangyang Ted Meng wrote:
> 
> Hi,
> 
> I am curious that if it was brought up before and what loop holes
> it might have. Is it possible to embed optional type declarations
> in the doc string, something like:
> 
> def function(a,b,c):
>         '''
>         (normal documentations)
> 
>         [start of python optional  types]
> 
>         function: int
>         a: int, b: String, c: int
>         d: int
> 
>         [end of python optional  types]
> 
>         '''
> 
>         d=a+c
> 
>         return d
> 
> It might not look good for a language designer.
> But compared to the proposed ADD-LATER typing ( I only took
> glimpse of the WEB posting, might have missed something)
> like below
> 
> def function: int (a:int,b:String,c:int):
> 
>         '''
>         (normal documentations)
>         '''
>         d:int =a+c
> 
>         return d

I agree the optional static typing proposals I've seen for Python so far
look scary; it doesn't look much like Python, as it clutters up stuff a
lot. Perhaps it's just that I'm not used to them yet, but I fear it
isn't.

An alternative to using doc strings is to use a kind of old style K&R C
style typing (was this optional too in the beginning? I suppose so!),
mixed with some Pascallish, and docstrings:

    def function(a, b):
        var:
            Result: int   "The sum of a and b."  
            a, b: int     "The things that need to be added."
            sum: int      "Local variable used to temporarily store the
sum."
        """This function uses optional static type checking.
        """

        sum = a + b
        return sum        
                
The 'var' block can safely be ignored and the program should still work.
IDEs can even 'fold' it away, and preprocessors can rip all var blocks
out. Docstrings can be used to document what variables are used for, so
even this would be possible, going beyond just static typing into
documentation:

    def function():
        var:
            Result "Absolutely anything can be returned"
 
I've used 'Result' instead of the function name, for easy copy & pasting
of 'var' blocks. I know one shouldn't copy & paste so much it to prevent
'rape & paste programming', but everybody does it at times, right? var
blocks can be copied & pasted more easily than intermixed static type
annotations. To abstract interface, one could split the 'var' block into
an 'signature' (or 'arg') and 'local' block, like this:

    def function(a, b):
       signature:
           a, b: int   "Stuff to process"
           Result: int "Result of the entire calculation."
       local:
           foo, bar, baz: int "Lots of helper variables"
       """This function does a whole lot of silly stuff to a and b.
       """
       
       foo = a + b * a
       bar = foo * 12
       baz = foo + bar
       return baz

Another function could share the same signature.

Python could even figure out which functions are 'fully statically
typed', and pass them on to the Python compiler. These functions can
still easily be prototyped in Python, and the 'signature' and 'local'
blocks would only need to be added when the function stabilizes and we
need the speed. A tool could automate this process, by pointing out to
the developer which variables in a function haven't been described yet:
   hocheck test.py
   
   Line 173, cannot hyperoptimize function foo; bar has no static type.
   Line 214, cannot hyperoptimize function xyz; i, j have no static
type.

Excercises for the reader:

* Extend this to classes
* Make Python interfaces fit in with this scheme

Is-this-more-in-the-spirit-of-Python?-ly yours,

Martijn