Re: [PHP-DEV] An implementation of a short syntax for closures

[Ryan McCue]

Brian Moon wrote:
> Is typing really the bottleneck for developers these days? I must suck
> then. I spend most of my day thinking or waiting on version control,
> testing and deploy applications, not typing.

+1. I don't think reducing key strokes should be a goal at all, the goal
should be readability above all.

Having read the other responses on this topic, I have to agree that
there's no need for any short syntax, so -1 on the short syntax from me.

(Forgot to send this to the list; sorry for the duplicate Brian!)
-- 
Ryan McCue


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

Re: [PHP-DEV] An implementation of a short syntax for closures

[Paul Dragoonis]

On Thu, Aug 4, 2011 at 7:54 PM, dukeofgaming  wrote:
> On Thu, Aug 4, 2011 at 1:47 PM, Gwynne Raskind wrote:
>
>> On Thu, Aug 4, 2011 at 09:12, Antony Dovgal  wrote:
>> >>>  Btw, am I the only one to whom the proposed syntax seems kinda
>> >>> hieroglyphic?
>> >> No. I don't see at all why we need this, just like I don't see why we
>> >> needed an alternative (short) syntax for arrays. This kind of syntax
>> >> additions that add *no* functionality, should not be in PHP.
>> > Yes, I believe we should stop this stream of alternative syntax proposals
>> > and concentrate on fixing existing functionality instead of adding less
>> readable ways to do
>> > the same thing. I would really like to keep PHP code easily readable, not
>> to turn it into
>> > perl-ish write-only gibberish.
>>
>> 100% agreed, both about the cryptic nature of the proposed syntax and
>> the need to focus on fixing existing issues. Strong -1 on a new
>> syntax.

>
>
> Aye, just realized watching the |=> reminded me of perl... say, I think that
> is what an aneurysm feels like.
>

One of the downsides to a language like perl was its Readability,
fancy magic symbols and lack of readability in its source code. PHP
has the opposite, very clear and readable C-like code. If PHP moves
towards a more magic syntax language then it would be
counter-productive.

Closures are quirky enough to wrap your eyes/mind around. Making these
more cryptic is very counter-productive.

Like mentioned, the amount of typing is not a problem, its more so
waiting on things to transfer, commit..etc

Very big -1 for me on this one. Please don't let a plethora of PHP
devs release code with this syntax.

Regards,
Paul Dragoonis.

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

Re: [PHP-DEV] An implementation of a short syntax for closures

[dukeofgaming]

On Thu, Aug 4, 2011 at 1:47 PM, Gwynne Raskind wrote:

> On Thu, Aug 4, 2011 at 09:12, Antony Dovgal  wrote:
> >>>  Btw, am I the only one to whom the proposed syntax seems kinda
> >>> hieroglyphic?
> >> No. I don't see at all why we need this, just like I don't see why we
> >> needed an alternative (short) syntax for arrays. This kind of syntax
> >> additions that add *no* functionality, should not be in PHP.
> > Yes, I believe we should stop this stream of alternative syntax proposals
> > and concentrate on fixing existing functionality instead of adding less
> readable ways to do
> > the same thing. I would really like to keep PHP code easily readable, not
> to turn it into
> > perl-ish write-only gibberish.
>
> 100% agreed, both about the cryptic nature of the proposed syntax and
> the need to focus on fixing existing issues. Strong -1 on a new
> syntax.


Aye, just realized watching the |=> reminded me of perl... say, I think that
is what an aneurysm feels like.

Re: [PHP-DEV] An implementation of a short syntax for closures

[Gwynne Raskind]

On Thu, Aug 4, 2011 at 09:12, Antony Dovgal  wrote:
>>>  Btw, am I the only one to whom the proposed syntax seems kinda
>>> hieroglyphic?
>> No. I don't see at all why we need this, just like I don't see why we
>> needed an alternative (short) syntax for arrays. This kind of syntax
>> additions that add *no* functionality, should not be in PHP.
> Yes, I believe we should stop this stream of alternative syntax proposals
> and concentrate on fixing existing functionality instead of adding less 
> readable ways to do
> the same thing. I would really like to keep PHP code easily readable, not to 
> turn it into
> perl-ish write-only gibberish.

100% agreed, both about the cryptic nature of the proposed syntax and
the need to focus on fixing existing issues. Strong -1 on a new
syntax.

The current PHP syntax for closures is the second-best one I've ever
used, IMHO. Clear, readable, explicit. My all-time favorite syntax is
that favored by Objective-C:

