Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88110
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.220.46 as permitted sender)
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (1.0)
In-Reply-To: <BLU436-SMTP23396F66FB225F9F2365E17E2540@phx.gbl>
Date: Mon, 7 Sep 2015 17:55:51 -0700
Cc: =?utf-8?Q?Bj=C3=B6rn_Larsson?= <bjorn.x.larsson@telia.com>,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <869870EE-6FAD-41C2-9C77-1868667E4FAE@golemon.com>
References: <BLU436-SMTP13020F8CE8795C628BDC665E26B0@phx.gbl> <55EAB740.6080004@telia.com> <BLU436-SMTP18117F322FF7AF41A325E78E2560@phx.gbl> <55EC1B77.6080708@telia.com> <BLU436-SMTP90D8DBFC51F9EED4F7D0D0E2550@phx.gbl> <28335322-EF2C-487D-99A8-2A624CAEAD99@golemon.com> <BLU436-SMTP23396F66FB225F9F2365E17E2540@phx.gbl>
To: Bob Weinand <bobwei9@hotmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Short Closures
From: php@golemon.com (Sara Golemon)


On Sep 6, 2015, at 18:19, Bob Weinand <bobwei9@hotmail.com> wrote:
> Oh, I thought that feature to be Hack-only. Looks like I'm wrong and hence=
 looked at the wrong place. [I always heard Hack has short Closures, but nev=
er was told HHVM had them too...]

Semantics semantics semantics.
Short closures *are* only supported by HHVM in Hack mode (<?hh), not for PHP=
 files (<?php).

When I say "HHVM", I mean the runtime.  When I say Hack, I mean the language=
/syntax (or the offline type checker).  In practice, because PHP and Hack sy=
ntax are so similar, HHVM gets away with using a single parser for both.  Th=
is parser, as mentioned, is a descendant of PHP's parser.  Which is why I wa=
s suggesting that implementation details could flow backward to php-src.

> But as I see you use a T_LAMBDA_OP which is inserted by a token-pre-parser=
 before it's being analyzed by the real parser.

Yes, and I regard it as a hideous abomonation.  No offense taken for not imp=
orting that piece of...art.

> Wouldn't say we really could compare that. It's a lot of complication... I=
f I remember correctly, we had a similar reason back then to reject my initi=
al keywords as identifiers patch as it was using that type of approach.
> Honestly, a %glr-parser bison directive would look cleaner here. But I'm n=
ot sure if we want to go that route down as a LALR(1) has much more determin=
istic performance characteristics...

Josh Watzman, who's working on UVS for HHVM would have a few words to say ab=
out that.  None charitable to LALR parsers.  :)

-Sara