[Types-sig] New syntax?

[Tim Peters]

[Greg Stein]
> ...
> I guess that does mean that something like:
>
> decl a: def(Int)->None
>
> would be possible. e.g. <a> is a member holding a ref to a function
> object.

If it weren't possible, it would be quite a hole in the type description
mechanism!

> Of course, the type of <a> in this case is no different than:
>
> def a(Int x)->None:
>
> It is just that one declares a member and the other declares a method.
> There is a subtle difference there :-)

I'd say it's exactly as subtle as the difference between

    Class.f = somefunc
and
    Class().f = somefunc

today.  BTW, I wouldn't object to requiring that the class/member
distinction be explicit.

    decl class a: ...
    decl member a: ...

If "decl" gets used for more stuff down the road, it could be a real help to
make the syntax explicit from the start:

   ofwhat : 'class' | 'member' | 'var' | 'type' | 'frozen' | ...
   decl-stmt : 'decl' ofwhat <stuff that depends on ofwhat>

> In fact, these two are probably equivalent:
>
> decl class a: def(Int)->None
> def a(Int x)->None:

WRT type, yes, but (of course!) the former is merely a declaration while the
latter is the initial stmt of a definition.

>> In either case, I'm not sure what to do about varargs (the
>> "*rest" form of argument).

> What's wrong with:
>
> decl a: def(Int, *)->Int
> decl b: def(Int, **)->Int
> decl c: def(Int, *, **)->Int
>
> I don't see any ambiguity in the grammar there, unless you use "*"
> to mean unknown (as Paul once mentioned). I think the unknown type
> should be "Any" (or "any"), since it really means "take any type
> of value."

Yes, Any is good.

The problem with * and ** is that people are going to want to express
restrictions, like "only strings from here on in" or "all the keyword args
must be of int type".  Under the theory that things work well if you just
don't think about them <wink>,

    decl c: def(Int, *: (String), **: {String: Int})->Int

> ...
> I'm not sure whether to go for practical or pure.

I'm leaning toward the "always explicit" above.  Restrictions can always be
loosened later if they prove too confining, but tightening a permissive spec
is usually impossible.

despite-guido's-charming-belief-that-we-could-actually-ban-
    intractably-magical-namespace-mutation<wink>-ly y'rs  - tim