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 !
--
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.
--
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.
--
It s simple, élégant, makes the coffee, smells like truffles
This is totally insufferable, I mean we did neither had jokes nor proposal nor manifesto for short lambdas during this Wwx.
--
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.
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.
--
real: es6 styleclose enough: support () => 1 and friends
--
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 :)
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.
--
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.
--
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.
--
Is it going to be part of Tink (meaning you need to download the whole library) or separate?
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 likevar emails = persons.filter.fn(person.email != null).map.fn(person.email);