named return parameter

[bubblebenj]

I was making the Go tour and found this http://tour.golang.org/#10 about Go (optional) named return parameter.

I've sometime thought that it would be nice to have such thing since it would make function body cleaner.

I'm not asking for any features, I just wonder why named return parameters are not common in programming languages.

There must be drawbacks ?

Any thoughts on that would be appreciated.

Ben

--
haXe - an open source web programming language
http://haxe.org

[sledorze]

self documenting code I can imagine..
however I find that not very elegant..

[blackdog]

On 11/16/2011 07:15 AM, sledorze wrote:
> self documenting code I can imagine..
> however I find that not very elegant..
>
>
> --
> View this message in context: http://haxe.1354130.n2.nabble.com/named-return-parameter-tp6999793p6999880.html
> Sent from the Haxe mailing list archive at Nabble.com.
>
I like the way Go does interfaces but the syntax reminds me of an april
fools prank a number of years ago on the python lists where a new
proposal for a perl/python merged syntax was put forward. Guess someone
saw the joke.

--
Simplicity is the ultimate sophistication. ~ Leonardo da Vinci


--
haXe - an open source web programming language
http://haxe.org

[Tarwin Stroh-Spijer]

You can easily use an object ie { x: 10, y: 50} and I don't think there's much overhead ...


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: [phone]
_______________________

On Wed, Nov 16, 2011 at 2:21 AM, blackdog <[hidden email]> wrote:

On 11/16/2011 07:15 AM, sledorze wrote:
> self documenting code I can imagine..
> however I find that not very elegant..
>
>
> --
> View this message in context: http://haxe.1354130.n2.nabble.com/named-return-parameter-tp6999793p6999880.html
> Sent from the Haxe mailing list archive at Nabble.com.
>

I like the way Go does interfaces but the syntax reminds me of an april
fools prank a number of years ago on the python lists where a new
proposal for a perl/python merged syntax was put forward. Guess someone
saw the joke.

--
Simplicity is the ultimate sophistication. ~ Leonardo da Vinci

--
haXe - an open source web programming language
http://haxe.org

--
haXe - an open source web programming language
http://haxe.org

[Juraj Kirchheim]

Actually, compared to return x, return { x: x } is far more expensive
on many platforms. You have:
1. an allocation of
2. an anonymous object (no overhead on dynamic platforms)
3. on which you access a field in order to get your result

On FlashPlayer 11 release, this is more than factor 20, even on the V8
this is still about 10, on neko it's down to 3.

Now this overhead may or may not be relevant, but it definitely is there.

On Wed, Nov 16, 2011 at 12:20 PM, Tarwin Stroh-Spijer
<[hidden email]> wrote:

> You can easily use an object ie { x: 10, y: 50} and I don't think there's
> much overhead ...
>
>
> Tarwin Stroh-Spijer
> _______________________
>
> Touch My Pixel
> http://www.touchmypixel.com/
> phone: [phone]
> _______________________
>
>
> On Wed, Nov 16, 2011 at 2:21 AM, blackdog <[hidden email]> wrote:
>>
>> On 11/16/2011 07:15 AM, sledorze wrote:
>> > self documenting code I can imagine..
>> > however I find that not very elegant..
>> >
>> >
>> > --
>> > View this message in context:
>> > http://haxe.1354130.n2.nabble.com/named-return-parameter-tp6999793p6999880.html
>> > Sent from the Haxe mailing list archive at Nabble.com.
>> >
>> I like the way Go does interfaces but the syntax reminds me of an april
>> fools prank a number of years ago on the python lists where a new
>> proposal for a perl/python merged syntax was put forward. Guess someone
>> saw the joke.
>>
>> --
>> Simplicity is the ultimate sophistication. ~ Leonardo da Vinci
>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org

[Tarwin Stroh-Spijer]

Oooh - yeah sorry, stupid of me. Sorry for the dis-info. The simplest thing that would be an optimization would be something like:

function getPoint():Int,Int

{

   return (10, 50); // the comma separates return values

}

myX, myY = getPoint();

To start with the compiler could just do the same kind of things as return {}, or an array, but you could optimize better with time.

