[Types-sig] syntax (was: check.py)

[Greg Stein]

On Wed, 29 Dec 1999, Paul Prescod wrote:
> Greg Stein wrote:
> > ...
> > To do this, I would need to change the Python grammar, or suck in .pyi
> > files. I plan to do the latter once some kind of formal grammar is
> > specified. If that doesn't happen soon, then I'll be using the grammar
> > that I posted in my type-proposal.html. It is complete and is sufficient
> > (yet Paul seems to be starting from scratch... :-( ).
> 
> My syntax is mostly based on your web page. I switched "!" for "as"
> based on my belief that it isn't Pythonic to use random keyboard
> characters in ways that are not universally understood.

I covered this under a separate email. If you insist on using a word
rather than '!', then at least use the right semantic.

> And I put decl
> and typedecl at the front instead of making them operators because I
> agree with Tim Peters that we are designing a sub-language that needs to
> be understood as being separate by virtue of being evaluated BEFORE the
> code is executed.

I disagree. Making a "sub-language" will simply serve to create something
that is not integrated with Python. I see no reason to separate anything
that is happening here -- that is a poor requirement/direction to take.

The typedef unary operator allows a Python programmer to manipulate type
declarator objects. That will be important for things such as an IDE, a
debugger, or some more sophisticated analysis tools.

The "decl" statement is fine, but we shouldn't look at it as an escape
hatch for anything that we'd like to do.

> It is my personal opinion that the grammar should be the last thing you
> integrate into your system.

I'd rather see the grammar *now* so that check.py can take advantage of
it. That kind of defeats your claim :-)  Otherwise, we're just coding in
the dark, hoping that the app will work when the grammar finally gets
implemented.

> In order to avoid maintaining a whole
> compiler while the grammar shifts, I would suggest you define classes
> like this:
> 
> class ParameterizedInterface:
> 	....
> 
> class ConcreteInterface:
> 	....
> 
> class MethodSignature:
> 
> and so forth. You need these classes regardless.

I've got classes like this. Go look at typedecl.py in my posting.

> Then your interface file becomes:
> 
> Array = new ParamterizedInterface( 
> 	parameters=["elements", "array"],
> 	attributes=[new MethodSignature( arguments=... )]
>   )
> 
> We need this API anyhow so it would help alot if you could design it
> while you are writing your package.

Have you looked at check.py?

-g

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