lambda syntax

[Felix]

Go as a language made a choice to leave certain things out, because

there is other ways to solve them, I live without generics and am happy,

no while loop no problem and etc.

But am hoping that the entire Go community + Go team + who ever it may concern

that we all accept that we need a lambda syntax,

-----------

(input parameters) => expression

-----------

(x, y) => x == y

-----------

() => SomeMethod()

-----------

this will really help with things like

implementing linq like in go check https://github.com/ahmetalpbalkan/go-linq 

( https://groups.google.com/forum/#!topicsearchin/golang-nuts/lambda%7Csort:date%7Cspell:true/golang-nuts/L-kxltsynh0 )

Am looking at the lambda expression from C# http://msdn.microsoft.com/en-us/library/bb397687.aspx

this will make functional things nice in Go

implementing a map over a slice like 

arr := []int{2, 3, 4}

map(x => x * 2, arr)

simpler that

map(func(x int){ x * 2}, arr)

So please Command Pike don't tell me no :-)

[Rob Pike]

No. It's not a good fit with the rest of the language.

-rob

[Felix]

No. It's not a good fit with the rest of the language.

why not? more explanation  

[frou]

Come on now. If you've adopted Go, you presumably have some respect for the designers' judgement, so don't demand they must explain judgement calls.

[Ingo Oeser]

The proposal doesn't include a type for the lambda argument.

If they did, they might look like this:

thresholds := []temperature.Celsius{35, 36, 37}

fever(adjustment temperature.Celsius => adjustment + temperature.Celsius(2), thresholds)

Which look better as a function.

[Thomas Bushnell, BSG]

The only true lambda syntax looks like this:

(lambda (parameters) expression)

However, if you are willing  to tolerate:

(parameters) => expression

I don't see why you aren't willing to tolerate

func (parameters) { return expression }

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Ian Lance Taylor]

On Wed, Feb 5, 2014 at 10:10 AM, Felix <dotf...@gmail.com> wrote:
>

> But am hoping that the entire Go community + Go team + who ever it may
> concern
> that we all accept that we need a lambda syntax,

We do already have a lambda syntax, of course. In C#, as far as I
know, the syntax you mention is the only way to write a lambda. In Go
you can already get all the functionality of a C# lambda expression by
writing a function literal.

So I think what you are suggesting is syntactic sugar for a certain
special case of a function literal, namely one in which the types of
the parameters and results are inferred, and the body of the function
literal is a single expression that is returned.

Go is not a language that has a lot of syntactic sugar for constructs
that can be specified in another way, so there would need to be a
really compelling argument to support it--an argument somewhat more
compelling than "it would make some things a bit easier to write."

More importantly, the fact that the types must be inferred makes this
a complex construct to use in many places.

f := x => x + 1

What is the type of f? Of course we can make up a rule--but that rule
is additional complexity in the language that people have to
understand, so now we have a disadvantage countering the relatively
minor advantage (beyond the obvious disadvantage of needing to learn
an additional syntax).

I would also like a more convenient syntax for simple function
literals, but I don't see how to make it fit with Go as it stands
today.

One way to approach it might be to start from the disadvantage I
pointed out. Currently Go does type inference from right to
left--when the type of the left hand side of an assignment is omitted,
it can be inferred from the type of the right hand side. For untyped
constants Go does type determination from right to left--the type of
the left hand side of an assignment can be used to determine the type
of an untyped constant on the right hand side.

Perhaps we can invent an untyped function literal, and permit the type
of the left hand side to determine the type of the right hand side.
Then we could perhaps write something like

