Re: [PHP-DEV] async/await - is future reserved words in PHP 7.x?

[Pierre Joye]

On Sep 28, 2015 11:53 PM, "Levi Morrison"  wrote:
>
> On Mon, Sep 28, 2015 at 9:17 AM, Thomas Hruska 
wrote:
> > On 9/28/2015 1:29 AM, S.A.N wrote:
> >>
> >> Are there any future plans for - async/await?
> >> This need to know now, not to use these words to constants, and class
> >> names...
> >
> >
> > async/await is the single greatest addition to modern application
> > development in the last 20 years.  Every language needs these features.
> > Microsoft completely solved the core problems surrounding multithreaded
> > programming with the concepts behind these two keywords.
>
> While not disputing this claim I think PHP should only reserve words
> when there are somewhat concrete plans for their use. There have been
> talks and draft RFCs for things like void returns and union types with
> Foo | null, so reserving `void` and `null` makes sense. Perhaps there
> is a massive effort somewhere off-list but I am not aware of any plans
> on implementing async/await in PHP.
>
> If you are worried about them becoming reserved then simply do not use
> `async` and `await` as method, constant or class names. There ends the
> issue (in my opinion).

This model totally failed for us in the past. And given that these keywords
will be used for anything related to async APIs, let reserve them and put
our users on the safe side already.

Re: [PHP-DEV] async/await - is future reserved words in PHP 7.x?

[Levi Morrison]

On Mon, Sep 28, 2015 at 9:17 AM, Thomas Hruska  wrote:
> On 9/28/2015 1:29 AM, S.A.N wrote:
>>
>> Are there any future plans for - async/await?
>> This need to know now, not to use these words to constants, and class
>> names...
>
>
> async/await is the single greatest addition to modern application
> development in the last 20 years.  Every language needs these features.
> Microsoft completely solved the core problems surrounding multithreaded
> programming with the concepts behind these two keywords.

While not disputing this claim I think PHP should only reserve words
when there are somewhat concrete plans for their use. There have been
talks and draft RFCs for things like void returns and union types with
Foo | null, so reserving `void` and `null` makes sense. Perhaps there
is a massive effort somewhere off-list but I am not aware of any plans
on implementing async/await in PHP.

If you are worried about them becoming reserved then simply do not use
`async` and `await` as method, constant or class names. There ends the
issue (in my opinion).

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Arrow function expressions in PHP

[Levi Morrison]

On Sat, Sep 26, 2015 at 10:17 AM, Levi Morrison  wrote:
> (Email in gist format:
> https://gist.github.com/morrisonlevi/fa7984c04ff176b5a87c)
>
> In EcmaScript 2015 (ES6) the expression `(x) => x * 2` means to create
> an anonymous function with one parameter `x` that will return `x * 2`.
> For example:
>
> (x) => x * 2
> // is equivalent to:
> function(x) { return x * 2; }
>
> A modified example from [documentation by Mozilla Developer
> Network][1] page demonstrates how they are useful:
>
> var a = [
> "Hydrogen",
> "Helium",
> "Lithium",
> "Beryl­lium"
> ];
>
> var a2 = a.map(function(s){ return s.length }); // pre-ES6
>
> var a3 = a.map((s) => s.length); // ES6
>
> There has been some talk about how we can use arrow function
> expressions in PHP. In PHP using the same syntax would have some
> ambiguities:
>
> // Does this mean:
> //   1. Create an array key with the result of `($x)` and a value
> with `$x * 2`
> //   2. Create an array with one value that is an anonymous function
> [($x) => $x * 2]
>
> // Does this mean:
> //   1. Yield a key with the result of `($x)` and a value with `$x * 2`
> //   2. Yield an anonymous function
> yield ($x) => $x * 2;
>
> This is why Bob Weinand [proposed][2] using `~>` instead of `=>`.
> However, if we allow type declarations there is another issue. In the
> definition `(Type &$x) => expr` the `(Type &$var)` part can parse as
> "take constant `Type` and variable `$var` and do a bitwise and `&`
> operation." After that the `=>` will be an unexpected token. Even
> though the rule would be invalid the parser doesn't know that far
> ahead it will error and it doesn't know which rule to pick. Changing
> the token from `=>` to `~>` doesn't affect this issue.
>
> We could solve the first ambiguities with prefering the current
> meaning with `key => value` and requiring the meaning with closures to
> wrap them in `()`. We could solve the latter ambiguity with a
> backtracking parser since it will eventually error and then know to
> pick the other rule. However, I really think this is a bad idea.
>
> So how can we have shorter closures without this mess? One simple way
> is to require the `function` prefix:
>
> // clearly an array with an anonymous function
> [function($x) => $x * 2];
>
> // clearly yields an anonymous function
> yield function($x) => $x * 2;
>
> // clearly an anonymous function
> function(Type &$x) => expr;
>
> Requiring the `function` prefix mitigates one of the value parts of
> arrow functions: they are short.
>
> Another option would be to resolve the ambiguities with keys and
> values but to change the type information in parameters:
>
> (&$input: array) => expr
>
> By putting the type after the variable (similar to how we declare
> return types) we no longer have the issues with mis-parsing. Of
> course, that's not how we declare parameter types currently. I think
> we would need to permit it everywhere and deprecate the current syntax
> with the type being prefixed. (By deprecate I mean in PHP 8 and not
> remove it until PHP 9 or later)
>
> I would prefer that we shorten the `function` keyword to `fn`:
>
> [fn($x) => $x * 2]
>
> This preserves the shortness of the expression while providing
> unambiguous, simple parsing. Of course, now we have a similar issue:
> we have both `fn` and `function`.
>
> What concerns do you have about `fn($x) => $x * 2` or `function($x) =>
> $x * 2`? I will be writing a proper RFC later but I wanted to get
> discussion going now.
>
>   [1]: 
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions
>   [2]: https://wiki.php.net/rfc/short_closures

Bumping. I feel like perhaps people aren't aware that this is an
important conversation to have *right now* before the vote on
short_closures end. This is because depending on the interpretation of
the rules it may not be possible to have another vote on the short
closure idea for at least 6 months.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] async/await - is future reserved words in PHP 7.x?

