Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!goblin2!goblin.stu.neva.ru!newsfeed1.swip.net!uio.no!news.tele.dk!news.tele.dk!small.news.tele.dk!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Terry Reedy <tjreedy@udel.edu>
Subject: Re: Delayed evaluation of expressions [was Re: Time we switched to unicode?]
Date: Wed, 26 Mar 2014 20:44:17 -0400
References: <9daf0806-02de-4447-964c-c8f8953c23e5@googlegroups.com> <mailman.8485.1395719463.18130.python-list@python.org> <lgquvt$b7t$1@speranza.aioe.org> <281c8ce1-4f03-4e93-b5cd-d45b85e89e7e@googlegroups.com> <mailman.8489.1395721791.18130.python-list@python.org> <feab8d4b-2f00-4f5f-ba57-2815439faecc@googlegroups.com> <CAPTjJmra0bs_6TP1iHmT5Auc1dykqeLUskg674z5OAB+jHv86g@mail.gmail.com> <53314FC1.2010603@rece.vub.ac.be> <CAPTjJmoOvEt-umUW38nW_7==3pciwGiZdJv2zFsNw5Kf_dW_Sw@mail.gmail.com> <mailman.8512.1395743920.18130.python-list@python.org> <5331652c$0$29994$c3e8da3$5496439d@news.astraweb.com> <mailman.8514.1395747979.18130.python-list@python.org> <f7eef30a-5e4a-45ae-8bdf-44e79e5c401f@googlegroups.com> <53319e60$0$29994$c3e8da3$5496439d@news.astraweb.com> <mailman.8550.1395791763.18130.python-list@python.org> <53321b7e$0$29994$c3e8da3$5496439d@news.astraweb.com> <mailman.8562.1395808246.18130.python-list@python.org> <5332fae0$0$29994$c3e8da3$5496439d@news.astraweb.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
In-Reply-To: <5332fae0$0$29994$c3e8da3$5496439d@news.astraweb.com>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.8595.1395881083.18130.python-list@python.org>
Lines: 119
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:69157

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 =E2=88=91 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 =3D 2
 >>>>>        =E2=88=91(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'=20
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=20
current possibility I can think of. So I actually agree that "can't" is=20
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=20
change is one I would strongly oppose and I will try to explain more=20
clearly why.

[*When I qualify doc suggestions on the tracker with 'something like',=20
as I usually do, I mean something that conveys the same meaning. So I=20
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=20
three things it can do:
1a. compile it so that it is immediately executed when encountered at=20
runtime (let this be the default);
1b. compile it so that it is somehow saved for execution later or=20
elsewhere (the alternative of concern here);
1c. compile it for a different alternative, such as turning an implied=20
'get' operation into a 'set' operation.

2. A code writer who wants an alternative treatment for a particular=20
must somehow delineate the expresion with boundary markers that, in=20
context at least, also indicate the alternative treatment. There are,=20
broadly, two possibilities:
2a. Use a generic quotation mechanism that can be applied to any=20
expression most any place. I call this explicit quoting.
2b. Use the expression in a special form that the compiler knows about.=20
The special form must have begin-end markers of some sort. I call this=20
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=20
marks and lambda-<EndofLambda>, where <EndofLambda> is ',', ')',=20
<EndofLine>, or maybe something else. If these are not present, the=20
default immediate execution mode is used for expressions in function=20
calls that are not themselves marked for alternative treatment.

Python's special forms are statements. Each has its own pair of=20
delimiters. Assignments use <BeginningofLine> and '=3D'. 'For' loops use =

'for' and 'in'. Other statements use 'as' and usually <EndofLine>.

Statements and functions call are syntactically very distinct, so there=20
is little possibility of confusion. I consider this a major feature of=20
python and I would oppose breaking it.

Lisp, for instance, uses s-expressions for everything, including what=20
would either function calls or statements in Python. Special functions=20
implicitly quote some argument expressions, but not necessarily all,=20
while normal functions do not quote any. The only way to know is to=20
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=20
was not widely adopted and has been more or less superceded by macros.=20
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 :=3D 0;
       for k :=3D l step 1 until u do
          s :=3D s + ak;
       Sum :=3D s
    end;

If that is supposed to be real code that can be compiled, I see no way=20
for the comment to be true. Or is the mechanism limited to builtin=20
functions?

--=20
Terry Jan Reedy