func map(func (int) int, []int) []int { /* body omitted */ */

map(func (x) { return x * 2 }, a)

Here the type of the function literal would be determined by the type
of the argument to map.

And the next obvious step would be to say if a function has a single
result parameter, the return statement may be implied by writing a
single expression as the last statement of the function. That would
permit
map(func (x) { x * 2 }, a)

I don't know how I feel about this. But in my opinion it would be a
more profitable approach than introducing syntactic sugar.

Ian

[Jesse McNelis]

On 06/02/2014 5:58 AM, "Felix" <dotf...@gmail.com> wrote:
>
>
>
>> No. It's not a good fit with the rest of the language.
>>
> why not? more explanation  

It's special syntax that needs to be defined, implemented, understood by everyone. But it only helps reduce the keystrokes for code that nobody writes. Thus it becomes some obscure syntax that people rarely see and have to look up in the spec every time they see it.

[Felix]

yeah for syntactic sugar , but it will be nice

and as a gopher I respect the language designers a lot

and their decisions, but sometimes you have to ask why.

well, we can close this issue.

[Starfish]

I for one think something like this would be highly desirable, in combination with generics. That would enable LINQ which is an awesome library, although some people hates everything coming out of Redmond.

[Jan Mercl]

On Thu, Feb 6, 2014 at 3:48 PM, Starfish <ahn...@rocketmail.com> wrote:
> I for one think something like this would be highly desirable, in
> combination with generics. That would enable LINQ which is an awesome
> library, although some people hates everything coming out of Redmond.

Just be patient. Once Go gets enough traction, Redmond will invent
Go#. I'm sure it will have generic LINQ lambdas among all of the other
bells and whistles.

-j

[Ian Lance Taylor]

On Thu, Feb 6, 2014 at 6:48 AM, Starfish <ahn...@rocketmail.com> wrote:
>
> I for one think something like this would be highly desirable, in
> combination with generics. That would enable LINQ which is an awesome
> library, although some people hates everything coming out of Redmond.

Let's be clear, though: this is just syntactic sugar. Go already has
lambda expressions.

Ian

[Felix]

Is very interesting how much gophers like syntactic SUGER.

[Felix]

yeah MSFT will always take the better things they can't spin from scratch

add things to it to call it something sharp or script

as in jscript, j# => c#, c++ amp and dos.

[chris dollin]

On 7 February 2014 12:15, Felix <dotf...@gmail.com> wrote:

Is very interesting how much gophers like syntactic SUGER.

I think they find it grues-ome.

Chris

--
Chris "no sweet Abbot" Dollin

[Matt Sherman]

Yes and no, re sugar. It's type inference, if we're talking about the case of passing a lambda as a parameter.

It's sugar in the same way that foo := bar(baz) is sugar, where foo doesn't require extra keystrokes to specify its type.

[Ian Lance Taylor]

On Fri, Feb 7, 2014 at 8:44 AM, Matt Sherman <mwsh...@gmail.com> wrote:
> Yes and no, re sugar. It's type inference, if we're talking about the case
> of passing a lambda as a parameter.
>
> It's sugar in the same way that foo := bar(baz) is sugar, where foo doesn't
> require extra keystrokes to specify its type.

Fair enough.

As I mentioned in a different message, it might be interesting to
consider type determination for function literals.

Ian

> On Thursday, February 6, 2014 7:32:35 PM UTC-5, Ian Lance Taylor wrote:
>>
>> On Thu, Feb 6, 2014 at 6:48 AM, Starfish <ahn...@rocketmail.com> wrote:
>> >
>> > I for one think something like this would be highly desirable, in
>> > combination with generics. That would enable LINQ which is an awesome
>> > library, although some people hates everything coming out of Redmond.
>>
>> Let's be clear, though: this is just syntactic sugar. Go already has
>> lambda expressions.
>>
>> Ian
>

[kam...@gmail.com]

I don't know how you can live without Generics but you can't live without Lambda expression. No Go Authors will not listen to anyone.
If I could(because of the project I am working on) I would never use a language like Go and would never look back. There are much better choices out there.

[Tyler Compton]

It's usually best to create a new thread instead of responding to one that's so old (more than three years in this case).

--

You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.