^ [returntype] ([params]) { code; }

The compiler figures out at build time which lexical stuff to capture,
and in most cases can infer the optional return type. I'd kinda love a
^ (params) use (captures) { code; } syntax in PHP, but nothing any
less wordy than that, and I'd hardly consider it any kind of priority.

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

Re: [PHP-DEV] An implementation of a short syntax for closures

[Brian Moon]

From your blog post:
> All in all, I have tried to eliminate the syntax noise by
> reducing the key strokes in the the non-significant parts
> of the expression is typing time really the bottleneck for
> productivity

Is typing really the bottleneck for developers these days? I must suck 
then. I spend most of my day thinking or waiting on version control, 
testing and deploy applications, not typing.


Brian.
http://brian.moonspot.net


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

Re: [PHP-DEV] An implementation of a short syntax for closures

[Antony Dovgal]

On 08/04/2011 05:04 PM, Derick Rethans wrote:

On Thu, 4 Aug 2011, Victor Bolshov wrote:


 Btw, am I the only one to whom the proposed syntax seems kinda hieroglyphic?


No. I don't see at all why we need this, just like I don't see why we
needed an alternative (short) syntax for arrays. This kind of syntax
additions that add *no* functionality, should not be in PHP.


Yes, I believe we should stop this stream of alternative syntax proposals and 
concentrate
on fixing existing functionality instead of adding less readable ways to do the 
same thing.
I would really like to keep PHP code easily readable, not to turn it into 
perl-ish write-only gibberish.

--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime profiling for PHP

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

Re: [PHP-DEV] An implementation of a short syntax for closures

[Derick Rethans]

On Thu, 4 Aug 2011, Victor Bolshov wrote:

> Btw, am I the only one to whom the proposed syntax seems kinda hieroglyphic?

No. I don't see at all why we need this, just like I don't see why we 
needed an alternative (short) syntax for arrays. This kind of syntax 
additions that add *no* functionality, should not be in PHP.

Derick

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

Re: [PHP-DEV] An implementation of a short syntax for closures

[Victor Bolshov]

+1 - think everybody'd want their functions to be searchable and searching
for complex patterns like "(function)|(\|\=\>)" would really be a headache.
Btw, am I the only one to whom the proposed syntax seems kinda hieroglyphic?

2011/8/4 Antony Dovgal 

> On 08/04/2011 04:39 PM, Lazare Inepologlou wrote:
>
>>  ... ( $x ) =>  $x + 1 for example would be ambiguous if used in an array
>>> definition, but is otherwise the best in terms of readability.
>>>
>>
>>   ... people wanted an easy way to grep for function declarations
>>>
>>
>>
>> A new and unique operator (like the |=>  I have proposed) is a solution
>> that works because:
>>
>
> Please stop that, it's not funny anymore.
>
> --
> Wbr,
> Antony Dovgal
> ---
> http://pinba.org - realtime profiling for PHP
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] An implementation of a short syntax for closures

[Antony Dovgal]

On 08/04/2011 04:39 PM, Lazare Inepologlou wrote:

 ... ( $x ) =>  $x + 1 for example would be ambiguous if used in an array 
definition, but is otherwise the best in terms of readability.



 ... people wanted an easy way to grep for function declarations



A new and unique operator (like the |=>  I have proposed) is a solution
that works because:


Please stop that, it's not funny anymore.

--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime profiling for PHP

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

Re: [PHP-DEV] An implementation of a short syntax for closures

[Lazare Inepologlou]

> ... ( $x ) => $x + 1 for example would be ambiguous if used in an array 
> definition, but is otherwise the best in terms of readability.

> ... people wanted an easy way to grep for function declarations


A new and unique operator (like the |=> I have proposed) is a solution
that works because:
1. A lambda expression can be part of other expressions, like arrays.
Therefore, we cannot reuse =>, or ->.
2. Multiple lambda expressions can be chained. The operator must have
very low precedence and it be right associative.
3. Lambdas should be grep-able.


For those who would like to try other syntaxes that could work in PHP,
I suggest a simple and creative way to approach this. All we need is 3
operators:

  OP_A args OP_B lexical_vars OP_C expr

Operator OP_C ought to have the above properties (unique, low
precedence, right associative). On the other hand there are no
restrictions about OP_A and OP_B and we can reuse existing ones as
long as they don't conflict and they look nice.

:-)

Lazare INEPOLOGLOU
Ingénieur Logiciel



