On Thu, Sep 3, 2015 at 11:56 AM, Rowan Collins <rowan.coll...@gmail.com> wrote:
> Pavel Kouřil wrote on 03/09/2015 07:32:
>>
>> Amendment 2. Make the ~> operator non-associative
>
>
>> Why? Once you read documentation about how the operator works and what
>> it does, you will know it and writing the extra brackets seems
>> superfluos. And woudn't this complicate the parser even more? Also, if
>> you have no idea about functional programming whatsoever, this will be
>> hard to grasp in any syntax form, but the syntax isn't the problem in
>> that case (as I already said in previous email).
>
>
> Yeah, maybe this one is just me - I just find right-associativity really
> hard to read, whatever it's purpose. Maybe it's because I've only ever read
> left-to-right languages.
>
> As mentioned in a previous e-mail, when I look at "$a ~> $b ~> $c" it makes
> me think of a single chain where all the terms are somehow related, like "$a
> = $b = $c", rather than any kind of nesting. Maybe I'd get used to it, maybe
> it would be rare enough that I'd never need to.
Yeah, my guess is that most developers would use this just for more
simple array_map/array_filter/etc. usage, so you probably wouldn't
encounter this use case "in the wild" much.
But imagine having something like this (combined with your #3):
function partial($cb) { return ($left) ~> (($right) ~> $cb($left, $right)); }
I hope I got the parenthesination correct, because now there's a ton
of parenthesis and it's even harder to read (and write). If I had to
choose between amendments #3 and #2, I'd go with #3 just for the sake
of consistency - but I definitely wouldn't choose both of them
simultaneously.
But even just #3 seems kinda "harder" to read than the form without
any parenthesis.
function partial($cb) { return ($left) ~> ($right) ~> $cb($left, $right); }
I know the parenthesis are optional in just one scenario, but I'd
argue it's probably the most common one.
>> So you are taking a syntax that's supposed to be short and "clean" and
>> making it more complex by the amedments 3 and 4?
>
>
> No, I'm trying to think of compromises which address constructive criticisms
> people have made of the current proposal, such as the variety of syntax
> forms, and the implicit scoping of variables.
>
> To be clear, these are not demands or anything like that, just suggestions
> of how to move the discussion beyond "here's the proposal, take it or leave
> it".
>
Yes, I hope everyone is trying to move the discussion forwards,
because I would love to see this in some reasonable form in PHP.
In my personal order of "most reasonable" ammendments, it would be #1
> #3 > #2 > #4. The #1 I could even see getting positive feedback,
because for everything longer than one statement, people can use the
function () { ... } declaration (unlike in some other languages).
>
>> Btw. about your previous email and this syntax ending your career -
>> why would it?
>
>
> That wasn't my e-mail, it was one I replied to. I'm not against this
> proposal, I'm genuinely trying to find ways forward with it.
>
Oh, really sorry! I read a lot of those emails at the same time and
somehow got two emails mixed up together! :)
Regards
PK
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
