[Tutor] Problems with genetically engineering the Print Ogre

[Remco Gerlich]

On  0, Scot Stevenson <scot@possum.in-berlin.de> wrote:
> Hello there, 
> 
> I have been learning Python for about half a year now, and there are two 
> parts of the language that feel "wrong" and do not have the instant, 
> instantly logical syntax that makes the rest of the language unbelievably 
> elegant: 
> 
> a) List comprehensions (aka "Ugly Stuff in Square Brackets")
> b) The extrended print statement (aka "The Print Ogre")
> 
> Neither "[<exp> for <var> in <seq> if <con>]" nor "print >> <file>, 
> <stuff>" are intuitive in the way that "if <con>:" or "for <var> in 
> <seq>:" are. They are, in fact, terribly confusing if Python is your first 
> language. Both create ugly spots of strange characters in code listings, 
> and I think both should be dragged outside and shot, or at least 
> genetically engineered to something that doesn't look like it has a "Made 
> by Frankenstein" stamp on the bottom. My first reaction to list 
> comprehensions was: How the hell did /that/ get past the beauty checker?

Personally I think list comprehensions are beautiful. It helps if you are
used to similar notation in math.

> 
> However, to finally get to the point of this mail, some of the saner ideas 
> in the PEP to the Print Ogre were vetoed by the BDFL himself. From PEP 214:
> 
> =====================================================
> 
>     The proposal has been challenged on the newsgroup.  One series of
>     challenges doesn't like '>>' and would rather see some other
>     symbol.
> 
>     Challenge: Why not one of these?
> 
>         print in stderr items,.... 
>         print + stderr items,.......
>         print[stderr] items,.....
>         print to stderr items,.....
> 
>     Response: If we want to use a special symbol (print <symbol>
>     expression), the Python parser requires that it is not already a
>     symbol that can start an expression -- otherwise it can't decide
>     which form of print statement is used.  (The Python parser is a
>     simple LL(1) or recursive descent parser.)
> 
>   =======================================================
> 
> This might be perfectly clear to Real Computer Scientists, but as one of 
> those people who is slightly more fluent in Mandarin than Recursive 
> Descent Parsing, I don't see why we can't at least change the Print Ogre 
> into something clean and instantly understandable like "print to <file>, 
> <stuff>", which would be the sort of syntax I would expect (actually, 
> "print <stuff> to <file>" would be even better, but sticking stuff at the 
> end would make this look like a German verb pattern; "print to <file>: 
> <stuff>" would be good, too, but break the rule about indentation after 
> ":", which I understand). 
> 
> Is there any chance one of the other Real Computer Scientists on this list 
> could explain what the problem is? 

The problem is that 'to' could also be the name of a variable.

Now a human could see the difference between, for instance:

print to, from
print to f: "Whee!"

And know that 'to' in the first is a variable, and part of the print in the
second.

But parsers receive tokens. It gets things like "print", "to", ",", "from"
as its input.

A LL(1) parser has a lookahead of 1. It gets to see the next token, and
using that it has to decide what it is parsing. These parsers are
conceptually very simple and quite fast, but of course a bit limited.

So after the "print", the parser sees "to" as the next word. It has to
decide whether that is a variable (actually, the start of an expression) or
part of the print statement, and it can't.

Something like "print + file, x" also doesn't work, since +file is perfectly
normal if file is some variable -- + can start an expression.

But in Python, no expression can start with >>, so it could be used.

This is slightly simplistic, but should be enough.
-- 
Remco Gerlich