Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105216
MIME-Version: 1.0
References: <CAF+90c9YZcrquGfS4h3x1a+codkCFLarAThsOXcN69RCTvbAFA@mail.gmail.com>
 <CAF+90c_keZTbMTuDO+9WRa53MsYxbNxkMO_pxGyymGnxCp691g@mail.gmail.com>
 <582b57dc-42a0-582b-9471-2ede97ba584a@telia.com> <CAF+90c-1uw-iuW9DAp4jukRehmZ11x=qMAEsAfEXEs5-A-pbig@mail.gmail.com>
 <CALKiJKoYwkrJdFbLCbLWTftDmPWSzZYS8AW3+WCG7+ny+g2mFg@mail.gmail.com>
 <CAMuFt-7b2t83qmJW_-eGo8kte4Vb07XQVYkf0FcJ=9FCyON=-g@mail.gmail.com>
 <9C232925-ECA1-4DB3-91A5-FE76C3BA1F4A@koalephant.com> <CAHN63oOq8mfJbNXP7rJb=4gR=SPiht-D1S1Q_Yj2qiJ4+edjfg@mail.gmail.com>
In-Reply-To: <CAHN63oOq8mfJbNXP7rJb=4gR=SPiht-D1S1Q_Yj2qiJ4+edjfg@mail.gmail.com>
Date: Wed, 10 Apr 2019 10:32:31 -0700
Message-ID: <CAHN63oMxYEkbZ+5=vq318d4oypNrpGM8f5yEsS99pKSSAPzN1A@mail.gmail.com>
To: Stephen Reay <php-lists@koalephant.com>
Cc: Robert Hickman <robehickman@gmail.com>, Rowan Collins <rowan.collins@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f13bff058630740b"
Subject: Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures
From: mo.mu.wss@gmail.com ("M. W. Moe")

--000000000000f13bff058630740b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

@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 <mo.mu.wss@gmail.com> wrote:

> 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 henc=
e
> a language contextual analysis step
> or what people call `static`.
>
> On Wed, Apr 10, 2019 at 2:35 AM Stephen Reay <php-lists@koalephant.com>
> wrote:
>
>>
>> > On 10 Apr 2019, at 15:59, Robert Hickman <robehickman@gmail.com> 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 edito=
r,
>> >> 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
>> > parsers like 'php parser', thus the cost is lower than initially
>> > apparent?
>> >
>> > --
>> > PHP Internals - PHP Runtime Development Mailing List
>> > To unsubscribe, visit: http://www.php.net/unsub.php
>> >
>>
>> This seems like a risky thing to assume =E2=80=9Cit=E2=80=99ll be fine=
=E2=80=9D about.
>>
>> I=E2=80=99d like to add my (non-voting) voice in favour of the `fn(=E2=
=80=A6)` syntax. I
>> don=E2=80=99t know that I=E2=80=99d get a lot of use out of short closur=
es anyway, but I=E2=80=99d
>> at least like it to remain readable on the occasion I might use them, or
>> (more likely) work on something where someone else uses them.
>>
>> I question (loudly) any view that less characters is automatically
>> improves readability. I=E2=80=99ve yet to see a project anywhere that su=
ffered
>> overrun or saw low productivity because developers were busy typing/read=
ing
>> parenthesis around argument lists or keywords.
>>
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>

--000000000000f13bff058630740b--