[Types-sig] PyDL RFC 0.02

[Paul Prescod]

PyDL is a pun. These files behave just like IDL in COM and CORBA. They
are a separate language, at least for now. 

Greg Stein wrote:
> 
> 
> The notion of two types of files just adds complexity. There is no reason
> that a generated file would be *any* different in form/syntax than a
> human's file. The human just gets to add funky comments, indentation, etc.

From PyDL RFC 0.03:

We have two different files so that hand-crafted PyDL files will not be
overwritten by generated ones. The syntax of the files is identical.

> In other words: design around a single file.

I did. The existence of two files affects the language semantics not one
whit but it makes the system much more safe and arguably much more
usable.

> Search *another* namespace? Eek! We're already seeing people avoiding the
> time with things like:
> 
>   def foo(len=len):
>     ...
> 
> Adding another namespace will just exacerbate the situation.

The whole point of static type checking is that the checks of the
namespaces should be done at *compile time*. It isn't like a name
reference from six levels of lexical nesting in a C++ file requires more
time to look up than a "local" reference. That's just a temporary Python
bug that we're trying to fix.

> Wasn't the notion of "const" (successfully) argued against inclusion?

Maybe. But I think that the situation changed when I moved from talking
about "lists", "tuples" and "dictionaries" to talking about "sequences",
"mappings" and "records" because we have no way of saying "read-only
record." Maybe that's a big deal for version 1. Maybe it isn't. I'm open
to opinions.

> I don't think this is going to work as you expect. The Python interpreter
> can't work with "Undefined" unless it is an object (otherwise, you're
> talking about a near-impossible revamp). Therefore, Undefined is an object
> and you're going to have some *real* serious issues trying to keep that
> out of some kind of assignment or other usage.
> 
> Pass it as a parameter? Shove it into a list or tuple? Check for Undefined
> on every name binding? What about indexed or slice assignment?

I think that there are finite number of such issues and you've listed
most of them. In each of these parts of the interpreter we need to add
two or three lines of C code. From a performance perspective, we will
just be doing a pointer comparison and branch which is tiny compared to
the rest of the interpreter overhead.

 Paul Prescod