[Types-sig] PyDL RFC 0.02

Greg Stein gstein@lyra.org
Mon, 27 Dec 1999 04:55:08 -0800 (PST)


Only a few quick comments for now...

On Mon, 27 Dec 1999, Paul Prescod wrote:
> PyDL RFC 0.02

PyDL ?!

Don't tell me "Python Definition Language." That is the wrong semantic...
you're talking about an "inteface file", not a language.

I'd seriously recommend a new acronym before you confuse people :-)

.pyi or something.

>...
> The Python interpreter invokes the static interface interpreter and
> optionally the interface checker on a Python file and its associated
> PyDL file.  Typically a PyDL file is associated with a Python file
> through placement in the same path with the same base name and a
> ".pydl"  or ".gpydl" extension. If both are avaiable, the module'sj
> interface is created by combining the declarations in the ".pydl" and
> ".gpydl" files.

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.

In other words: design around a single file.

>...
> Once it interprets the Python code, the interface objects are
> available to the runtime code through a special namespace called the
> "interface namespace". This namespace is interposed in the name search
> order between the module's namespace and the built-in namespace.

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.

I don't recommend adding another distinct namespace, but *IF* you are
going to do so, then I might suggest that it is only available for use
from withing a typedecl.

>...
> 5. Declare un-modifiability:
> 
> const [const Array( Integer )]
> 
> (the semantics of un-modifiability need to be worked out)

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

>...
> The Undefined Object:
> =====================
> 
> The Undefined object is used as the value of unassigned attributes and
> the return value of functions that do not return a value. It may not
> be bound to a name. 

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?

>...
> conforms( x: Any, y: Interface ) -> Any or Undefined

This is predicated upon the "Undefined" concept. I believe that Undefined
isn't possible as you're currently defined it, thereby making conforms()
unusable.

Cheers,
-g

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