Re: [RFC] [Discussion] Short Closures

From: 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

« previous php.internals (#88110) next »