Sounds like we're in violent agreement. :-)
On Monday, September 28, 2015, Random832 <random832@fastmail.com> wrote:
Guido van Rossum <guido@python.org> writes:
> I would at least define different classes for the uptalk versions.
>
> But my main complaint is using the parse tree as a spec at all
Like I said, I actually came up with that structure *before* seeing that
it mirrored a grammar element - it honestly seems like the most natural
way to embody the fact that evaluating it requires the whole context as
a unit and can short-circuit halfway through the list, depending on if
the 'operator' at that position is an uptalk version.
The evaluation given this structure can be described in pseudocode:
def evaluate(expr):
value = expr.atom.evaluate()
for trailer in trailers:
if trailer.uptalk and value is None:
return None
value = trailer.evaluate_step(value)
The code generation could work the same way, iterating over this and
generating whatever instructions each trailer implies. In CPython, The
difference between the uptalk and non-uptalk version would be that
immediately after the left-hand value is on the stack, insert opcodes:
DUP_TOP LOAD_CONST(None) COMPARE_OP(is) POP_JUMP_IF_TRUE(end), with the
jump being to the location where the final value of the expression is
expected on the stack.
Assuming I'm understanding the meaning of each opcode correctly, this
sequence would basically be equivalent to a hypothetical JUMP_IF_NONE
opcode.
I don't think a recursive definition for the structure would work,
because evaluating / code-generating an uptalk operator needs to have
the top-level expression in order to escape from it to yield None.
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
--
--Guido van Rossum (on iPad)