Delayed evaluation of expressions [was Re: Time we switched to unicode?]
tjreedy at udel.edu
Thu Mar 27 01:44:17 CET 2014
I agree that we have not been understanding each other.
From you original post that I responded to:
>>>>> The thing is, we can't just create a ∑ function, because it doesn't
>>>>> work the way the summation operator works. The problem is that we
>>>>> would want syntactic support, so we could write something like this:
>>>>> p = 2
>>>>> ∑(n, 1, 10, n**p)
The initial misunderstanding is that I interpreted 'something like this'
more loosely than you meant it. So I wrote something that was 'something
like the above' to me but not to you. I interpreted 'something like'
semantically* whereas you apparently meant is syntactically. I added the
one or the other little marks needed to make the above work in python as
it is whereas your 'something like' excludes such marks or any other
current possibility I can think of. So I actually agree that "can't" is
correct in relation to what you meant, as opposed to what I understood.
Changing "can't" to "can" would requires a major change to Python. That
change is one I would strongly oppose and I will try to explain more
[*When I qualify doc suggestions on the tracker with 'something like',
as I usually do, I mean something that conveys the same meaning. So I
edited your call text to convey the intended meaning in Python.]
Lets start with things we should agree on. The first two are mostly not
specific to Python.
1. When a compiler encounters an expression in code, there are at least
three things it can do:
1a. compile it so that it is immediately executed when encountered at
runtime (let this be the default);
1b. compile it so that it is somehow saved for execution later or
elsewhere (the alternative of concern here);
1c. compile it for a different alternative, such as turning an implied
'get' operation into a 'set' operation.
2. A code writer who wants an alternative treatment for a particular
must somehow delineate the expresion with boundary markers that, in
context at least, also indicate the alternative treatment. There are,
broadly, two possibilities:
2a. Use a generic quotation mechanism that can be applied to any
expression most any place. I call this explicit quoting.
2b. Use the expression in a special form that the compiler knows about.
The special form must have begin-end markers of some sort. I call this
implicit quoting. If human readers do not know that a particular form is
a special form, they may have a problem understanding the code.
Python has 2 pairs of generic explicit delimiters: open-close quote
marks and lambda-<EndofLambda>, where <EndofLambda> is ',', ')',
<EndofLine>, or maybe something else. If these are not present, the
default immediate execution mode is used for expressions in function
calls that are not themselves marked for alternative treatment.
Python's special forms are statements. Each has its own pair of
delimiters. Assignments use <BeginningofLine> and '='. 'For' loops use
'for' and 'in'. Other statements use 'as' and usually <EndofLine>.
Statements and functions call are syntactically very distinct, so there
is little possibility of confusion. I consider this a major feature of
python and I would oppose breaking it.
Lisp, for instance, uses s-expressions for everything, including what
would either function calls or statements in Python. Special functions
implicitly quote some argument expressions, but not necessarily all,
while normal functions do not quote any. The only way to know is to
know, and I found it confusing and difficult to remember.
> Sum(i, 1, 100, V[i])
> In Algol60, this function call would:
> - pass the name "i" (not a string!) as the first argument;
> - pass 1 as the second argument;
> - pass 100 as the third argument;
> - pass the expression "V[i]" (not a string!) as the fourth argument
which depends for this operation on
I read the whole article, including the criticisms and the fact that it
was not widely adopted and has been more or less superceded by macros.
It did not answer the obvious question: suppose the call is Sum(i, l, h,
V[i]). How is the reader supposed to know that 'i' and 'V[i]' get quoted
and the other args do not? The article included
real procedure Sum(k, l, u, ak)
value l, u;
integer k, l, u;
comment k and ak are passed by name;
s := 0;
for k := l step 1 until u do
s := s + ak;
Sum := s
If that is supposed to be real code that can be compiled, I see no way
for the comment to be true. Or is the mechanism limited to builtin
Terry Jan Reedy
More information about the Python-list