Delayed evaluation of expressions [was Re: Time we switched to unicode?]

[Terry Reedy]

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 
clearly why.

[*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

 > https://en.wikipedia.org/wiki/Jensen%27s_device

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;
       real ak;
       comment k and ak are passed by name;
    begin
       real s;
       s := 0;
       for k := l step 1 until u do
          s := s + ak;
       Sum := s
    end;

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 
functions?

-- 
Terry Jan Reedy