[Types-sig] New syntax?

Greg Stein gstein@lyra.org
Mon, 20 Dec 1999 01:29:00 -0800 (PST)

On Sun, 19 Dec 1999, Tim Peters wrote:
> > The problem with using "decl" to do typedefs is that it does
> > weird voodoo to associate the typedecl with the name (e.g.
> > BinaryFunc).
> Perhaps an earlier msg made this clearer:  I've viewed "decl"s as (purely!)
> compile-time expressions.  IOW, BinaryFunc is a compile-time name in the
> above; there's no implication that a name introduced by a "decl typedef"
> will appear in any runtime namespace (this doesn't preclude that in some
> modes the implementation may *want* to make a Python object of the same name
> available at runtime).

I think that we definitely want to be able to construct and use typedecl
objects at runtime. That's why I prefer the typedef unary operator over
your "sub-language."

Viewing the "decl" stuff as a sub-language is kind of icky. Where is the
integration with Python itself? Having a clean integration is a good
measure that you have a Pythonic syntax and feel.

> > I believe my unary operator is much clearer to what is happening:
> >
> >   BinaryIntFunc = typedef BinaryFunc(Int)
> This looks like a runtime stmt to me; if so, it's of no use to static
> (compile-time) type declaration.  If it's not a runtime stmt, better to
> stick a "decl" (or something) in front of it to make that crucial
> distinction obvious.

It definitely is a runtime statement. But the compiler can easily track
what is happening.

We're doing data flow and type checking already: that's what the SIG is
about. Tracking the result of a typedef is cake once you have that.

> > In this case, it is (IMO) very clear that you are storing a typedecl
> > object into BinaryIntFunc, for later use. For example, we might see the
> > following code:
> >
> >   import types
> >   Int = types.IntType
> >   List = types.ListType
> >   IntList = typedef [Int]
> >   ...
> This all looks like runtime code to me -- if so, how is a *compiler*
> supposed to get any benefit out of it?  Or if not, how is a compiler
> supposed to recognize that it's not runtime code?

It is runtime code. The runtime is going to need those objects to execute
the runtime type checks (on function entry and for the type-assert
operator; possibly for assignment enforcement).

But the compiler can extract a lot of benefit from the above statements.
As I mentioned: the compiler can/should understand the types module and
the type() builtin (plus things like __class__). Then you're quite fine.
No magic voodoo involved.

> > Hrm. I don't have a ready answer for your first typedef, though. That
> > is a new construct that we haven't seen yet. We've been talking about
> > parameterizing *classes*, rather than typedecls.
> >
> > *ponder*
> In my twisted little universe, I'm using a declarative language for
> compile-time type expressions, and BinaryFunc(_T) can be thought of as a
> compile-time macro -- same as the BinaryIntFunc typedef (except the latter
> doesn't take any arguments -- or does take no arguments <wink>).

I know that. I meant that I didn't have a response that fits into *my*
universe :-)

>... tuple stuff ...
> > *grumble*  .... I don't have a handy resolution for this one.
> So let's make one up.  The problem is spelling "tuple of unknown length"
> (and Paul's complaint notwithstanding, that *is* Python so we gotta deal
> with it).  Python has no notation for this.  OK:
>     ...
>     Tuple(T1, T2, T3) equivalent_to (T1, T2, T3)
>     Tuple(T1, T2) equivalent_to (T1, T2)
>     Tuple(T1,) equivalent_to (T1,)
>     Tuple(T1) means tuple-of-T1 of unknown length
> So it's always *legal* to stick "Tuple" in front of a tuple specifier, and
> it's *required* in the last case.
> Actually, tuples show up in type specifiers rarely enough-- and look so much
> like grouping now --that I'd be happy requiring "Tuple" all the time.  Again
> one of those things that could be relaxed later if it proved too irksome.

A little wordy to include that keyword(?) in there, while things like List
and Dict don't require it. While a valiant attempt to solve the
readability of tuple type declarators, it just doesn't seem right... :-(


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