Thoughts on new grammar rules (PEP 284 in particular)

[Steve Horne]

On Tue, 14 May 2002 15:43:54 +0200, holger krekel
<pyth at devel.trillke.net> wrote:


>> Of course, with 20/20 hindsight, a much better approach could have
>> been taken. For instance, consider the following...
>> 
>>   begin function ... :
>>     ...
>> 
>>   begin while ... :
>>     ...
>> And, relevant to a current PEP...
>> 
>>   begin switch ... :
>>     begin case ... :
>>       ...
>> 
>>     begin default :
>>       ...
>
>don't you think that the increased verbosity hurts a lot? 
>(Apart from the fact that 'begin' sounds like starting a loop to me.)

Not really, with just this one keyword. If you've ever used Ada,
you'll have seen much more verbosity than this. In fact, most of the
block structures in Pascal, Modula 2, Ada and similar require a begin
keyword - but it is positioned in such a way that it can't be used as
a 'here is a block structure' hint, so multiple predefined keywords
are needed in each case.

Avoiding verbosity is important, but it always involves trade-offs
with other language goals. Python is already frequently more verbose
than Perl - for example we need a 'len' function rather than a 'scalar
context' symbol to determine the length of a list - because
readability is given a higher priority in Python. I simply suspect
that it might be beneficial to consider a similar trade-off for
grammar-extensibility.

As for the appearance of starting a loop, why? - it is already used in
a number of languages as part of the start of structure (in Pascal
particularly, playing much the same role as the C '{' marker). In Ada,
loops are among the structures it is *not* used for. To my knowledge,
users of these languages don't suffer from confusion on this issue.

>> and because only 'begin' would be a keyword ('procedure' etc being
>> ordinary identifiers, which only have special meaning after the
>> 'begin' keyword) any new structure could be added without needing new
>> keywords or obscure operator combinations - old code would be safe
>> from at least one aspect of the evolution of the language.
>
>not true, unless the parser doesn't look at your code-block. Consider
>the 'yield' keyword. Older python-parsers produce a 'SyntaxError'. 
>If you would esacape that with 'begin yield' then the parsing process
>starts to loose a lot of meaning (apart from beeing very ugly).

By 'one aspect', I mean the identification of block structures, not
any special statements used inside the blocks. 'break', 'continue',
'return' and the like would need another mechanism to support
extensions without new keywords, if that was considered worthwhile.

However, in this alternative universe, there would be no need for
yield. The more sensible (IMHO) alternative would be to start
generators using 'begin generator (args)' and use the return statement
to return values from the generator.

>> So using perlish symbols isn't by any means my ideal - I just think
>> that in the long run there may already be a risk of serious creaping
>> perlishness (due to the resistance to adding new keywords)
>
>um, this sentence somewhat means that python is already perlish :-)

Yes. For instance, to determine whether a 'def' definition is for a
function or a generator, you cannot simply look at its definition -
you have to search the body to see if it contains 'yield' statements
or not and infer whether it is a generator from that. It is not
explicit from the start what you are dealing with, and it is therefore
a bit unclear and potentially misleading and confusing.

Seems a tad perlish to me :-(

Please note - this is not intended as a serious criticism. Generators
are a valuable addition to the language and, given the pre-existing
circumstances, this syntax had as much merit as any other. I'm simply
suggesting that, in an alternative universe where the language grammar
was designed to be easily extensible from the start, language
extensions such as generators might have been more easily and clearly
accomodated without creating compatibility issues.

>IMO the developer crew and especially GvR is very careful 
>with respect to language changes. I don't know if
>it would be possible to be even more conservative about
>language *syntax* so that older parsers would not choke
>on future extensions. 

I agree. Very much so. I just think that there might be a better path
than going through ever-increasing contortions to maintain
compatibility when extending the language.

-- 
Steve Horne
steve at lurking.demon.co.uk