[Python-3000] Type annotations: annotating generators

[Guido van Rossum]

On 5/18/06, Kay Schluehr <kay.schluehr at gmx.net> wrote:
> Guido van Rossum schrieb:
>
> >> Another question: is there any intention to
> >> support ML style quards for pattern matching on algebraic /recursive
> >> types?
> >
> > Can you rephrase that without references to ML or quads?
>
> No, but the basic idea is easily explained using ML syntax and semantics.
>
> ML lets users define their own datatypes which has the obvious advantage
> that they do not need to pollute their function signatures with
> definitions. Python would likely use class syntax for this purpose or
> interface syntax in future (?)
>
> Some examples:
>
> (* simple 'algebraic datatype' created by RED, YELLOW, BLUE . The vertical bars mark alternatives. *)
>
> datatype PrimaryColours = RED | YELLOW | BLUE;
>
> (* simple recursive datatype. The '*' token is used to combine types to a cartesian product type *)
>
> datatype IntTree = NIL | NODE of int * IntTree * IntTree;
>
>
> There is a symmetry between the usage of the vertical bars in datatype
> definitions and in "pattern matching" where the pattern mentioned here
> refers to the "algebraic datatype".
>
> (* Function 'colourString' that keeps a PrimaryColours type. Note that ML is statically typed and each type will
>    be inferred so declarations in function signatures can be omitted.
>  *)
>
> fun colourString c =
>     case c of
>       RED    => "red"
>     | BLUE   => "blue"
>     | YELLOW => "yellow"
>   ;
>
>
> (* Another function defined on IntTree *)
>
> fun preOrder t =
>     case t of
>       NIL => [ ]
>     | NODE (i,left,right) => (preOrder left) @ (preOrder right) @ [i]
>   ;

I'm frustrated by your inability to translate ML terms into Python;
you seem to assume that ML is easy, but I can guarantee you that in my
experience it's a language only spoken by people whose IQ is >= 150.

I still don't quite get which part you're interested in having in
Python's type system; if you can't explain it without mentioning ML,
the default answer to your original question (about intent) will have
to be no. :-)

I'm not sure what you meant by "quards" -- "quads" (as I originally
read it -- not knowing any ML it seemed totally plausible that it
might have something called quads) or "guards" (by which you could
perhaps mean the case statement above???). Guards are definitely not
planned.

I guess by "algebraic types" you meant enumerated types? Those aren't
planned either.

I happen to know what you mean by recursive types (even though you
don't explain the NODE thing in your example). I think we would do
that by defining the type first using some notation for forward
references (e.g. lambda:A as a forward ref to A). Then your IntTree
example could become (if I'm guessing right that @ is ML's list
concatenation operator):

class IntTree:
  op: int
  left: None | lambda:IntTree
  right: None | lambda:IntTree

def preOrder(t: IntTree):
  if t is None:
    return []
  else:
    return preOrder(t.left) + preOrder(t.right) + [t.op]
# Isn't this postOrder though?

However, note that I'm currently not proposing to have class attribute
annotations like "op: int" above, so we'd have to use some other way
to spell that. (While "op: int" seems a fine notation, it's ambiguous
about whether it refers to instance or class attributes.)

I'm not convinced that we need all this for the likely intended use,
since static type checking isn't really high on the agenda anyway.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)