Hi Bob,
This has probably already come up, but I'd like to weigh in on the
symbol choice.
On the subject of syntax, ~> (let's call it the squiggle arrow) seems
like a very poor choice compared to ==> (let's call it Hack's arrow).
I think it's been mentioned that ==>, Hack's arrow, was thought to be
likely to be confused with =>, the key/value separator in array() and
foreach(). But I'd argue this is actually rather unlikely, for two reasons.
The first of these is that ==> is a whole column wider. So, if there's a
smudge on the screen or something, you could still clearly distinguish
==> from =>. They're visually distinct, much like =, == and === are,
which I'm sure any PHP programmer can tell apart.
Second, => is only used in very limited contexts. You can't use => in a
normal expression or statement. You can't mistake ($t ==> $f ==> $t) for
($t => $f => $t) for long, because the latter would never be a valid
expression. And in the contexts where => does work, it's unlikely you'd
be using a closure at least, I can't think of a case where you'd want
to create a numeric array of closures using a literal.
For those two reasons, I don't agree that confusing ==> with => would be
a big problem.
Now ~>, the squiggle arrow, was supposedly chosen to reduce the
likelihood of confusion. However, I would argue that it is actually
*more* likely to cause confusion. In this case the potential confusion
would be with ->, the object property dereference operator. I have two
reasons for why the two operators would be confused, and they're the
respective inverses of the reasons why => and ==> wouldn't.
First, ~> visually takes up the same amount of space as ->, so if you
have a small character size, a blurry or low-resolution screen, or poor
eyesight, there's nothing aside from the very slight curvature (and
maybe syntax highlighting, which does not yet exist) to distinguish ~>
from ->.
Second, ->, the object property dereference operator, is used in a wide
range of contexts. It's a valid expression (and thus statement), and so
would crop up in many places where ~>, the squiggle arrow, also would. A
realistic example of this is the Church Booleans, an encoding of the
boolean values "true" and "false" in the lambda calculus: "true" is a
function that takes two arguments and returns the first, and "false" is
a function that takes two arguments and returns the second. The "true"
function would be written, using squiggle arrows, as ($a ~> $b ~> $a).
Now, if you squint, can you tell that apart from ($a ~> $b -> $a)? Did
you even notice the difference in that second expression? (The second
squiggle arrow become a dereference operator.) I wouldn't be surprised
if you didn't. And the difference wouldn't always be immediately obvious
from context. Here, the unusual spacing might give it away (a variable
property access would usually be $b->$a), but not everyone is going to
put spaces around their squiggle arrows.
For those two reasons alone, I think ~> is a poor choice. And that's
without the ugliness issue: in some fonts, particularly Japanese ones, ~
is rendered at the top of the character box, like an overline. In such a
font, ~> will not look like an arrow.
You did mention that the HHVM team might find things easier if you chose
~> instead of ==>, given Hack already has ==>. Surely, though, that only
matters if ==> has different semantics in PHP and Hack, yet this
proposal matches Hack's implementation exactly, so far as I can tell.
Also, it would be nice if PHP and Hack don't diverge when implementing
the same features, unless there's a particularly good reason... it's not
very kind to people who use both languages.
So, to conclude, I would urge you to change the RFC to use ==> instead
of ~>.
Thanks.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