I don't think that's confusing either, especially as it simply uses a comma between items for return type, return and setting vars.

Regards,


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: [phone]
_______________________

On Wed, Nov 16, 2011 at 3:52 AM, Juraj Kirchheim <[hidden email]> wrote:

Actually, compared to return x, return { x: x } is far more expensive
on many platforms. You have:
1. an allocation of
2. an anonymous object (no overhead on dynamic platforms)
3. on which you access a field in order to get your result

On FlashPlayer 11 release, this is more than factor 20, even on the V8
this is still about 10, on neko it's down to 3.

Now this overhead may or may not be relevant, but it definitely is there.

On Wed, Nov 16, 2011 at 12:20 PM, Tarwin Stroh-Spijer
<[hidden email]> wrote:
> You can easily use an object ie { x: 10, y: 50} and I don't think there's
> much overhead ...
>
>
> Tarwin Stroh-Spijer
> _______________________
>
> Touch My Pixel
> http://www.touchmypixel.com/
> phone: <a href="tel:%2B61%203%208060%205321" value="[phone]">[phone]
> _______________________
>
>
> On Wed, Nov 16, 2011 at 2:21 AM, blackdog <[hidden email]> wrote:
>>
>> On 11/16/2011 07:15 AM, sledorze wrote:
>> > self documenting code I can imagine..
>> > however I find that not very elegant..
>> >
>> >
>> > --
>> > View this message in context:
>> > http://haxe.1354130.n2.nabble.com/named-return-parameter-tp6999793p6999880.html
>> > Sent from the Haxe mailing list archive at Nabble.com.
>> >
>> I like the way Go does interfaces but the syntax reminds me of an april
>> fools prank a number of years ago on the python lists where a new
>> proposal for a perl/python merged syntax was put forward. Guess someone
>> saw the joke.
>>
>> --
>> Simplicity is the ultimate sophistication. ~ Leonardo da Vinci
>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org

--
haXe - an open source web programming language
http://haxe.org

[bubblebenj]

I was not talking about the multiple result parameters only about naming the result parameter in the function definition.

I find for instance

public static function j( _selector : String ) _jqElement : JQuery

{

_jqElement = new JQuery( _selector );

return;

}

(2) easier keep track of the return parameter than 

public static function j( _selector : String ) : JQuery

{

return new JQuery( _selector );

}

(3) and prettier than 

public static function j( _selector : String ) : JQuery

{

var _jqElement = new JQuery( _selector );

return _jqElement;

}

well it's not an example that shows anything but the syntax.

I think the most common case I think of such syntax is when debugging, I need to put breakpoint / trace on the return value and I end up using the (3) structure.

Ben

On Wed, Nov 16, 2011 at 12:20 PM, Tarwin Stroh-Spijer <[hidden email]> wrote:

You can easily use an object ie { x: 10, y: 50} and I don't think there's much overhead ...


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: <a href="tel:%2B61%203%208060%205321" value="[phone]" target="_blank">[phone]
_______________________

On Wed, Nov 16, 2011 at 2:21 AM, blackdog <[hidden email]> wrote:

On 11/16/2011 07:15 AM, sledorze wrote:
> self documenting code I can imagine..
> however I find that not very elegant..
>
>
> --
> View this message in context: http://haxe.1354130.n2.nabble.com/named-return-parameter-tp6999793p6999880.html
> Sent from the Haxe mailing list archive at Nabble.com.
>

I like the way Go does interfaces but the syntax reminds me of an april
fools prank a number of years ago on the python lists where a new
proposal for a perl/python merged syntax was put forward. Guess someone
saw the joke.

--
Simplicity is the ultimate sophistication. ~ Leonardo da Vinci

--
haXe - an open source web programming language
http://haxe.org

--
haXe - an open source web programming language
http://haxe.org

--
haXe - an open source web programming language
http://haxe.org

[Nicolas Cannasse]

Le 16/11/2011 13:41, Tarwin Stroh-Spijer a écrit :

