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
--
https://mail.python.org/mailman/listinfo/python-list
