Short lambda: she's back !

414 views
Skip to first unread message

David Elahee

unread,
May 31, 2015, 3:10:22 PM5/31/15
to haxe...@googlegroups.com

This is totally insufferable, I mean we did neither had jokes nor proposal nor manifesto for short lambdas during this Wwx.

So I propose we adopt like haskell notation which I find really nice :

Lambda.map( function(x,y) return x+y)

Would write

Lambda.map( \(x,y) x+y )

The function would always return void or the expression type based on the caller type, like dispatch getArgs.

It s simple, élégant, makes the coffee, smells like truffles and saves the world. So what do you think ?

Xoxo love yall !

Franco Ponticelli

unread,
May 31, 2015, 4:05:20 PM5/31/15
to haxe...@googlegroups.com
I knew I should have come, now I officially regret it! :)

In any case I would adopt the ES6 way just because I think our potential users might be more familiar with that:

Lambda.map((x,y) => x+y)

Beautiful!

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

Philippe Elsass

unread,
May 31, 2015, 4:19:20 PM5/31/15
to haxe...@googlegroups.com
Haha short lambdas are so last year ;)

That said, like Franco, my vote goes to copying ES6 when that makes sense for Haxe.
--
Philippe

Justin Donaldson

unread,
May 31, 2015, 5:39:49 PM5/31/15
to Haxe
Short lambdas never go out of style

Franco Ponticelli

unread,
May 31, 2015, 5:54:56 PM5/31/15
to Haxe
A new meme, awesome!

Ashiq A.

unread,
May 31, 2015, 11:29:05 PM5/31/15
to haxe...@googlegroups.com
+1 for ES6 format, which is similar to C# format, which makes it more accessible.

Daniel Glazman

unread,
Jun 1, 2015, 12:29:10 AM6/1/15
to haxe...@googlegroups.com
On 01/06/2015 05:28, Ashiq A. wrote:
> +1 for ES6 format, which is similar to C# format, which makes it more
> accessible.

Absolutely. ES6 format, please.

</Daniel>

David Elahee

unread,
Jun 1, 2015, 3:37:13 AM6/1/15
to haxe...@googlegroups.com
Oh es6 notation is so out of baroque...nevermind, if es6 can have short lambda let's still it. 

es6 for me too then !

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.



--
David Elahee


clemos

unread,
Jun 1, 2015, 4:03:22 AM6/1/15
to haxe...@googlegroups.com
es6 +1000

David Elahee

unread,
Jun 1, 2015, 4:58:27 AM6/1/15
to haxe...@googlegroups.com
For those who haven't seen the es6 features : https://github.com/lukehoban/es6features

I especially feel that we could steal arrows, maybe even destructuring. 

Dan Korostelev

unread,
Jun 1, 2015, 7:34:13 AM6/1/15
to haxe...@googlegroups.com
yay, giff short lambda plox. es6/C# looks obvious to anyone familiar with modern popular languages

воскресенье, 31 мая 2015 г., 22:10:22 UTC+3 пользователь David Elahee написал:

Benjamin Dubois

unread,
Jun 1, 2015, 8:18:10 AM6/1/15
to haxe...@googlegroups.com
​I'm sure there is a good reason for that, but I wonder why the notation isn't simply
(x,y){x+y}
​?​


--

Alexander Kuzmenko

unread,
Jun 1, 2015, 8:50:43 AM6/1/15
to haxe...@googlegroups.com
It s simple, élégant, makes the coffee, smells like truffles
And it looks like it is shouting "Zig Heil!": \(x,y)






воскресенье, 31 мая 2015 г., 22:10:22 UTC+3 пользователь David Elahee написал:

This is totally insufferable, I mean we did neither had jokes nor proposal nor manifesto for short lambdas during this Wwx.

Dan Korostelev

unread,
Jun 1, 2015, 10:02:12 AM6/1/15
to haxe...@googlegroups.com
Hahaha, you made my day!