> Oooh - yeah sorry, stupid of me. Sorry for the dis-info. The simplest
> thing that would be an optimization would be something like:
>
> function getPoint():Int,Int
> {
>     return (10, 50); // the comma separates return values
> }
>
> myX, myY = getPoint();
>
> To start with the compiler could just do the same kind of things as
> return {}, or an array, but you could optimize better with time.

It could only be optimized for platforms that supports multiple return
values, which only includes CPP so far (by returning a stack-allocated
structure).

Best,
Nicolas

--
haXe - an open source web programming language
http://haxe.org

[Juraj Kirchheim]

Actually I don't think example 1 is easier. It requires two statements
instead of one, plus one of them is an assignment, which should
generally be avoided.
Also please consider that haXe function bodies don't need to be blocks
(however the method you suggest basically requires blocks) and haXe
has an everything-is-an-expression approach, which makes it easy to
write any function body as a single return statement, or at least use
only one return statement per function body.

On Wed, Nov 16, 2011 at 1:50 PM, benjamin Dubois <[hidden email]> wrote:

> I was not talking about the multiple result parameters only about naming the
> result parameter in the function definition.
> I find for instance
> public static function j( _selector : String ) _jqElement : JQuery
> {
> _jqElement = new JQuery( _selector );
> return;
> }
> (2) easier keep track of the return parameter than
> public static function j( _selector : String ) : JQuery
> {
> return new JQuery( _selector );
> }
> (3) and prettier than
> public static function j( _selector : String ) : JQuery
> {
> var _jqElement = new JQuery( _selector );
> return _jqElement;
> }
> well it's not an example that shows anything but the syntax.
> I think the most common case I think of such syntax is when debugging, I
> need to put breakpoint / trace on the return value and I end up using the
> (3) structure.
> Ben
> On Wed, Nov 16, 2011 at 12:20 PM, Tarwin Stroh-Spijer
> <[hidden email]> wrote:
>>
>> You can easily use an object ie { x: 10, y: 50} and I don't think there's
>> much overhead ...
>>
>>
>> Tarwin Stroh-Spijer
>> _______________________
>>
>> Touch My Pixel
>> http://www.touchmypixel.com/
>> phone: [phone]
>> _______________________
>>
>>
>> On Wed, Nov 16, 2011 at 2:21 AM, blackdog <[hidden email]> wrote:
>>>
>>> On 11/16/2011 07:15 AM, sledorze wrote:
>>> > self documenting code I can imagine..
>>> > however I find that not very elegant..
>>> >
>>> >
>>> > --
>>> > View this message in context:
>>> > http://haxe.1354130.n2.nabble.com/named-return-parameter-tp6999793p6999880.html
>>> > Sent from the Haxe mailing list archive at Nabble.com.
>>> >
>>> I like the way Go does interfaces but the syntax reminds me of an april
>>> fools prank a number of years ago on the python lists where a new
>>> proposal for a perl/python merged syntax was put forward. Guess someone
>>> saw the joke.
>>>
>>> --
>>> Simplicity is the ultimate sophistication. ~ Leonardo da Vinci
>>>
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org

[Juraj Kirchheim]

This is indeed interesting. Especially if one could "spread out" the
return values on other calls:

       function getPoint():Int,Int { ... }
       function setPixel(color:Int, x:Int, y:Int):Void { ... }
       //and then:
       setPixel(0xFF00FF, getPoint());

On Wed, Nov 16, 2011 at 1:58 PM, Nicolas Cannasse
<[hidden email]> wrote:

> Le 16/11/2011 13:41, Tarwin Stroh-Spijer a écrit :
>>
>> Oooh - yeah sorry, stupid of me. Sorry for the dis-info. The simplest
>> thing that would be an optimization would be something like:
>>
>> function getPoint():Int,Int
>> {
>>    return (10, 50); // the comma separates return values
>> }
>>
>> myX, myY = getPoint();
>>
>> To start with the compiler could just do the same kind of things as
>> return {}, or an array, but you could optimize better with time.
>
> It could only be optimized for platforms that supports multiple return
> values, which only includes CPP so far (by returning a stack-allocated
> structure).
>
> Best,
> Nicolas
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org

[sledorze]

with currying and unifying tuples and method parameters you can come pretty close

setPixel(0x0FF)(getPoint())