[Björn Larsson]

Den 2015-09-28 kl. 18:53, skrev Levi Morrison:

On Mon, Sep 28, 2015 at 9:17 AM, Thomas Hruska  wrote:

On 9/28/2015 1:29 AM, S.A.N wrote:

Are there any future plans for - async/await?
This need to know now, not to use these words to constants, and class
names...


async/await is the single greatest addition to modern application
development in the last 20 years.  Every language needs these features.
Microsoft completely solved the core problems surrounding multithreaded
programming with the concepts behind these two keywords.

While not disputing this claim I think PHP should only reserve words
when there are somewhat concrete plans for their use. There have been
talks and draft RFCs for things like void returns and union types with
Foo | null, so reserving `void` and `null` makes sense. Perhaps there
is a massive effort somewhere off-list but I am not aware of any plans
on implementing async/await in PHP.

In the interview with Dmitry asynchronous behaviour was
mentioned as one key area for the future, see:
- 
https://blog.amasty.com/php-7-and-script-languages-future-insights-from-lead-zend-com-developer


Hope it materialises some day!

Regards //Björn


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Arrow function expressions in PHP

[Pavel Kouřil]

On Sat, Sep 26, 2015 at 6:17 PM, Levi Morrison  wrote:
> (Email in gist format:
> https://gist.github.com/morrisonlevi/fa7984c04ff176b5a87c)
>
> In EcmaScript 2015 (ES6) the expression `(x) => x * 2` means to create
> an anonymous function with one parameter `x` that will return `x * 2`.
> For example:
>
> (x) => x * 2
> // is equivalent to:
> function(x) { return x * 2; }
>
> A modified example from [documentation by Mozilla Developer
> Network][1] page demonstrates how they are useful:
>
> var a = [
> "Hydrogen",
> "Helium",
> "Lithium",
> "Beryl­lium"
> ];
>
> var a2 = a.map(function(s){ return s.length }); // pre-ES6
>
> var a3 = a.map((s) => s.length); // ES6
>
> There has been some talk about how we can use arrow function
> expressions in PHP. In PHP using the same syntax would have some
> ambiguities:
>
> // Does this mean:
> //   1. Create an array key with the result of `($x)` and a value
> with `$x * 2`
> //   2. Create an array with one value that is an anonymous function
> [($x) => $x * 2]
>
> // Does this mean:
> //   1. Yield a key with the result of `($x)` and a value with `$x * 2`
> //   2. Yield an anonymous function
> yield ($x) => $x * 2;
>
> This is why Bob Weinand [proposed][2] using `~>` instead of `=>`.
> However, if we allow type declarations there is another issue. In the
> definition `(Type &$x) => expr` the `(Type &$var)` part can parse as
> "take constant `Type` and variable `$var` and do a bitwise and `&`
> operation." After that the `=>` will be an unexpected token. Even
> though the rule would be invalid the parser doesn't know that far
> ahead it will error and it doesn't know which rule to pick. Changing
> the token from `=>` to `~>` doesn't affect this issue.
>
> We could solve the first ambiguities with prefering the current
> meaning with `key => value` and requiring the meaning with closures to
> wrap them in `()`. We could solve the latter ambiguity with a
> backtracking parser since it will eventually error and then know to
> pick the other rule. However, I really think this is a bad idea.
>
> So how can we have shorter closures without this mess? One simple way
> is to require the `function` prefix:
>
> // clearly an array with an anonymous function
> [function($x) => $x * 2];
>
> // clearly yields an anonymous function
> yield function($x) => $x * 2;
>
> // clearly an anonymous function
> function(Type &$x) => expr;
>
> Requiring the `function` prefix mitigates one of the value parts of
> arrow functions: they are short.
>
> Another option would be to resolve the ambiguities with keys and
> values but to change the type information in parameters:
>
> (&$input: array) => expr
>
> By putting the type after the variable (similar to how we declare
> return types) we no longer have the issues with mis-parsing. Of
> course, that's not how we declare parameter types currently. I think
> we would need to permit it everywhere and deprecate the current syntax
> with the type being prefixed. (By deprecate I mean in PHP 8 and not
> remove it until PHP 9 or later)
>
> I would prefer that we shorten the `function` keyword to `fn`:
>
> [fn($x) => $x * 2]
>
> This preserves the shortness of the expression while providing
> unambiguous, simple parsing. Of course, now we have a similar issue:
> we have both `fn` and `function`.
>
> What concerns do you have about `fn($x) => $x * 2` or `function($x) =>
> $x * 2`? I will be writing a proper RFC later but I wanted to get
> discussion going now.
>
>   [1]: 
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions
>   [2]: https://wiki.php.net/rfc/short_closures
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>


Hello,

personally, as a purely userland dev, I feel that the correct syntax
would be the "simplest" one - and that's imho the (Type &$x) ==> expr

Or the version with ~> operator - I don't care which one gets in,
althought I would rather see the ==> one. :)