понедельник, 1 июня 2015 г., 15:50:43 UTC+3 пользователь Alexander Kuzmenko написал:

David Peek

unread,
Jun 1, 2015, 10:19:57 AM6/1/15
to haxe...@googlegroups.com
Add your +1's here https://github.com/HaxeFoundation/haxe/issues/4268

Or, make a case against them of course. Surely this is some kind of democracy :)

David Peek

unread,
Jun 1, 2015, 12:51:28 PM6/1/15
to haxe...@googlegroups.com
So, if we can somehow prove that "most haxe users" want short lambdas Nicolas has said he'll consider it :D

Fernando Serboncini

unread,
Jun 1, 2015, 12:53:12 PM6/1/15
to haxe...@googlegroups.com
If it's just a vote thing. Yes so much to any of those syntax.

--

Ashiq A.

unread,
Jun 1, 2015, 1:10:53 PM6/1/15
to haxe...@googlegroups.com
I don't think it's about numbers.Nicolas has very strong opinions about what should and shouldn't go into a language. That's what drives features in Haxe.

He's mentioned in a number of other cases that he wants a core language that's small and easy to learn. Maybe the Haxe core won't change much in the future.

Instead of campaigning for another language change, maybe different solutions can work. Having a library of common, often-requested macros (and a really, really, really simple way to include them in any project -- maybe through HaxeLib?) could work.

But, someone has to develop (and maintain) such a thing for it to continue to be useful.

Franco Ponticelli

unread,
Jun 1, 2015, 1:14:20 PM6/1/15
to haxe...@googlegroups.com
YOU CANNOT DO REAL SHORT LAMBDAS WITH MACROS! :) you can get close but not close enough. Beside if the language doesn't evolve it is an issue now and more so in the future.

Fernando Serboncini

unread,
Jun 1, 2015, 1:15:16 PM6/1/15
to haxe...@googlegroups.com
Yeah, that was my previous impression too, that's why I was surprised by the numbers thing.

That said, simplicity and easiness to learn is a bit a matter of context, right?
And the argument that ES6 supports a version of it, means it will probably very soonish become an expected/reasonable part of (forbid me for putting it that way) JavaScript-like languages. 
Which could mean that it stops being a "weird obscure notation" and turning into a reasonably unsurprising thing.


Juraj Kirchheim

unread,
Jun 1, 2015, 1:18:20 PM6/1/15
to haxe...@googlegroups.com
On Mon, Jun 1, 2015 at 7:14 PM, Franco Ponticelli <franco.p...@gmail.com> wrote:
YOU CANNOT DO REAL SHORT LAMBDAS WITH MACROS! :) you can get close but not close enough. Beside if the language doesn't evolve it is an issue now and more so in the future.

This is a very vague statement. Define "real" and "close enough" ;) 

Juraj Kirchheim

unread,
Jun 1, 2015, 1:23:02 PM6/1/15
to haxe...@googlegroups.com
On Mon, Jun 1, 2015 at 7:10 PM, Ashiq A. <alibha...@gmail.com> wrote:
I don't think it's about numbers.Nicolas has very strong opinions about what should and shouldn't go into a language. That's what drives features in Haxe.

He's mentioned in a number of other cases that he wants a core language that's small and easy to learn. Maybe the Haxe core won't change much in the future.

Instead of campaigning for another language change, maybe different solutions can work. Having a library of common, often-requested macros (and a really, really, really simple way to include them in any project -- maybe through HaxeLib?) could work.

But, someone has to develop (and maintain) such a thing for it to continue to be useful.

I'd like to think that tink_lang is such a library. It has 4 years of history, it is lightweight, easy to use, thoroughly documented, field tested, actively maintained and now also available on haxelib. I'd be glad to hear any suggestions for possible improvements.

Best,
Juraj

Franco Ponticelli

