[Types-sig] New syntax?

[Greg Stein]

On Fri, 17 Dec 1999, Tim Peters wrote:
> [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!

hehe :-)

This syntax is part of my current proposal. I definitely agree it is a
requirement to be able to specify functional types.

>...
> 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>

This seems entirely reasonable to me. Let's see what Mr. Consensus says.

> > 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.

Correct. I forgot to mention that and noticed the lack later when I read
that email. No worries... you won't let me get away with being a
slacker... :-)

>...
> Yes, Any is good.

I've listed this in my proposal as an open question. I'm leaning to
"formally endorsing" it. My only real opposition is whether it must be a
new keyword, or we can find some other way to deal with it.

For example:

import types
Int = types.IntType
String = types.StringType
Any = None

decl foo: Any
decl bar: String

The compiler isn't going to have recognized names for the types. I think
it will be using data flow to figure that out (and maybe some builtin
knowledge of the type() builtin and the types module). If the compiler
determines that a particular dotted_name leads to the value None (whereas
it typically refers to a PyTypeObject, a class object, or a typedecl
object), then it says "oh. that is the 'any' construct".

This also leads quite naturally to the following:

def foo(bar):
  ...

In this case, all the type annotations are not specified -- they are None.
Implicitly, that means "any".

Damn, I'm smooth. ;-)

> 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

Yah... this has been covered. No problem.

Funny note: looking at the grammar, I've found the following is legal:

  def foo(bar, *args, * *kw):
    ...

In my typedecl syntax, I punted the ability to use "* *" ... you must use
"**". So there :-)

> > ...
> > 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.

Yup. Quite a reasonable argument.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/