Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88074
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <61.90.26858.306BCE55@pb1.pair.com>
References: <BLU436-SMTP13020F8CE8795C628BDC665E26B0@phx.gbl>
	<61.90.26858.306BCE55@pb1.pair.com>
Date: Mon, 7 Sep 2015 07:33:01 +0200
Message-ID: <CAB6YZuzgWUJWi+O3=kBf3YQvtpa6=dmFs6BBzKZ1uOW-cgW6Kg@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Re: [RFC] [Discussion] Short Closures
From: pajousek@gmail.com (=?UTF-8?Q?Pavel_Kou=C5=99il?=)

On Sun, Sep 6, 2015 at 11:54 PM, Andrea Faulds <ajf@ajf.me> wrote:
> 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 lik=
e a
> very poor choice compared to =3D=3D> (let's call it Hack's arrow).
>
> I think it's been mentioned that =3D=3D>, Hack's arrow, was thought to be=
 likely
> to be confused with =3D>, 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 =3D=3D> is a whole column wider. So, if there'=
s a
> smudge on the screen or something, you could still clearly distinguish =
=3D=3D>
> from =3D>. They're visually distinct, much like =3D, =3D=3D and =3D=3D=3D=
 are, which I'm
> sure any PHP programmer can tell apart.
>
> Second, =3D> is only used in very limited contexts. You can't use =3D> in=
 a
> normal expression or statement. You can't mistake ($t =3D=3D> $f =3D=3D> =
$t) for ($t
> =3D> $f =3D> $t) for long, because the latter would never be a valid expr=
ession.
> And in the contexts where =3D> does work, it's unlikely you'd be using a
> closure =E2=80=93 at least, I can't think of a case where you'd want to c=
reate a
> numeric array of closures using a literal.
>
> For those two reasons, I don't agree that confusing =3D=3D> with =3D> wou=
ld be a
> big problem.
>
> Now ~>, the squiggle arrow, was supposedly chosen to reduce the likelihoo=
d
> of confusion. However, I would argue that it is actually *more* likely to
> cause confusion. In this case the potential confusion would be with ->, t=
he
> 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 =3D> and =3D=3D> wouldn't.
>
> First, ~> visually takes up the same amount of space as ->, so if you hav=
e 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 bool=
ean
> values "true" and "false" in the lambda calculus: "true" is a function th=
at
> 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 usua=
lly
> 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 with=
out
> the ugliness issue: in some fonts, particularly Japanese ones, ~ is rende=
red
> at the top of the character box, like an overline. In such a font, ~> wil=
l
> not look like an arrow.
>
> You did mention that the HHVM team might find things easier if you chose =
~>
> instead of =3D=3D>, given Hack already has =3D=3D>. Surely, though, that =
only
> matters if =3D=3D> has different semantics in PHP and Hack, yet this prop=
osal
> matches Hack's implementation exactly, so far as I can tell. Also, it wou=
ld
> 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 =3D=3D> instea=
d of
> ~>.
>
> Thanks.
>
> --
> Andrea Faulds
> http://ajf.me/
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Hello,

these are all good points.

Also, I realized it's definitely harder to write ~ than =3D. On my
keyboard layout (Czech Qwerty) I have to do "right alt + shift + (key
above Tab)". I'm not sure how it is with other non-US keyboard
layouts, but it might be worth exploring before deciding on a symbol;
or maybe there's a possibility that my keyboard layout is just an
anomaly and you can write ~ on most keyboard layouts with a single key
(or double).

Regards
PK