I understand that there might be some ambiguity in the parser that
would need to be solved by backtracking, but for using the language,
the "simplest" option should IMHO be the correct one. Also not
introducing any more "stuff" (like new parameter types syntax) would
be a plus.

For the need to have a single parameter enclosed with ( ) - by
thinking more and more about it, I think that having the one special
case for not requiring parenthesis around parameters is pretty uselss,
since it would have to be there anyways if you wrote the typehint.

PS: the [fn($x) => $x * 2] seems ambigous, from reader's POV; key of
the item is result of fn($x) and value is $x * 2? Also, it would be a
huge BC break with not allowing you to name functions fn(), wouldn't
it?

--
Regards
Pavel Kouřil

--
PHP Internals - PHP Runtime Development Mailing List

Re: [PHP-DEV] [RFC] [VOTE] Short Closures

[Björn Larsson]

Den 2015-09-26 kl. 09:18, skrev Pavel Kouřil:

On Tue, Sep 22, 2015 at 3:59 AM, Bob Weinand  wrote:

Hey,

Thanks for all your feedback in the discussion thread!

So, before I start the vote, just two quick notes:
I've added two notes about the statement syntax and the single variable use.
Though a few people complained, I'm not switching to the ==> operator, as I 
noticed many people expected typehints to work (they don't due to parser 
limitations) when they compared to Hack's short Closures. It also allows us to 
differ syntax-wise [e.g. for typehints] from Hack without causing any confusion 
later. Which should be the smartest choice: Avoid conflicts. (If anyone strongly 
feels against that, he may vote no, but I would like to not bikeshed that in this 
Vote thread, but leave it free for eventual actual issues.)

Now, the link to the RFC about Short Closures:
https://wiki.php.net/rfc/short_closures
or straight ahead to the vote:
https://wiki.php.net/rfc/short_closures#vote

