[Types-sig] updated proposal

Tony Lownds Tony Lownds <tony@metanet.com>
Mon, 3 Jan 2000 19:59:13 -0800 (PST)

I just tried to compile Python 1.5.2 with your syntax changes. I got
pretty far but your syntax needed a bit of tweaking. Here is a tweaked
version of the "type declarators" code snippet that worked[1]:

# first NAME should be: 'member', 'var', 'class', etc
decl_stmt: 'decl' NAME NAME ':' typedecl
typedecl: item_tdecl ('or' item_tdecl)*
item_tdecl: param_tdecl | list_tdecl | dict_tdecl | func_tdecl |
param_tdecl: dotted_name ['(' arglist_tdecl ')']
tuple_tdecl: '(' typedecl (',' typedecl)* [','] ')'
list_tdecl: '[' typedecl ']'
dict_tdecl: '{' typedecl ':' typedecl '}'
func_tdecl: 'def' '(' [varargs_tdecl] ')' '->' typedecl
varargs_tdecl: (arg_tdecl ',')* ('*' ':' typedecl [',' '**' ':' typedecl] 
| '**' ':' typedecl) | arg_tdecl (',' arg_tdecl)* [',']
arg_tdecl: typedecl

The changes are:
- the grouping alternative in item_tdecl conflicted with tuple_tdecl, so
  tuple_tdecl handles grouping and tuples

- arg_tdecl cannot have a name, just a type. I don't see a way to have:

    arg_tdecl: [NAME ':'] typedecl 

  in python's parser, because typedecl can start with a
  NAME via dotted_name) so the rule makes an ambiguous DFA. You 
  can have:

    arg_tdecl: typedecl [':' typedecl]

  and constrain the first typedecl in the AST-consuming code.

I'm going to continue to add the syntax you've laid out. I've
independently been writing grammar for in-line function definitions stuff
so that'll be the next piece. 

However, I'd like to hear from people who have an opinion if using a
modified build is even adviseable. My recent experience suggests it is not
because when you change the grammer you often trip up the compiler and end
up with a broken python.

If it *is* adviseable, then the thing to do is to completely specify the
syntax and then make a Grammar and compile.c that works with current
syntax (ignoring any type declarations).

If it is *not* adviseable, then the thing to do is to make check.py go
through an interface instead of accessing the parser, token and symbol
modules directly, and look for another way to turn Python programs into
parse trees.

Either way I'm pretty interested in getting check.py to work on a modified 
Python syntax, if only to test ideas.


[1] test run - the python binary was built with a modified Grammar/Grammar

habib:~/src/Pyhack/Python-1.5.2> ./python syntest.pyc 
Module readline not available.
>> decl mamber sprintf as def(String, *:[Any]) -> String
     (NAME, 'decl'),
     (NAME, 'mamber'),
     (NAME, 'sprintf'),
     (NAME, 'as'),
        (NAME, 'def'),
        (LPAR, '('),
         (arg_tdecl, (typedecl, (item_tdecl, (param_tdecl, (dotted_name,
(NAME, 'String')))))),
         (COMMA, ','),
         (STAR, '*'),
         (COLON, ':'),
            (LSQB, '['),
            (typedecl, (item_tdecl, (param_tdecl, (dotted_name, (NAME,
            (RSQB, ']'))))),
        (RPAR, ')'),
        (RETURNS, '->'),
        (typedecl, (item_tdecl, (param_tdecl, (dotted_name, (NAME,
   (NEWLINE, ''))),

On Mon, 3 Jan 2000, Greg Stein wrote:

> I've updated my proposal document at:
>   http://www.lyra.org/greg/python/typesys/type-proposal.html
> There have been some minor refinements to text, examples, and a small
> syntax change to type declarator (had to add '(' typedecl ')' to deal with> some binding precedence issues).
> I've also added a big section on what I see as open issues. I've listed by
> biased :-) thoughts along with my understanding of the counter-proposal.
> Comments are most welcome!
> Cheers,
> -g
> -- 
> Greg Stein, http://www.lyra.org/
> _______________________________________________
> Types-SIG mailing list
> Types-SIG@python.org
> http://www.python.org/mailman/listinfo/types-sig