unread,
Jun 1, 2015, 1:41:17 PM6/1/15
to haxe...@googlegroups.com
real: es6 style
close enough: support () => 1 and friends

--

Luca Mezzalira

unread,
Jun 1, 2015, 1:47:17 PM6/1/15
to haxe...@googlegroups.com
+1 ES6 format

Juraj Kirchheim

unread,
Jun 2, 2015, 2:54:29 PM6/2/15
to haxe...@googlegroups.com
On Mon, Jun 1, 2015 at 7:41 PM, Franco Ponticelli <franco.p...@gmail.com> wrote:
real: es6 style
close enough: support () => 1 and friends

With es6 you can have `x => y`, `(x, y) => z` or `() => 1`, while in Haxe you can have `x => y`, `[x, y] => z` or `[] => 1`, so it's all a matter of brackets vs. parens, nothing more, nothing less. If you are saying this makes all the difference between real and unreal, I very much doubt the definition is really helpful.

While I understand your frustration over the issue, this should not make you grasp for such straws. You wouldn't accept macros as a solution, even if it were possible to use the exact same syntax. Because you take the position that this should really be part of the standard language (as do I).

In all honesty, I don't care enough about it though. But I am genuinely concerned with the message the stubbornness over a trivial change sends to potential users and contributors :(

Best,
Juraj

Franco Ponticelli

unread,
Jun 2, 2015, 3:00:54 PM6/2/15
to haxe...@googlegroups.com
The syntax matters to me as I really think that using something "unconventional" like [] could rise more questions from new adopters and I don't see the point in scaring them away. If I could do the ES6 syntax with macros and if that would not require me to extend magic classes everywhere I would adopt it.

Still, you are right, the point is that I want short lambdas in the language and that the way the situation is (not) dealt with is unacceptable to me, and that is all :)

--

Zjnue Brzavi

unread,
Jun 2, 2015, 3:34:09 PM6/2/15
to haxe...@googlegroups.com
Still, you are right, the point is that I want short lambdas in the language and that the way the situation is (not) dealt with is unacceptable to me, and that is all :)

Please allow 2 more attempts:

1. Flattery

Nicolas lead many developers, with Haxe, to a realm where (comparatively) reasonably inclusive language decisions is a norm, in much the same way Einstein opened the door to quantum physics. Yet.. Einstein could not let go (even when all the quantum kids were complaining) and was dubbed "The Last Classical Physicist". If history will call Nicolas "The Last Non-Short Lambda User", remains to be seen.

2. Emotional appeal & saying thx

As the one who opened the door to user-contributed back-ends to the Haxe compiler (with the PHP target) and soon to be 365-day-Github-contribution-streak-holder, I cannot imagine a more fitting gift to Franco than to include the Haxe feature he has clearly been dreaming about for years. No other considerations need apply. On day 365, let us give Franco and Haxe short lambdas!

With much applause and peer pressure,
Zjnue

Ashiq A.

unread,
Jun 2, 2015, 3:40:58 PM6/2/15
to haxe...@googlegroups.com
Again, Nicolas already decided and discussed this again (and repeated today) that he's not interested in adding it to the core language right now. Approaching the problem from that perspective seems wasteful.

What other avenues do we see for this?

1) A macro for short lambdas. While it will not be the same as a language feature, it gets us most of the way there.
2) Forking Haxe itself to include this feature. This is a "true" solution (complete with PR back into core Haxe), but until and unless Nicolas can agree to accept it in, someone has to maintain this separate version.
3) (insert your other ideas here)

Personally, option #1 seems easier to me -- less code to write, less code to maintain (eg. with new versions of Haxe), and easy to ship and version (eg. as a haxelib library), and easy to dissolve if/when short lambdas get into the core language.

--Ashiq



Franco Ponticelli

unread,
Jun 2, 2015, 3:49:21 PM6/2/15
to haxe...@googlegroups.com
You are the man :)

clemos

