Re: [RFC] [Discussion] Short Closures
| From: | Sara Golemon | Date: | Tue, 08 Sep 2015 00:55:51 +0000 |
| Subject: | Re: [RFC] [Discussion] Short Closures | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-88110@lists.php.net to get a copy of this message | ||
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 never 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 syntax are so similar, HHVM gets away
with using a single parser for both. This parser, as mentioned, is a descendant of PHP's
parser. Which is why I was 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 importing that piece
of...art.
> Wouldn't say we really could compare that. It's a lot of complication... If I
> remember correctly, we had a similar reason back then to reject my initial 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 not sure if we
> want to go that route down as a LALR(1) has much more deterministic performance characteristics...
Josh Watzman, who's working on UVS for HHVM would have a few words to say about that. None
charitable to LALR parsers. :)
-Sara