2011/8/4 Johannes Schlüter :
> On Thu, 2011-08-04 at 21:18 +1000, Ryan McCue wrote:
>> Lazare Inepologlou wrote:
>> > Thank you for your interest. This is just a proposal that I have tested and
>> > works. Of course, the final syntax can be different. Syntax is always a
>> > matter of taste :-)
>>
>> As much as I love the idea, I have to agree that using | doesn't really
>> make sense here and actually makes the readability worse, IMO. However,
>> I can't really think of a better operator. ( $x ) => $x + 1 for example
>> would be ambiguous if used in an array definition, but is otherwise the
>> best in terms of readability.
>
> If you go there you can also allow more complex statements and re-use
> symbols used to group statements, using a syntax like
>
>     ( $x ) { $x + 1; }
>
> Oh wait - now we've reached a point which was mentioned in this thread
> already "allow to drop the function keyword".
>
> Back when I proposed to drop "function" a key argument was that people
> wanted an easy way to grep for function declarations. I accepted the
> validity of that concern and think this might be a case here, too. The
> difference of these few characters is not that much but the keyword
> gives a clear guidance what's going on, else you might end up with a
> long list of random characters next to each other ...
>
> johannes
>
>
>

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

Re: [PHP-DEV] An implementation of a short syntax for closures

[Arvids Godjuks]

Oh, and I forgot one more thing:

As I read the internals, I noticed many times that PHP lexer is
somewhat limited in it's capabilities and sometimes the features are
dropped because of this issue.
It can be the case that the can be ambiguous and it will be just
impossible to add at this stage.

As Ryan McCue pointed out in his example - there can be a problem with
arrays. And so on. Use cases are not just limited to declaring a
lambda as a function callback or assigning it to a variable. Creatinx
syntax that just looks odd for the language like those | probably will
not be accepted by the community because it looks out of place.

my 2 cents

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

Re: [PHP-DEV] An implementation of a short syntax for closures

[Arvids Godjuks]

2011/8/4 Lazare Inepologlou :
> Hello everyone.
>
> I am new to the php-internals list. I have joined because I have
> implemented a feature that I would like to be included in the php
> language: a shorter syntax for lambdas. I am going to briefly present
> it here. Apologies for the long (and yet incomplete) e-mail. I am
> ready to write a more complete RFC in the wiki, however, I would
> appreciate having some directions for that. Do I have to ask for
> permission first? Is it open to anyone to submit an RFC?
>
> The stuff...

Absolutely against such a syntax. Just try to imagine that you have to
actually not only write code, but you have to edit it and it can be
written by someone else.

The syntax we have right now is a bit wordy (is there such a word? :)
), but it makes code easily readable and formatted. Consider
JavaScript - it has function keyword for lambdas and no one is
complaining. Besides it lets you to indent your code beautifully:

$a->select(function($x) {
return $x->getName();
});

Or like this:

call_some_function(
$param1,
$param2
function ($x, $y) {
return $x * $y;
}
);

And so on.

If you write it in one line - it will become ugly one way or other no
matter the syntax.
Just make a Live Template (or whatever it's called in your IDE) for
somethink like "labd" => function (#vars#) { #body } for auto-complete
and be happy.

Is PHP still going the KISS way? PHP does not have different syntax's
for same things except few exceptions witch make sense and didn't
allowed such additions in the past. Please, can I ask the core team to
stay on the same line in the future :)

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

Re: [PHP-DEV] An implementation of a short syntax for closures

[Johannes Schlüter]

On Thu, 2011-08-04 at 21:18 +1000, Ryan McCue wrote:
> Lazare Inepologlou wrote:
> > Thank you for your interest. This is just a proposal that I have tested and
> > works. Of course, the final syntax can be different. Syntax is always a
> > matter of taste :-)
> 
> As much as I love the idea, I have to agree that using | doesn't really
> make sense here and actually makes the readability worse, IMO. However,
> I can't really think of a better operator. ( $x ) => $x + 1 for example
> would be ambiguous if used in an array definition, but is otherwise the
> best in terms of readability.

If you go there you can also allow more complex statements and re-use
symbols used to group statements, using a syntax like

 ( $x ) { $x + 1; }

Oh wait - now we've reached a point which was mentioned in this thread
already "allow to drop the function keyword".

Back when I proposed to drop "function" a key argument was that people
wanted an easy way to grep for function declarations. I accepted the
validity of that concern and think this might be a case here, too. The
difference of these few characters is not that much but the keyword
gives a clear guidance what's going on, else you might end up with a
long list of random characters next to each other ...

johannes



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

Re: [PHP-DEV] An implementation of a short syntax for closures

