Hello,
On Sun, 29 Nov 2020 13:39:37 +1300
Greg Ewing <greg.ew...@canterbury.ac.nz> wrote:
> On 29/11/20 4:14 am, Paul Sokolovsky wrote:
> >
> > On Fri, 27 Nov 2020 13:06:56 +1300
> > Greg Ewing <greg.ew...@canterbury.ac.nz> wrote:
> >
> > There was no mix-up on my side, and neither seems there was on
> > yours. Block-level scoping and const'ness are orthogonal, well
> > composable features.
>
> Someone (maybe not you) suggested "for const i = ..." as a way
> to address the problem of variable capture in for loops.
I proposed "for const". I didn't propose to use equal sign "=" in the
"for" ;-).
> The logic behind this seems to be:
>
> * If i is const, rebinding it each time round the loop
> is obviously impossible, therefore the loop body must be
> a new scope in which there is a different i for each
> iteration.
Please watch your terminology. Because it's exactly right, but
implications you make doesn't seem to match the terms. If something is
const, it means that you can't *assign* to it. However, the semantics
of "for" is that it executes the loop body with "i" *bound* to a new
value each time. This is pretty much corresponds to what you said a few
messages ago. Except you proposed to implement that literally, and
create a new cell for each new value of "i". What I propose is to take
advantage that binding of "i" is constant (indeed, formally const'ness
applies to binding, not to value bound to), which allows to optimize
away the need to create multiple cells.
> * Since i is const, we don't need to capture it as a variable,
> so as an optimisation we can just capture its value.
Right.
> But this makes constness and new scopes non-orthogonal,
> because there's no way to have a new scope for a variable
> without making it const, and no way to make a variable
> const without creating a new scope for it.
That's why we don't limit our discussion to just the case of the "for",
and consider it in wider language scope, to avoid temptation of choosing
a non-generic solution for just "for". But for the situation of "for",
we can "strike out" those generic cases which don't apply (well, don't
make much sense) to it. So, let's see the full matrix of the "plausible
world":
Case 1:
x = 123
for x in seq:
print(x)
# Possible, doesn't make much sense, but always has been there
x = 1
# Prints last item in "seq"
print(x)
Case 2:
x = 123
for let x in seq:
print(x)
# Possible, doesn't make much sense
x = 1
# Prints 123
print(x)
Case 3:
x = 123
for const x in seq:
print(x)
# Error
# Prints 123
print(x)
x = 1
So, in the plausible domain, there would be "for let", which would
introduce a loop variable as mutable (just like classical "for" does).
But again, it doesn't make much sense to assign to a loop control var
(it will be overwritten on the next loop iter). To emphasize the fact
that loop variable belongs to the loop statement (and not to a user), we
put our full bet on the "for const" syntax, and don't implement "for
let" at all.
But it's only part of the big picture, because we have (even if
eventually):
Case 4:
let x = 1
# Possible
x = 2
Case 5:
const x = 1
# Error
x = 2
> I also think that "const" is not an *obvious* solution
> to someone faced with the for-loop problem. They're not
> trying to reassign the variable anywhere, so there's no
> reason for constness to come to mind.
It will be much more obvious if there's a general (standalone) "const",
that's why I'm saying we can't really consider "for const" without just
"const" (even though implementation-wise, one could appear a version or
2 earlier).
And it's "pretty obvious" to someone who considered various choices and
saw pieces falling into their places. Also might be pretty obvious for
someone who used other languages. It's certainly not a replacement for
reading docs, tutorials, and changelogs.
>
> > "for const" on its
> > own doesn't make much sense (and neither "for new", i.e. adhoc
> > workaround for the "for" case).
>
> It's not so ad-hoc if "new" can be applied to any assignment.
So assuming conceptual part is clear(er), let's speak of raw words.
Among 3 of "new", "const", "let", considering the use as a *standalone*
keyword (as in "applied to any assignment") - "new" seems to be the
worst choice, sorry. Sorry but even I (a cautious guy) use "new" as a
variable name *often*. Yeah, we might address that with over-modern
parsers with exponential performance and memory usage, but I hope the
point is clear. Extra nag is that "new" is the well-known keyword in
other languages, with a different meaning (creating a new object).
I bet I never used "const" as a variable name, but on a bad day, I
could. Well, we'll need to deal with that (I vote for non-NP
solution!!1). There're not many viable alternatives. I guess we won't
take a pun from Rust for example with something like "immut".
"let" should be as safe as an introduction of a new keyword can be. In
no way I could use it as a variable name (because it's verb, not a
noun), though I bet grepping around will show us a few "let"
functions/methods. Another issue is that "let" may confuse people
regarding its (im)mutability, like it clearly does in the case of BDFL.
Well, I again don't see a viable alternative. A common "var" is also
widely used variable name in Python. Overall, this is a rare case when
I hang my hopes on JavaScript to save us from this dilemma.
> Also, if you think "for new" doesn't make sense, you're
> probably reading it incorrectly. The mental bracketing
> isn't "(for new) i", it's "for (new i)".
I'm much less tied to words than to concepts and implementation
details. So, when I say "for new", I mean "implementation which creates
a new cell on each iteration".
> This works with "new" and "const", because they're
> adjectives. But "let" isn't an adjective, so
> "for let i" doesn't make sense however you parse it.
So, stroke of luck for us that we don't need "for let", only "for
const".
>
> --
> Greg
--
Best regards,
Paul mailto:pmis...@gmail.com
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/TX4CDZUU7CA7CGCJQYQDPXCHDVBLXCX7/
Code of Conduct: http://python.org/psf/codeofconduct/
