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.
Tom Worster wrote on 03/10/2015 21:33:
when the grammar starts with function(args), it seems the main
difference from existing grammar is to make the curly braces when
there's only one statement in the function block.
in other contexts i had the impression that things like
if (bool-expr)
Hey Levi,
Levi Morrison wrote:
I messaged the list about this feature before I had the RFC written up
for it. The RFC[1] is slightly different from what I proposed in the
previous thread, so please read the RFC to make sure you understand
what is being proposed before replying here.
Here's a sm
when the grammar starts with function(args), it seems the main
difference from existing grammar is to make the curly braces when
there's only one statement in the function block.
in other contexts i had the impression that things like
if (bool-expr) statement;
and similar were going out o
55 matches
Mail list logo