[Ryan McCue]

Lazare Inepologlou wrote:
> Thank you for your interest. This is just a proposal that I have tested and
> works. Of course, the final syntax can be different. Syntax is always a
> matter of taste :-)

As much as I love the idea, I have to agree that using | doesn't really
make sense here and actually makes the readability worse, IMO. However,
I can't really think of a better operator. ( $x ) => $x + 1 for example
would be ambiguous if used in an array definition, but is otherwise the
best in terms of readability.

-- 
Ryan McCue


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

Re: [PHP-DEV] An implementation of a short syntax for closures

[Ivan Enderlin @ Hoa]

Hi all :-),

On 04/08/11 09:23, Rasmus Lerdorf wrote:

On 08/04/2011 12:08 AM, Lazare Inepologlou wrote:

$add = | $x |=>  | $y : $x |=>  $x+$y;

This does not seem to match the syntax of any language I know of so
people are going to have a hard time figuring out what this does. It's
not even clear that |=>  is a new operator there due to the dangling |,
which as you say conflicts with the regular | operator. Plus it is only
useful in one limited type of trivial closure usage.
This syntax reminds me the “block lambda syntax”, presented on the 
ECMAScript's wiki [1] about the future of ECMAScript6. It seems they 
tend to choose the “arrow function syntax” [2], which is more natural 
and more readable. You can found pros and cons on the wiki, along with a 
lot of use cases/examples (including rebinding this!).


For a quicker introduction to these two short syntaxes, I would suggest 
you to read the conference “FalsyValues” [3], from slide 31 to 36, 
recently given by Dmitry Soshnikov about the future of ECMAScript 6 (all 
the conference is a beauty, a must-read).



In PHP we try really hard not to invent new unfamiliar syntax. We try to
stick with things that have some basis in either the existing syntax or
in other popular languages that the average PHP developer might be
exposed to.
+1. It must be the result of a long reflection and we should get a large 
vote from the community before choosen one syntax.



Best regards.


[1] 
[2] 
[3] 



--
Ivan Enderlin
Developer of Hoa Framework
http://hoa.42/ or http://hoa-project.net/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



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

Re: [PHP-DEV] An implementation of a short syntax for closures

[Lazare Inepologlou]

Hello,

>> $add = | $x |=> | $y : $x |=> $x+$y;
> Not sure that it's really readable.

This is not the most trivial example. In my blog, there is a small
sub-section where I explain why this is more readable than an implementation
with the current syntax. See under "Readability" and "A more complicated
example".

http://linepogl.wordpress.com/2011/08/04/short-closures-for-php-an-implementation/

:-)


Lazare INEPOLOGLOU
Ingénieur Logiciel


Le 4 août 2011 10:50, Frédéric Hardy  a écrit
:

> Hello !
>
>> I've always thought that just supressing the "function" keyword could work
>> as a shorthand, i.e. having ([param1 [, param2 [, ...]]]){...}. Somewhat
>> similar to Ruby's lambda shorthand:
>> http://slideshow.rubyforge.org/ruby19.html#40
>>
>>
> Huge +1 for that.
> Code using closures will be more readable.
>
>> $add = | $x |=> | $y : $x |=> $x+$y;


>>> Not sure that it's really readable.
> Moreover, it's more Perl/Ruby way than PHP way.
>
> Best regards,
> Fred
>
> --
> 
> Frédéric Hardy : Architecte d'application/Admin. système/Ergonome
>   CV : http://blog.mageekbox.net/public/cv.frederic.hardy.pdf
> Blog : http://blog.mageekbox.net
>  Twitter : http://twitter.com/mageekguy
> 
>
>

Re: [PHP-DEV] An implementation of a short syntax for closures

[Lazare Inepologlou]

Good morning Rasmus,

Thank you for your interest. This is just a proposal that I have tested and
works. Of course, the final syntax can be different. Syntax is always a
matter of taste :-)


> it is only useful in one limited type of trivial closure usage

This trivial usage is actually the most common one. A single-return closure
can be used for sorting, mapping, filtering, lifting, folding, comparing,
validating, formatting, lazy-loading etc. which cover the majority of the
tasks a PHP programmer does everyday. The popular LINQ library is just an
example of the power of this kind of closures.

The only case that these closures are not useful is asynchronous
(event-driven) programming. However, PHP is single threaded and usually
delegates the user interface to javascript, and therefore, two major needs
for asynchronous programming are eliminated.



> In PHP we try really hard not to invent new unfamiliar syntax.