unread,
Jun 3, 2015, 6:09:54 AM6/3/15
to haxe...@googlegroups.com
I don't think a macro solution would be viable:
Introducing such syntactic features using macros feels like (and probably is) a hack that a compiler upgrade could very easily break.
Say we implement a macro that takes [a,b] => { a + b; } 
and then for whatever reason this syntax becomes invalid for the compiler (or means something else) because of some other feature.
The party is over...
I've been playing with such stuff myself, it really feels like you exploit some leak in the language specs, really.

Drakim

unread,
Jun 3, 2015, 6:37:38 AM6/3/15
to haxe...@googlegroups.com
The shorthand function declaration (fat arrow function) will be arriving in JavaScript eventually. When it does, Haxe will pretty much have to adopt the same, or be branded as "lagging behind" and "old and verbose". Nobody is gonna enjoy switching over to Haxe when they realize that their easily readable and tightly organized JS code has to be embiggened because the "Haxe guys didn't like the arrow"

Daniel Glazman

unread,
Jun 3, 2015, 7:31:05 AM6/3/15
to haxe...@googlegroups.com
Agreed. And it will be branded as "reinventing the wheel" if it chooses
another syntax for the same feature.

</Daniel>

Juraj Kirchheim

unread,
Jun 3, 2015, 9:17:50 AM6/3/15
to haxe...@googlegroups.com
On Wed, Jun 3, 2015 at 12:09 PM, clemos <cl3...@gmail.com> wrote:
I don't think a macro solution would be viable:
Introducing such syntactic features using macros feels like (and probably is) a hack that a compiler upgrade could very easily break.
Say we implement a macro that takes [a,b] => { a + b; } 
and then for whatever reason this syntax becomes invalid for the compiler (or means something else) because of some other feature.
The party is over...
I've been playing with such stuff myself, it really feels like you exploit some leak in the language specs, really.

In that case, you must be doing it wrong. I have used it just that way in my day to day work for over two years now. It has not been an issue and will not break unless there are breaking changes made to the parser, which last happened with the Haxe 2 to Haxe 3 transition, which is what major releases are for.

I agree that this should become part of the standard language, but what what you are saying is based either on ignorance or dishonesty. You should not let your frustration get the best of you!

clemos

unread,
Jun 3, 2015, 9:31:45 AM6/3/15
to haxe...@googlegroups.com
Re-reading my post I can understand why you somehow take it as (not so constructive) criticism towards tink and your work.
It really was not intended, sorry about that.
Tink is great, and you're indeed more experienced than me on that matter, so I trust you.

It's just that I'm beginning to find the "it's not in the language, let's just do it with macros" argument kind of naive sometimes.
You can't deny that macro-powered features come with caveats, and are hardly comparable to actual language features.

Best,
Clément 

--

Juraj Kirchheim

unread,
Jun 3, 2015, 4:33:07 PM6/3/15
to haxe...@googlegroups.com
On Wed, Jun 3, 2015 at 3:31 PM, clemos <cl3...@gmail.com> wrote:
Re-reading my post I can understand why you somehow take it as (not so constructive) criticism towards tink and your work.
It really was not intended, sorry about that.
Tink is great, and you're indeed more experienced than me on that matter, so I trust you.

It's just that I'm beginning to find the "it's not in the language, let's just do it with macros" argument kind of naive sometimes.
You can't deny that macro-powered features come with caveats, and are hardly comparable to actual language features.

Oh no, this is not about tink or my work at all. It is about the "macros are such dark magic"-culture that I see again and again in this community. If you look at how much major Lisp dialects implement through macros alone, or even other languages build on their metaprogramming facilities (e.g. Ruby on Rails), you'll have a hard time maintaining the stance that this is not viable. Sure, there are some caveats with macros, but those can actually be tackled and the more people use macros, the more pressure there will be to do just that.

