On 16/12/2025 11:25, Deleu wrote:
My conclusion here is exactly the opposite of yours because this
explanation makes `as` even more symmetrical now.
I haven't exactly reached the "opposite" conclusion. If anything, I've
now reached the conclusion that "as" and "=>" are both equally ambiguous
and easy to misinterpret.
As you've mentioned `foreach(new MyIterator as $iterator)` is not how
it works. An iterator *produces a value* that is assigned to the
variable after `as`. Symmetrically, `using(new ContextManager as
$context)` the ContextManager is also producing a value that is
assigned to the variable after `as`. The only difference is in the
keyword: foreach will loop, but using will not loop since
ContextManager is not an iterator.
That is certainly how I read it, having already been primed by mentions
of iterators in the Python design document.
However, Tim pointed out (as you say, it came up in a different thread)
that the "each" is doing important work in the phrasing "for each ...
as". (It occurs to me that PHP used to have an actual function called
each(), which gave you an item from an array.)
Without that hint, the "X as Y" could easily be misread as meaning that
X and Y are the same thing.
In plain English, "using the screwdriver as a hammer" means the
screwdriver and the hammer are the same object. In PHP, "use Foo as
Bar;" means Foo and Bar refer to the same class.
On 16/12/2025 15:59, Larry Garfield wrote:
Second, I find it fascinating that there's so many different mutually-incompatible
spins on what => means.
I think we're all engaging in a lot of post hoc rationalisation for a
bunch of syntax that's evolved haphazardly, with multiple inspirations.
I was particularly amused by this:
For the arrow function, it's kind of implied in the name ARROW
function that we would need a syntax in the lines of `fn () =>`.
It makes me imagine a Computer Science researcher named Dr. Arrow, who
invented a new kind of function, but didn't know how to write it until
their friend pointed out that their name would make a suitable pun.
In reality, I suspect there are at least two lines of origin:
1) The key => value syntax for arrays is pretty clearly inspired by
Perl, which was far and away the most popular web programming language
in the early 1990s.
In Perl, it's called the "fat comma", and (a => 'b') is actually a
synonym for ('a', 'b').
2) Using some form of "args arrow expression" for lambda functions comes
ultimately, I suspect, from Functional Programming languages. The "=>"
in match statements can probably be traced to there as well.
Notably, exactly what arrow is used varies from language to
language. CoffeeScript (created in 2009) has both "(args) -> expression"
and "(args) => expression" with different semantics;
JavaScript/ECMAScript basically adopted the "=>" version in 2015.
Meanwhile, C# added "(args) => expression" in 2007; Java added "(args)
-> expression" in 2014. Hack used "(args) ==> expression" but needed an
ugly parser implementation, and an early PHP proposal for "(args) ~>
expression" was rejected, so we ended up with "fn(args) => expression"
instead.
Ultimately, the thing that all the uses of "=>" have in common is some
reason to want an ASCII representation of an arrow, and the need to fit
it into the constrained space of an existing grammar.
The same is basically true of "as" - it's a nice short English word,
with multiple meanings. That's a blessing and a curse: a blessing,
because we can reuse it in different contexts without reserving more
words; a curse, because people might have different intuitions about
which meaning was intended.
Which brings me back to where I started this e-mail: my conclusion is
that neither "as" nor "=>" is clear and unambiguous. We could probably
pick either, and people would get used to it; or we could try for
something better.
Regards,
--
Rowan Tommins
[IMSoP]