I have done some research before posting and it seems that the proposed
syntax is not at all uncommon. For example, here is the same comparer
written in a variety of languages:

Proposed for PHP:
| $x , $y |=> $x - $y

C#:
( x , y )=> x - y

Haskell:
\ x y -> x - y

Python:
lambda x y: x - y

OCaml, F#:
fun x y -> x - y

StandardML:
fn x y => x - y

There are many similarities here. In all of the above examples, there is no
return and no curly brackets. In addition, all expressions begin with a
token and separate the arguments from the returning expression with another
token.




Kind regards,


Lazare INEPOLOGLOU
Ingénieur Logiciel


2011/8/4 Rasmus Lerdorf 

> On 08/04/2011 12:08 AM, Lazare Inepologlou wrote:
> > $add = | $x |=> | $y : $x |=> $x+$y;
>
> This does not seem to match the syntax of any language I know of so
> people are going to have a hard time figuring out what this does. It's
> not even clear that |=> is a new operator there due to the dangling |,
> which as you say conflicts with the regular | operator. Plus it is only
> useful in one limited type of trivial closure usage.
>
> In PHP we try really hard not to invent new unfamiliar syntax. We try to
> stick with things that have some basis in either the existing syntax or
> in other popular languages that the average PHP developer might be
> exposed to.
>
> -Rasmus
>

Re: [PHP-DEV] An implementation of a short syntax for closures

[Frédéric Hardy]

Hello !

I've always thought that just supressing the "function" keyword could work
as a shorthand, i.e. having ([param1 [, param2 [, ...]]]){...}. Somewhat
similar to Ruby's lambda shorthand:
http://slideshow.rubyforge.org/ruby19.html#40
  

Huge +1 for that.
Code using closures will be more readable.

$add = | $x |=> | $y : $x |=> $x+$y;
  

Not sure that it's really readable.
Moreover, it's more Perl/Ruby way than PHP way.

Best regards,
Fred

--

Frédéric Hardy : Architecte d'application/Admin. système/Ergonome
   CV : http://blog.mageekbox.net/public/cv.frederic.hardy.pdf
 Blog : http://blog.mageekbox.net
  Twitter : http://twitter.com/mageekguy



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

Re: [PHP-DEV] An implementation of a short syntax for closures

[Stas Malyshev]

Hi!

On 8/4/11 12:31 AM, dukeofgaming wrote:

I've always thought that just supressing the "function" keyword could work
as a shorthand, i.e. having ([param1 [, param2 [, ...]]]){...}. Somewhat
similar to Ruby's lambda shorthand:
http://slideshow.rubyforge.org/ruby19.html#40


My opinion is that when almost any mix of alphanumeric and 
non-alphanumeric characters becomes a valid syntax in the language, it's 
taking it a bit too far :)

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

Re: [PHP-DEV] An implementation of a short syntax for closures

[dukeofgaming]

Hi,

I've always thought that just supressing the "function" keyword could work
as a shorthand, i.e. having ([param1 [, param2 [, ...]]]){...}. Somewhat
similar to Ruby's lambda shorthand:
http://slideshow.rubyforge.org/ruby19.html#40

Regards,

David

On Thu, Aug 4, 2011 at 2:23 AM, Rasmus Lerdorf  wrote:

> On 08/04/2011 12:08 AM, Lazare Inepologlou wrote:
> > $add = | $x |=> | $y : $x |=> $x+$y;
>
> This does not seem to match the syntax of any language I know of so
> people are going to have a hard time figuring out what this does. It's
> not even clear that |=> is a new operator there due to the dangling |,
> which as you say conflicts with the regular | operator. Plus it is only
> useful in one limited type of trivial closure usage.
>
> In PHP we try really hard not to invent new unfamiliar syntax. We try to
> stick with things that have some basis in either the existing syntax or
> in other popular languages that the average PHP developer might be
> exposed to.
>
> -Rasmus
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] An implementation of a short syntax for closures

[Rasmus Lerdorf]

On 08/04/2011 12:08 AM, Lazare Inepologlou wrote:
> $add = | $x |=> | $y : $x |=> $x+$y;

This does not seem to match the syntax of any language I know of so
people are going to have a hard time figuring out what this does. It's
not even clear that |=> is a new operator there due to the dangling |,
which as you say conflicts with the regular | operator. Plus it is only
useful in one limited type of trivial closure usage.

In PHP we try really hard not to invent new unfamiliar syntax. We try to
stick with things that have some basis in either the existing syntax or
in other popular languages that the average PHP developer might be
exposed to.

-Rasmus

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