If Nicolas is giving us a hard time adding some things to Haxe, and macros allow it, then we should use the opportunity to produce tangible evidence that this works. I consider that a constructive way of exploring possible ways of extending the language and producing a pressure based not just on opinions, but actual experience.

We actually have this opportunity right here and right now, and if we can observably succeed by moving forward in this direction, it seems like the next logical step to take, because nobody can stop us from taking it. If we use this "loop hole" as you perceive it, to establish it as a common programming style in Haxe, this might work toward creating the leverage we need, and even if it's not enough to convince Nicolas, we'll have gotten pretty close to what we wanted in the first place.

That should of course not stop us to try driving a CONSTRUCTIVE debate to get this into the core language! ;)

Best,
Juraj

Philippe Elsass

unread,
Jun 3, 2015, 4:55:19 PM6/3/15
to haxe...@googlegroups.com
+1 Juraj

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.



--
Philippe

Ashiq A.

unread,
Jun 5, 2015, 4:06:33 PM6/5/15
to haxe...@googlegroups.com
So to confirm:

1) Is someone going to work on said macro?
2) Where will it live?

Is it going to be part of Tink (meaning you need to download the whole library) or separate?

--

Philippe Elsass

unread,
Jun 5, 2015, 5:58:13 PM6/5/15
to haxe...@googlegroups.com
Andreas did some dark magic here:
--
Philippe

Cauê Waneck

unread,
Jun 5, 2015, 6:31:50 PM6/5/15
to haxe...@googlegroups.com
2015-06-05 18:57 GMT-03:00 Philippe Elsass <philipp...@gmail.com>:
Andreas did some dark magic here:

That's nice. One thing though - if he creates several classes inside Slambda.hx, each containing a version of  `fn` with the expected number of parameters, he can overload them without the need of numbering them

Andreas Söderlund

unread,
Jun 6, 2015, 7:12:23 AM6/6/15
to haxe...@googlegroups.com
Thanks Cauê, I will update it. :) If you or anyone else have more feedback, please let me know. I've been using it a bit lately and it's nice to do things like

var emails = persons.filter.fn(person.email != null).map.fn(person.email);

Quite readable and understandable, don't you think?

/Andreas

Juraj Kirchheim

unread,
Jun 6, 2015, 9:20:12 AM6/6/15
to haxe...@googlegroups.com
On Fri, Jun 5, 2015 at 10:05 PM, Ashiq A. <alibha...@gmail.com> wrote:

Is it going to be part of Tink (meaning you need to download the whole library) or separate?


Currently, you will have to download the whole library. That is actually you will get 5 libraries with a total size of 3.5 KLOC. I think that's well worth it, but if you have suggestions on what bits to single out, we can gladly discuss them on the tink_lang tracker ;)

Juraj Kirchheim

unread,
Jun 6, 2015, 9:25:46 AM6/6/15
to haxe...@googlegroups.com
On Sat, Jun 6, 2015 at 1:12 PM, Andreas Söderlund <gaz...@gmail.com> wrote:
Thanks Cauê, I will update it. :) If you or anyone else have more feedback, please let me know. I've been using it a bit lately and it's nice to do things like

var emails = persons.filter.fn(person.email != null).map.fn(person.email);

I like the general approach in that it is very local, but I think the parameter auto detection will make your life unnecessarily hard. There's a whole lot of stuff to keep in mind, such as `true` and `false` which you're ignoring. Also what about `persons.filter.fn(someRegex.match(person.email))`? That will behave unexpectedly. I'd say that just going with `_` is good enough, e.g. `persons.filter.fn(someRegex.match(_.email))`, as that's completely explicit.

Andreas Söderlund

unread,
Jun 6, 2015, 11:02:47 AM6/6/15
to haxe...@googlegroups.com
Good points, surprises should be avoided so I'll make the default parameter "_" instead of autodetecting it. The only thing is that I think it looks a bit unattractive. :)
Reply all
Reply to author
Forward
0 new messages