On Sep 6, 2015, at 18:19, Bob Weinand <bobw...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