Thanks,
Bob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


Hello,

since the RFC doesn't look like it will pass, I have a question about
RFC process - will you be able to "fix" the RFC and submit it for vote
again with targeting PHP 7.1?

The biggest issues seem to be
- ~> operator instead of ==>
- missing type hints
- auto imports

If probably the first two would be resolved, then maybe the RFC could
get accepted? I personally don't understand the 3rd complain, since
having to use() everything would make it "not-so-short closures".

I also remember people not liking the option not to have parenthesis
with single parameter. I was thinking about this, and with the type
hints, it would be probably better anyways to have the ( ) required,
so that would be just a single use case where they wouldn't be
required - so is there a point in keeping this special use case?

Regards
Pavel Kouřil


A good strategy. Suspect that fixing type hints & reach consensus
on auto import or not is enough to make it pass, maybe also
parenthesis.

I don't think ~> or ==> is cruical but then I personally favour ~>
because I find it more distinct, not confusing it with => or <=>.
Also having ==> might lead the thought that functionality is like
== vs ===. Hm... or if someday in the future comparison operator
without type juggling is needed.

Regards //Björn Larsson


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Benchmark Results for PHP Master 2015-09-28

[lp_benchmark_robot]

Results for project php-src-nightly, build date 2015-09-28 05:13:35+03:00
commit: 250938e2d35fc54161a18167b7901c5e3b574371
revision_date:  2015-09-27 15:48:42+02:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 
2, LLC 45 MB
mem:128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

Baseline results were generated using release php-7.0.0beta3, with hash
1674bd9b151ff389fb8c9fc223bc6aafdd49ff2c from 2015-08-05 04:56:40+00:00

--
benchmark   relative   change since   change since
std_dev*   last run php-7.0.0beta3
--
:-)   Wordpress 4.2.2 cgi -T1  0.13%  0.00%  3.79%
:-|   Drupal 7.36 cgi -T1  0.59%  0.51%  1.93%
:-)   MediaWiki 1.23.9 cgi -T5000  0.41% -0.29%  5.38%
:-) bench.php cgi -T1  0.07% -0.04%  2.01%
:-|   micro_bench.php cgi -T1  1.10% -0.49% -0.17%
:-|mandelbrot.php cgi -T1  0.20%  0.01% -0.45%
--
Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in
fetches/second while all others are measured in seconds.
* Relative Standard Deviation (Standard Deviation/Average)

Our lab does a nightly source pull and build of the PHP project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] async/await - is future reserved words in PHP 7.x?

[Thomas Hruska]

On 9/28/2015 1:29 AM, S.A.N wrote:

Are there any future plans for - async/await?
This need to know now, not to use these words to constants, and class names...


async/await is the single greatest addition to modern application 
development in the last 20 years.  Every language needs these features. 
 Microsoft completely solved the core problems surrounding 
multithreaded programming with the concepts behind these two keywords.


+1 to reserving these keywords even though PHP isn't currently a 
multithreaded language.  IMO, PHP CLI is just as viable as PHP SAPI. 
And PHP CLI is where multithreaded functionality makes a lot more sense.


--
Thomas Hruska
CubicleSoft President

I've got great, time saving software that you will find useful.

http://cubiclesoft.com/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] More precise float value

[Yasuo Ohgaki]

Hi all and Ferenc,

