Re: [RFC] [Discussion] Short Closures

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/