Den 2019-04-17 kl. 16:14, skrev Larry Garfield:
On Sun, Apr 14, 2019, at 11:52 AM, Nikita Popov wrote:
So, there's been quite a bit of extra discussion here... unfortunately I
can't say that it really clarified anything, we're still circling around
different syntax choices, with the main conten
On Sun, Apr 14, 2019, at 11:52 AM, Nikita Popov wrote:
> So, there's been quite a bit of extra discussion here... unfortunately I
> can't say that it really clarified anything, we're still circling around
> different syntax choices, with the main contenders being fn, \ and ==>.
>
> fn($x) => $x
>
On Mon, Apr 15, 2019, at 6:48 AM, Benjamin Morel wrote:
> Even though I was originally hoping for something closer to JS syntax,
> considering Nikita's summary it looks like the best contender is still
> fn(), as originally proposed.
> At least it looks like a function indeed, to the uninitiated.
>
On Wed, Apr 17, 2019 at 11:23 AM Björn Larsson
wrote:
> Den 2019-04-14 kl. 18:52, skrev Nikita Popov:
> > On Mon, Apr 8, 2019 at 4:06 PM Nikita Popov
> wrote:
> >
> >> On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov
> wrote:
> >>
> >>> Hi internals,
> >>>
> >>> Motivated by the recent list compreh
Den 2019-04-14 kl. 18:52, skrev Nikita Popov:
On Mon, Apr 8, 2019 at 4:06 PM Nikita Popov wrote:
On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov wrote:
Hi internals,
Motivated by the recent list comprehensions RFC, I think it's time we
took another look at short closures:
https://wiki.php.ne
Den 2019-04-15 kl. 13:48, skrev Benjamin Morel:
Even though I was originally hoping for something closer to JS syntax,
considering Nikita's summary it looks like the best contender is still
fn(), as originally proposed.
At least it looks like a function indeed, to the uninitiated.
So FWIW, I t
> On 14 Apr 2019, at 23:52, Nikita Popov wrote:
>
> On Mon, Apr 8, 2019 at 4:06 PM Nikita Popov wrote:
>
>> On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov wrote:
>>
>>> Hi internals,
>>>
>>> Motivated by the recent list comprehensions RFC, I think it's time we
>>> took another look at short
Even though I was originally hoping for something closer to JS syntax,
considering Nikita's summary it looks like the best contender is still
fn(), as originally proposed.
At least it looks like a function indeed, to the uninitiated.
So FWIW, I think that a vote for the fn() syntax only still make
Den 2019-04-14 kl. 18:52, skrev Nikita Popov:
On Mon, Apr 8, 2019 at 4:06 PM Nikita Popov wrote:
On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov wrote:
Hi internals,
Motivated by the recent list comprehensions RFC, I think it's time we
took another look at short closures:
https://wiki.php.ne
On Mon, Apr 8, 2019 at 4:06 PM Nikita Popov wrote:
> On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov wrote:
>
>> Hi internals,
>>
>> Motivated by the recent list comprehensions RFC, I think it's time we
>> took another look at short closures:
>>
>> https://wiki.php.net/rfc/arrow_functions_v2
>>
>>
On Fri, Apr 12, 2019 at 4:27 PM Fabien S wrote:
>
>
> > On 12 Apr 2019, at 16:46, Theodore Brown wrote:
> >
> > On Thursday, April 11, 2019 at 10:22 AM Fabien S
> > wrote:
> >
> >> I really like the Haskell `\($x)` syntax, could someone confirm if
> >> it would possible to drop the parenthesis
> On 12 Apr 2019, at 16:46, Theodore Brown wrote:
>
> On Thursday, April 11, 2019 at 10:22 AM Fabien S wrote:
>
>> I really like the Haskell `\($x)` syntax, could someone confirm if
>> it would possible to drop the parenthesis (like `\$x`) if we have
>> one argument ?
>
> The RFC says this s
On Thursday, April 11, 2019 at 10:22 AM Fabien S wrote:
> I really like the Haskell `\($x)` syntax, could someone confirm if
> it would possible to drop the parenthesis (like `\$x`) if we have
> one argument ?
The RFC says this syntax is ambiguous without the parentheses, since
the `\` may also
On Thu, Apr 11, 2019 at 1:48 PM M. W. Moe wrote:
>
> @Benjamin Morel
>
> you must certainly have basic comprehension troubles; read me back; it is
> public; keep for yourself your
> emotional false projections to myself and infantile behaviors to yourself;
> I would never dare simply by following
@Benjamin Morel
you must certainly have basic comprehension troubles; read me back; it is
public; keep for yourself your
emotional false projections to myself and infantile behaviors to yourself;
I would never dare simply by following
the basic rules of education; maybe english grammar should intr
@Robert Hickman
yes somehow that's a valid conclusion; however, I can walk and talk; it
does not
bother me at all; I like distractions.
You have a nice day.
On Thu, Apr 11, 2019 at 9:38 AM Robert Hickman
wrote:
> @M. W. Moe If you don't like the java-isms you can ignore them to a
> large exten
@M. W. Moe If you don't like the java-isms you can ignore them to a
large extent, which I do. However in doing so you're going against the
grain and will end up writing a lot of stuff yourself. I do find it
weird how PHP has morphed so drastically from it's origins and also
wander why. If people wa
> why? if voicing reasonable criticisms is bothering you; then you should
do something else in life;
> because engineering is built on this `very` concept;
You're very welcome to challenge the "java impurities" that have been a
foundation of the language for 15 years—although you may better invest
@Fabien S
yes, I think you could remove decoration; but still lambda capture process
must
be clarified i.e iterating your ruleset; you don't want to capture every
scope variables.
On Thu, Apr 11, 2019 at 8:22 AM Fabien S wrote:
> Thanks a lot for all your efforts Nikita.
>
> I really like the
Thanks a lot for all your efforts Nikita.
I really like the Haskell `\($x)` syntax, could someone confirm if it would
possible to drop the parenthesis (like `\$x`) if we have one argument ?
Thanks in advance, regards
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
@Benjamin Morel
why? if voicing reasonable criticisms is bothering you; then you should do
something else in life;
because engineering is built on this `very` concept; I am not in the apex
or any emotional trend;
it does not interest me.
You have a good day!
On Thu, Apr 11, 2019 at 7:58 AM Benj
> yes php still suffers of
> it's java-like-transform; historically named php5;
> repeating the same design traps almost 20 years after it;
Maybe you could just switch to another language then, and bother another
mailing list?
On Thu, 11 Apr 2019 at 16:51, M. W. Moe wrote:
> @Stephen Reay
>
>
@Stephen Reay
i) Good for you!, if you say so must be the truth; yes php still suffers of
it's java-like-transform; historically named php5;
repeating the same design traps almost 20 years after it; and in the
real-life the most interesting inquiries about the language evolution are
blocked by thi
On Thu, 11 Apr 2019 at 00:43, Rowan Collins wrote:
>
> On 10 April 2019 21:56:41 BST, "Björn Larsson"
> wrote:
> >Could then the \($x) syntax be a good compromise between
> >readability & implementation?
>
This syntax does make sense to me, although only as I've seen it
before in Haskell, which
> On 11 Apr 2019, at 00:32, M. W. Moe wrote:
>
> I have never seen ML programmers being improductive;
Great. I’ve never seen a pig crash a plane, therefore all pilots should be pigs?
Given your previous comments regarding removing “java impurities” it’s hard to
take anything you suggest seri
On 10 April 2019 21:56:41 BST, "Björn Larsson"
wrote:
>Could then the \($x) syntax be a good compromise between
>readability & implementation?
Personally, I don't find it "more readable"; on the one hand, it's one
character shorter; on the other, it stands out less from everything else.
My per
Den 2019-04-10 kl. 10:39, skrev Rowan Collins:
On Tue, 9 Apr 2019 at 11:20, Nikita Popov wrote:
The ==> syntax is the other one I implemented (
https://github.com/php/php-src/pull/3945). The implementation is based on
lexer lookahead, which is ugly but still manageable. I haven't seen much
s
@Stephen Reay,
I have never seen ML programmers being improductive; that's because maybe
you witness people
unfit for it; math is less character and contextual i.e meanings change
according to environment;
it's fully readable to people fitted for it.
On Wed, Apr 10, 2019 at 10:18 AM M. W. Moe w
Hello,
this is not much the syntax which is problematic here but the implicit
lambda capture ruleset proposed; for that,
it would require (fully justified in this case) a preprocessing step hence
a language contextual analysis step
or what people call `static`.
On Wed, Apr 10, 2019 at 2:35 AM Ste
> On 10 Apr 2019, at 15:59, Robert Hickman wrote:
>
>> I'd just like to amplify this mention of 3rd party tooling: if we go with
>> something which requires complex lexer/parser rules, then every editor,
>> IDE, and static analysis tool will need to also work with that syntax.
>>
>
> Is this
I think that the RFC covers a great deal of possible syntaxes and their
tradeoffs.
`==>` requires *a lot* of changes to the current parser, and external
tooling as mentioned by Rowan.
It has not even been specified whether the `==>` syntax could land into PHP
7.4, or could require postponing to P
On Wed, 10 Apr 2019 at 09:59, Robert Hickman wrote:
> > I'd just like to amplify this mention of 3rd party tooling: if we go with
> > something which requires complex lexer/parser rules, then every editor,
> > IDE, and static analysis tool will need to also work with that syntax.
> >
>
> Is this
Hi, Gabriel,
On 10.04.19 10:33, Gabriel O wrote:
Those parentheses are important when having multiple argument
Please don't top post, thanks!
Thanks for pointing it out, I'm aware.
Still `===>` would better stand out to _me_ personally.
thanks,
- Markus
--
PHP Internals - PHP Runtime Devel
> I'd just like to amplify this mention of 3rd party tooling: if we go with
> something which requires complex lexer/parser rules, then every editor,
> IDE, and static analysis tool will need to also work with that syntax.
>
Is this actually a problem? Don't these tools make use of existing
parser
On Tue, 9 Apr 2019 at 11:20, Nikita Popov wrote:
> The ==> syntax is the other one I implemented (
> https://github.com/php/php-src/pull/3945). The implementation is based on
> lexer lookahead, which is ugly but still manageable. I haven't seen much
> support for this variant in this discussion t
Those parentheses are important when having multiple argument
On 10 April 2019 10:02:46 AM Markus Fischer wrote:
On 10.04.19 00:10, Robert Hickman wrote:
- $waithandles = $this->urls->map(fn($url) => $this->fetcher->fetch($url));
- $waithandles = $this->urls->map(\($url) => $this->fetcher->fe
On 10.04.19 00:10, Robert Hickman wrote:
- $waithandles = $this->urls->map(fn($url) => $this->fetcher->fetch($url));
- $waithandles = $this->urls->map(\($url) => $this->fetcher->fetch($url));
- $waithandles = $this->urls->map($url ==> $this->fetcher->fetch($url));
I would say that when lambda fu
and maybe one day if public, protected, private, interface, abstract i.e
java impurities are finally removed:
class bar
{
owned var $m_a : float = 0.0;
var $b : object = null;
fn foo(int $x, int $y) : int
{ return fn($x) [&$y] { $x * $y; }; }
owned fn bar() : void
{ retur
Hello,
for now what I see is a bit of everything:
- adding a contextual keyword/alias to function
- enforce by reference
- a lack of coherence
too mockups (I like the arrow idea but won't ever replace `use`
functionalities)
"keeping the unnecessary arrow"
class bar
{
public fn foo(int $x, i
Hi internals,
This is my first write to this list but I've been followed
your discussions quite a while ago. For a brief introduction,
my name is Kosit, I'm a programmer from Thailand and I've been using
PHP since version 3 (for a short period before moving to PHP4).
I'm a fan of `fn` syntax and
> - $waithandles = $this->urls->map(fn($url) => $this->fetcher->fetch($url));
> - $waithandles = $this->urls->map(\($url) => $this->fetcher->fetch($url));
> - $waithandles = $this->urls->map($url ==> $this->fetcher->fetch($url));
>
> I would say that when lambda functions occurs in function calls I
Den 2019-04-09 kl. 17:23, skrev Björn Larsson:
Den 2019-04-09 kl. 12:19, skrev Nikita Popov:
On Tue, Apr 9, 2019 at 8:56 AM Björn Larsson
wrote:
Den 2019-04-08 kl. 16:06, skrev Nikita Popov:
On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov
wrote:
Hi internals,
Motivated by the recent list c
Den 2019-04-09 kl. 12:19, skrev Nikita Popov:
On Tue, Apr 9, 2019 at 8:56 AM Björn Larsson
wrote:
Den 2019-04-08 kl. 16:06, skrev Nikita Popov:
On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov
wrote:
Hi internals,
Motivated by the recent list comprehensions RFC, I think it's time we
took
a
On Tue, Apr 9, 2019 at 8:56 AM Björn Larsson
wrote:
> Den 2019-04-08 kl. 16:06, skrev Nikita Popov:
>
> > On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov
> wrote:
> >
> >> Hi internals,
> >>
> >> Motivated by the recent list comprehensions RFC, I think it's time we
> took
> >> another look at short
Den 2019-04-08 kl. 16:06, skrev Nikita Popov:
On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov wrote:
Hi internals,
Motivated by the recent list comprehensions RFC, I think it's time we took
another look at short closures:
https://wiki.php.net/rfc/arrow_functions_v2
This is based on a previous
On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov wrote:
> Hi internals,
>
> Motivated by the recent list comprehensions RFC, I think it's time we took
> another look at short closures:
>
> https://wiki.php.net/rfc/arrow_functions_v2
>
> This is based on a previous (withdrawn) proposal by Levi & Bob.
On Fri, March 15, 2019 at 4:45 AM Josh Di Fabio wrote:
> I'd certainly be on board with the fn() syntax, but the backslash
> syntax has definitely grown on me. To me, all of the examples in
> Theodore's email are very readable and I find that the backslash makes
> it very easy to identify arrow f
On Thu, Mar 14, 2019 at 7:42 PM Theodore Brown wrote:
>
> On Thu, March 14, 2019 10:41 AM Nikita Popov wrote:
>
> > On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov wrote:
> >
> > > Hi internals,
> > >
> > > Motivated by the recent list comprehensions RFC, I think it's time we took
> > > another loo
On Thu, Mar 14, 2019, at 3:41 PM, Theodore Brown wrote:
> > As a small update, I've implemented a proof of concept that uses the ($x)
> > ==> $x * $multiplier syntax (or $x ==> $x * $multiplier for short) in
> > https://github.com/php/php-src/pull/3945. As mentioned in the RFC, this
> > requires s
On Thu, March 14, 2019 10:41 AM Nikita Popov wrote:
> On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov wrote:
>
> > Hi internals,
> >
> > Motivated by the recent list comprehensions RFC, I think it's time we took
> > another look at short closures:
> >
> > https://wiki.php.net/rfc/arrow_functions_v
On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov wrote:
> Hi internals,
>
> Motivated by the recent list comprehensions RFC, I think it's time we took
> another look at short closures:
>
> https://wiki.php.net/rfc/arrow_functions_v2
>
> This is based on a previous (withdrawn) proposal by Levi & Bob.
On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov wrote:
> Hi internals,
>
> Motivated by the recent list comprehensions RFC, I think it's time we took
> another look at short closures:
>
> https://wiki.php.net/rfc/arrow_functions_v2
>
> This is based on a previous (withdrawn) proposal by Levi & Bob.
52 matches
Mail list logo