On Mon, Sep 28, 2015 at 4:51 AM, Anatol Belski  wrote:
>> -Original Message-
>> From: jakub@gmail.com [mailto:jakub@gmail.com] On Behalf Of Jakub
>> Zelenka
>> > Exactly, so my question was - why it still needs to do "if (mode == 0)
>> > ndigit = 17;" in snprintf at the place I've linked? It won't have any
>> > effect as zend_dtoa will ignore it :)
>> >
>>
>> As I said in the PR some time ago, it's not used by dtoa for mode 0 but it's 
>> still
>> used by php_gcvt for checking if exponential or decimal notation should be
>> used. See
>>
>> https://github.com/php/php-
>> src/blob/250938e2d35fc54161a18167b7901c5e3b574371/main/snprintf.c#L163
>>
> Ah, I see it now. The patch is quite sparse, so have to check the whole 
> functions. Thanks for the explanations.
>
> For 7.0 raising the precision INIs to max supported were probably OK, but no 
> new INI options should be added. And IMHO, there should be only one INI 
> option change, and preferably full patch with json_precision in 7.1 and not 
> touching other branches (the simplest solution). As it seems, one sees it 
> critical to start using 17 digits in 7.0 - then probably vote were eligible 
> (whereby I wouldn't see it critical). But then IMHO - switch to 
> serialize_precision in 7.0 and keep the name for 7.1 with full patch. Though 
> please be aware that times are going fast, if you decide to put something 7.0 
> related to the vote, be sure the results stand till RC5.

Thank you for explanation, Jakub.

Ferenc, are you OK with the JSON serialize precision change?
i.e. Use PG(serialize_precision) rather than EG(precision) when
json_serialize() is called.
If yes, I'll prepare the patch and start the vote immediately.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] async/await - is future reserved words in PHP 7.x?

[S.A.N]

Are there any future plans for - async/await?
This need to know now, not to use these words to constants, and class names...

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Short Closures

[Arne Blankerts]

Hi,

On Sa, 2015-09-26 at 10:10 +0200, Pavel Kouřil wrote:
> On Sat, Sep 26, 2015 at 9:57 AM, Stanislav Malyshev  
> wrote:
> > Hi!
> >
> >> The biggest issues seem to be
> >> - ~> operator instead of ==>
> >> - missing type hints
> >> - auto imports
> >
> >
> Seems you are right it's not clear after all; I skimmed through all
> the e-mails in this thread and found only around 5 people stating that
> the ~> operator was their reason to vote "no"; while I was writing the
> previous e-mail, I really thought more people stated that here; on the
> other hand, we don't know why the rest of those ~30 people voted no,
> so it's really hard to say.

For what it's worth: My reasons to vote no were a) the general
readability, particularly when the parentheses are missing as well as
the choice of operator and b) the lack of type declarations. 
I can see the benefit of auto imports but consider it a break of
concepts (habit?) from everywhere else in PHP.

Regards,
Arne Blankerts

-- 
Those who do not understand Unix 
  are condemned to reinvent it, poorly (Henry Spencer,1987)


signature.asc
Description: This is a digitally signed message part

Re: [PHP-DEV] async/await - is future reserved words in PHP 7.x?

[Aaron Piotrowski]

Hello,

> On Sep 28, 2015, at 3:29 AM, S.A.N  wrote:
> 
> Are there any future plans for - async/await?
> This need to know now, not to use these words to constants, and class names...
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

As a few others have pointed out, the idea has certainly been discussed, but 
I’m not aware of any real progress toward integrating this into PHP in the near 
future. Implementing async/await in PHP is certainly possible, but will be no 
small task. I would love to see it in a 7.x release, but I’m thinking it might 
have to wait until 8 just because of all the changes that would be required.

I’ve created a library called Icicle (https://github.com/icicleio/icicle) that 
uses promises and generators to implement coroutines that use yield to 
interrupt execution of the coroutine until the promise is resolved. Combined 
with non-blocking I/O and concurrent execution implementations available in 
other packages designed for Icicle, you can create non-blocking and 
multi-threaded servers that are designed to be run from the CLI instead of the 
Apache SAPI, etc.

If you are not familiar with Icicle, I encourage you to take a quick look at 
the documentation, as the proceeding paragraph will make more sense if you 
understand how Icicle works.

I think the engine could use a similar strategy to that of Icicle for 
async/await. Async functions could return promises. Calling an async function 
with the await keyword would be similar to yielding a promise (or coroutine) 
within a coroutine in Icicle. If the await keyword is not used when calling an 
async function, this could be similar to calling Promise::wait() in Icicle, 
blocking control flow at that point until the promise is resolved. Perhaps in 
this way existing functions could be modified to support async/await while 
maintaining the existing blocking behavior when called without the await 
keyword.

Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Arrow function expressions in PHP

[Levi Morrison]

On Mon, Sep 28, 2015 at 3:38 PM, Pavel Kouřil  wrote:
> On Sat, Sep 26, 2015 at 6:17 PM, Levi Morrison  wrote:
>> (Email in gist format:
>> https://gist.github.com/morrisonlevi/fa7984c04ff176b5a87c)
>>
>> In EcmaScript 2015 (ES6) the expression `(x) => x * 2` means to create
>> an anonymous function with one parameter `x` that will return `x * 2`.
>> For example:
>>
>> (x) => x * 2
>> // is equivalent to:
>> function(x) { return x * 2; }
>>
>> A modified example from [documentation by Mozilla Developer
>> Network][1] page demonstrates how they are useful:
>>
>> var a = [
>> "Hydrogen",
>> "Helium",
>> "Lithium",
>> "Beryl­lium"
>> ];
>>
>> var a2 = a.map(function(s){ return s.length }); // pre-ES6
>>
>> var a3 = a.map((s) => s.length); // ES6
>>
>> There has been some talk about how we can use arrow function
>> expressions in PHP. In PHP using the same syntax would have some
>> ambiguities:
>>
>> // Does this mean:
>> //   1. Create an array key with the result of `($x)` and a value
>> with `$x * 2`
>> //   2. Create an array with one value that is an anonymous function
>> [($x) => $x * 2]
>>
>> // Does this mean:
>> //   1. Yield a key with the result of `($x)` and a value with `$x * 2`
>> //   2. Yield an anonymous function
>> yield ($x) => $x * 2;
>>
>> This is why Bob Weinand [proposed][2] using `~>` instead of `=>`.
>> However, if we allow type declarations there is another issue. In the
>> definition `(Type &$x) => expr` the `(Type &$var)` part can parse as
>> "take constant `Type` and variable `$var` and do a bitwise and `&`
>> operation." After that the `=>` will be an unexpected token. Even
>> though the rule would be invalid the parser doesn't know that far
>> ahead it will error and it doesn't know which rule to pick. Changing
>> the token from `=>` to `~>` doesn't affect this issue.
>>
>> We could solve the first ambiguities with prefering the current
>> meaning with `key => value` and requiring the meaning with closures to
>> wrap them in `()`. We could solve the latter ambiguity with a
>> backtracking parser since it will eventually error and then know to
>> pick the other rule. However, I really think this is a bad idea.
>>
>> So how can we have shorter closures without this mess? One simple way
>> is to require the `function` prefix:
>>
>> // clearly an array with an anonymous function
>> [function($x) => $x * 2];
>>
>> // clearly yields an anonymous function
>> yield function($x) => $x * 2;
>>
>> // clearly an anonymous function
>> function(Type &$x) => expr;
>>
>> Requiring the `function` prefix mitigates one of the value parts of
>> arrow functions: they are short.
>>
>> Another option would be to resolve the ambiguities with keys and
>> values but to change the type information in parameters:
>>
>> (&$input: array) => expr
>>
>> By putting the type after the variable (similar to how we declare
>> return types) we no longer have the issues with mis-parsing. Of
>> course, that's not how we declare parameter types currently. I think
>> we would need to permit it everywhere and deprecate the current syntax
>> with the type being prefixed. (By deprecate I mean in PHP 8 and not
>> remove it until PHP 9 or later)
>>
>> I would prefer that we shorten the `function` keyword to `fn`:
>>
>> [fn($x) => $x * 2]
>>
>> This preserves the shortness of the expression while providing
>> unambiguous, simple parsing. Of course, now we have a similar issue:
>> we have both `fn` and `function`.
>>
>> What concerns do you have about `fn($x) => $x * 2` or `function($x) =>
>> $x * 2`? I will be writing a proper RFC later but I wanted to get
>> discussion going now.
>>
>>   [1]: 
>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions
>>   [2]: https://wiki.php.net/rfc/short_closures
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
>
> Hello,
>
> personally, as a purely userland dev, I feel that the correct syntax
> would be the "simplest" one - and that's imho the (Type &$x) ==> expr
>
> Or the version with ~> operator - I don't care which one gets in,
> althought I would rather see the ==> one. :)
>
> I understand that there might be some ambiguity in the parser that
> would need to be solved by backtracking, but for using the language,
> the "simplest" option should IMHO be the correct one. Also not
> introducing any more "stuff" (like new parameter types syntax) would
> be a plus.
>
> For the need to have a single parameter enclosed with ( ) - by
> thinking more and more about it, I think that having the one special
> case for not requiring parenthesis around parameters is pretty uselss,
> since it would have to be there anyways if you wrote the typehint.

I do not think it is feasible to make the parser do backtracking or
anything of 

[PHP-DEV] Re: Windows OpCache bug fix

[Matt Ficken]

Great. The locking issue is fixed.

But, it sometimes still fails to reattach to the base address. Because of
ASLR, extra DLLs, etc... the existing base address may not be usable in
other processes that need to reattach. When I see this issue I'm creating a
series of processes (for test runs) and when a process fails to reattach,
it happens to all the following processes for a few minutes. ASLR waits a
few minutes before changing the randomized memory layout when creating a
new process. When this happens to production web sites, it often sounds
like this is the case, as the web site becomes unusable for a while.

Exiting when the base address can't be reattached to, is not a good way to
handle this case, even in a FastCGI scenario.

The contract for create_segments() is to reattach successfully or return
ALLOC_FAILED.


Option 1: change create_segments() contract and zend_shared_alloc_startup()
so that create_segments() can `disable` OpCache, possibly setting
zend_accel_globals.enable=false and adding additional checks. This
eliminates the benefit of using OpCache, likely for several processes,
causing a major performance drop for a web site.

Option 2: creating a backup, 2nd backup, etc... OpCache in this case. There
may be up to 6 OpCaches(5 backups) with 4 attempts each. This fix is
simpler.This allows processes to share a backup OpCache, a web site will
slow down only to compile the scripts again(at the expense of some
additional memory).

There have been some feature requests to be able to create separate
OpCaches anyway. Shared web hosters would like to have different OpCaches
for different sites, but this would require a new INI directive which is
too late to add for 7, and for machines that run different PHP builds.

This patch passes my functional, stress and performance tests.

I've added it to the PR 1536:
https://github.com/php/php-src/commit/7cbebc747e5c5f824a6e0336cc044ce4dc4c8f9f


Regards
-M


On Thu, Sep 24, 2015 at 1:29 AM, Dmitry Stogov  wrote:

> Ops, I forgot to revert the exit condition.
>
>
> http://git.php.net/?p=php-src.git;a=commitdiff;h=2d55e8c186ef1034c2af64478da8f23dbeb28be9
>
>
>
> On Thu, Sep 24, 2015 at 11:00 AM, Dmitry Stogov  wrote:
>
>> hi Matt,
>>
>> Thanks.
>> I also moved the exit condition to be before Sleep().
>> This should prevent race condition on last iteration (after unlocked
>> sleep process should try to reattach).
>> Committed to PHP-7.0 and master.
>>
>>
>> http://git.php.net/?p=php-src.git;a=commitdiff;h=262160e0e9919dce914df2f0643c4b16ca137454
>>
>> If this really works, we should backport this into php-5.* as well.
>>
>> Thanks. Dmitry.
>>
>> On Thu, Sep 24, 2015 at 8:34 AM, Matt Ficken 
>> wrote:
>>
>>> Ok, I have a new PR just to unlock around Sleep():
>>> https://github.com/php/php-src/pull/1536
>>>
>>> Just by unlocking around Sleep() the OpenFileMapping loop will work.
>>> Holding the lock in that loop will not only block detach_segments() in
>>> other PHP processes but also reattaching in accel_startup().
>>>
>>> Checking the base address used when this issue occurs during some of my
>>> stress testing, most of the time the base address used is the first in
>>> vista_mapping_base_set. Its typically the timing between the locking and
>>> mapped file operations between processes more often than the base address
>>> selection.
>>>
>>> Especially ASLR, also PECL DLLs, and other factors will still cause this
>>> issue occasionally, but this fixes a majority of my occurrences.
>>>
>>> Regards
>>> -M
>>>
>>>
>>> On Wed, Sep 23, 2015 at 2:04 AM, Dmitry Stogov  wrote:
>>>
 Hi Matt,

 It looks like with your patch, the same file may be mapped to different
 virtual addresses of different processes and this won't work.
 I think usage of vista_mapping_base_set[] in your patch is wrong.

 Do I understand properly, that zend_shared_alloc_unlock/lock_win32()
 around Sleep() is the main part of the patch?

 Please, next time, try to make PR diffs as small as possible (without
 messing real fix with formatting and rearranging changes).

 Thanks. Dmitry.



 On Wed, Sep 23, 2015 at 10:10 AM, Matt Ficken 
 wrote:

> I want to increase visibility for my PR 1531,
> https://github.com/php/php-src/pull/1531, my patch for fixing an
> intermittent OpCache issue on Windows.
>
> Details, etc... are on the PR.
>
> Regards
> -M
>


>>>
>>
>