sugar for functions?

classic Classic list List threaded Threaded
64 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

sugar for functions?

MarcWeber
Some popular languages have a way to write functions (lambdas) much
shorter than
  function (x) { return 3*x; }

Examples:

- Haskell
  \x -> 3 * x
  or
  (3 *)

- Ruby:
  def foo(x) x * 3 end
  it can do even better:
  {|x| 3}

-Scala:
  { case x of i => i * 3 }
  or
  (_ * 3)


By hiding the "function" text some DSLs look more notural. Example:
Scalatest:

  class StackSpec extends FlatSpec with ShouldMatchers {

    "A Stack" should "pop values in last-in-first-out order" in {
      stack.pop() should equal (2)
      stack.pop() should equal (1)
    }


Even Java can do this kind now by using xtext which is a DSL for writing
DSL's.

I personally think that this is more natural to write:

"my test ".shouldnt.throwException( functions(){
  throw "failure";
});

than the Assertions which is implemented in both: hxunit and unit.

A funny extension could be defining functions this way:
(a,b){"result"}      // << assume it returns something
(a,b):Void{"result"} // :Void makes this a function returning Void only

Same for classes. Why write function all the time? Its obvious that you
want a function, isn't it?

classs X{
  public static foo(a,b){ }
}

Of course I can make editors insert function, return etc (eg by using
templates). I'd still prefer not having to write them at all.

Have you already thought about sugaring functions in HaXe?

Marc Weber

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: sugar for functions?

Cauê W.
This was discussed some times in here, but never was adopted as it's considered a syntax sugar only.

I agree with you, though, that it would be much readable. maybe adding a short "fun" as a shorthand for "function", or using a => operator.

2010/8/1 Marc Weber <[hidden email]>
Some popular languages have a way to write functions (lambdas) much
shorter than
 function (x) { return 3*x; }

Examples:

- Haskell
 \x -> 3 * x
 or
 (3 *)

- Ruby:
 def foo(x) x * 3 end
 it can do even better:
 {|x| 3}

-Scala:
 { case x of i => i * 3 }
 or
 (_ * 3)


By hiding the "function" text some DSLs look more notural. Example:
Scalatest:

 class StackSpec extends FlatSpec with ShouldMatchers {

   "A Stack" should "pop values in last-in-first-out order" in {
     stack.pop() should equal (2)
     stack.pop() should equal (1)
   }


Even Java can do this kind now by using xtext which is a DSL for writing
DSL's.

I personally think that this is more natural to write:

"my test ".shouldnt.throwException( functions(){
 throw "failure";
});

than the Assertions which is implemented in both: hxunit and unit.

A funny extension could be defining functions this way:
(a,b){"result"}      // << assume it returns something
(a,b):Void{"result"} // :Void makes this a function returning Void only

Same for classes. Why write function all the time? Its obvious that you
want a function, isn't it?

classs X{
 public static foo(a,b){ }
}

Of course I can make editors insert function, return etc (eg by using
templates). I'd still prefer not having to write them at all.

Have you already thought about sugaring functions in HaXe?

Marc Weber

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


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: sugar for functions?

Andy Li
I think that's cool. There is similar planing for JS too: http://www.sitepoint.com/blogs/2010/07/02/shorter-javascript-function-statement/

On Sun, Aug 1, 2010 at 10:42 PM, Cauê Waneck <[hidden email]> wrote:
This was discussed some times in here, but never was adopted as it's considered a syntax sugar only.

I agree with you, though, that it would be much readable. maybe adding a short "fun" as a shorthand for "function", or using a => operator.

2010/8/1 Marc Weber <[hidden email]>

Some popular languages have a way to write functions (lambdas) much
shorter than
 function (x) { return 3*x; }

Examples:

- Haskell
 \x -> 3 * x
 or
 (3 *)

- Ruby:
 def foo(x) x * 3 end
 it can do even better:
 {|x| 3}

-Scala:
 { case x of i => i * 3 }
 or
 (_ * 3)


By hiding the "function" text some DSLs look more notural. Example:
Scalatest:

 class StackSpec extends FlatSpec with ShouldMatchers {

   "A Stack" should "pop values in last-in-first-out order" in {
     stack.pop() should equal (2)
     stack.pop() should equal (1)
   }


Even Java can do this kind now by using xtext which is a DSL for writing
DSL's.

I personally think that this is more natural to write:

"my test ".shouldnt.throwException( functions(){
 throw "failure";
});

than the Assertions which is implemented in both: hxunit and unit.

A funny extension could be defining functions this way:
(a,b){"result"}      // << assume it returns something
(a,b):Void{"result"} // :Void makes this a function returning Void only

Same for classes. Why write function all the time? Its obvious that you
want a function, isn't it?

classs X{
 public static foo(a,b){ }
}

Of course I can make editors insert function, return etc (eg by using
templates). I'd still prefer not having to write them at all.

Have you already thought about sugaring functions in HaXe?

Marc Weber

--
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
Reply | Threaded
Open this post in threaded view
|

Re: sugar for functions?

tommedema
I like the comment by Adam Hepton there:

"Why stop there? Why don’t we reassign ‘var’ to ‘_’, ‘for’ to ‘£’, ‘while’ to ‘€’ and, oh I don’t know, ‘new Date’ to ‘@’?

Because it’s a really stupid idea, that’s why not."

This pretty much sums up what I'm thinking.

A function is a function, and when you define something it is much easier to actually say what you are defining rather than implementing special keywords for everything (or other methods).

Implementing these special cases is a pure waist of time in my opinion and only makes haXe less attractive to those not known with these weird behaviours.

- Tom


2010/8/1 Andy Li <[hidden email]>
I think that's cool. There is similar planing for JS too: http://www.sitepoint.com/blogs/2010/07/02/shorter-javascript-function-statement/


On Sun, Aug 1, 2010 at 10:42 PM, Cauê Waneck <[hidden email]> wrote:
This was discussed some times in here, but never was adopted as it's considered a syntax sugar only.

I agree with you, though, that it would be much readable. maybe adding a short "fun" as a shorthand for "function", or using a => operator.

2010/8/1 Marc Weber <[hidden email]>

Some popular languages have a way to write functions (lambdas) much
shorter than
 function (x) { return 3*x; }

Examples:

- Haskell
 \x -> 3 * x
 or
 (3 *)

- Ruby:
 def foo(x) x * 3 end
 it can do even better:
 {|x| 3}

-Scala:
 { case x of i => i * 3 }
 or
 (_ * 3)


By hiding the "function" text some DSLs look more notural. Example:
Scalatest:

 class StackSpec extends FlatSpec with ShouldMatchers {

   "A Stack" should "pop values in last-in-first-out order" in {
     stack.pop() should equal (2)
     stack.pop() should equal (1)
   }


Even Java can do this kind now by using xtext which is a DSL for writing
DSL's.

I personally think that this is more natural to write:

"my test ".shouldnt.throwException( functions(){
 throw "failure";
});

than the Assertions which is implemented in both: hxunit and unit.

A funny extension could be defining functions this way:
(a,b){"result"}      // << assume it returns something
(a,b):Void{"result"} // :Void makes this a function returning Void only

Same for classes. Why write function all the time? Its obvious that you
want a function, isn't it?

classs X{
 public static foo(a,b){ }
}

Of course I can make editors insert function, return etc (eg by using
templates). I'd still prefer not having to write them at all.

Have you already thought about sugaring functions in HaXe?

Marc Weber

--
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
Reply | Threaded
Open this post in threaded view
|

Re: sugar for functions?

Miller Medeiros
Just to complement... the JS proposal probably won't be approved:  http://hacks.mozilla.org/2010/07/brendan-eich-at-jsconf-2010-whats-coming-in-ecmascript-5-and-more/  - guy that created JS talks about it at 22min...
--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: sugar for functions?

wvxvw
In reply to this post by MarcWeber
Maybe this is not always stupid, but this is a known and hated issue in C++, which is said to be a very context-dependent language. What that means in layman terms is that it is difficult for the compiler to understand what the programmer wrote. (Do you want to see compiler errors like "Please simplify this", or "Cannot understand this, please rewrite"? - I don't think so). Another bad thing about it, that you will basically duplicate the existing API, again, the compiler will have to work harder for no reason understanding what exactly did you intend to write. But not only that, the programmers who are used to a certain style will not understand the other style right away (a famous problem with Python once, and the everyday pain of the PHP programmer). It is in fact much better if a language has one and only one way to express something. Anti-democratic, but purpose-wise, the best thing to have :)
There are languages, where shorthands for functions can bland easily, and in fact look natural (think Lisp), but HaXe is very much like ECMAScript, and I think that having var and function helps this language a lot (otherwise it could fall under the same category as C++ because of a very difficult to digest syntax).
So, I'm against it :)

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: sugar for functions?

singmajesty
I agree.

I tend to believe it is better to have an IDE which completes things for  
you than to have a programming language that is less verbose.

Personally, if I were to recommend a format change for haXe, I would  
suggest that the package structure adopt a similar structure to  
Actionscript 3. Right now, haXe feels like AS3, put in an AS2 file  
structure.




On Sun, 01 Aug 2010 09:09:11 -0700, Oleg Sivokon <[hidden email]>  
wrote:

> Maybe this is not always stupid, but this is a known and hated issue in  
> C++,
> which is said to be a very context-dependent language. What that means in
> layman terms is that it is difficult for the compiler to understand what  
> the
> programmer wrote. (Do you want to see compiler errors like "Please  
> simplify
> this", or "Cannot understand this, please rewrite"? - I don't think so).
> Another bad thing about it, that you will basically duplicate the  
> existing
> API, again, the compiler will have to work harder for no reason
> understanding what exactly did you intend to write. But not only that,  
> the
> programmers who are used to a certain style will not understand the other
> style right away (a famous problem with Python once, and the everyday  
> pain
> of the PHP programmer). It is in fact much better if a language has one  
> and
> only one way to express something. Anti-democratic, but purpose-wise, the
> best thing to have :)
> There are languages, where shorthands for functions can bland easily,  
> and in
> fact look natural (think Lisp), but HaXe is very much like ECMAScript,  
> and I
> think that having var and function helps this language a lot (otherwise  
> it
> could fall under the same category as C++ because of a very difficult to
> digest syntax).
> So, I'm against it :)


--
Joshua Granick
Owner / Lead Developer
[ eclecticdesignstudio ]
P: (916) 889-7306

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: sugar for functions?

interaction-designer
In reply to this post by MarcWeber
Hi,

You can try to shorthand everything until it goes beyond the point of making sense, the point where it becomes unreadable. It becomes at least harder to understand by the compiler if not also harder too read by humans. So I am very much against leaving away the usage of the function keyword for functions. Use shorthands intelligently and not just because it is possible.

Cheers, Simon

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: sugar for functions?

Cauê W.
well, I think you all have extrapolated to a point where it's ridiculous. But I think it's an easy way to extrapolate like that, and you can do that with pratically everything and rant about them.

On the special case of function definitions, there is a point into having this. It makes the code cleaner, more readable.
I think it would make haXe more declarative to use that, like it is with the use of the "using" keyword.
I for one would use much more Lambda expressions, as they would be much clear to understand:
e.g.

var string:String;
//...

var arrayOfInts = [];
for (str in string.split(", "))
arrayOfInts.push(Std.parseInt(str));

//use arrayofints

------
could be turned into a very clear one-liner:
using Lambda;

var arrayOfInts = string.split(", ").map( (str) => Std.parseInt(str) );


of course you can still write

var arrayOfInts = string.split(", ").map( function (str) Std.parseInt(str) );

but think of a nastier case with nested lambdas.
(in this case we could use var arrayOfInts = string.split(", ").map(Std.parseInt); anyway)

I know I restrain myself from using Lambda's because they are slow and also because of the readability problems there are. I am pretty sure no one thinks C#'s declarative properties of Linq bad. Do you?



2010/8/1 <[hidden email]>
Hi,

You can try to shorthand everything until it goes beyond the point of making sense, the point where it becomes unreadable. It becomes at least harder to understand by the compiler if not also harder too read by humans. So I am very much against leaving away the usage of the function keyword for functions. Use shorthands intelligently and not just because it is possible.

Cheers, Simon

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


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: sugar for functions?

tommedema
Well, I'm sorry but your example didn't convince me. The 3 lines are much easier to read than the one liner in my opinion.

- tom

2010/8/1 Cauê Waneck <[hidden email]>
well, I think you all have extrapolated to a point where it's ridiculous. But I think it's an easy way to extrapolate like that, and you can do that with pratically everything and rant about them.

On the special case of function definitions, there is a point into having this. It makes the code cleaner, more readable.
I think it would make haXe more declarative to use that, like it is with the use of the "using" keyword.
I for one would use much more Lambda expressions, as they would be much clear to understand:
e.g.

var string:String;
//...

var arrayOfInts = [];
for (str in string.split(", "))
arrayOfInts.push(Std.parseInt(str));

//use arrayofints

------
could be turned into a very clear one-liner:
using Lambda;

var arrayOfInts = string.split(", ").map( (str) => Std.parseInt(str) );


of course you can still write

var arrayOfInts = string.split(", ").map( function (str) Std.parseInt(str) );

but think of a nastier case with nested lambdas.
(in this case we could use var arrayOfInts = string.split(", ").map(Std.parseInt); anyway)

I know I restrain myself from using Lambda's because they are slow and also because of the readability problems there are. I am pretty sure no one thinks C#'s declarative properties of Linq bad. Do you?



2010/8/1 <[hidden email]>

Hi,

You can try to shorthand everything until it goes beyond the point of making sense, the point where it becomes unreadable. It becomes at least harder to understand by the compiler if not also harder too read by humans. So I am very much against leaving away the usage of the function keyword for functions. Use shorthands intelligently and not just because it is possible.

Cheers, Simon

--
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
Reply | Threaded
Open this post in threaded view
|

Re: sugar for functions?

MarcWeber
In reply to this post by interaction-designer
Hi Simon (&list),

Excerpts from interaction-designer's message of Sun Aug 01 18:50:38 +0200 2010:
> You can try to shorthand everything until it goes beyond the point of making sense, the point where it becomes unreadable.

I prefer

list.map((x){ x*x;}).filter((x){ x > 3; })

over

list.map(function(x){ return x*x;}).filter(function(x){ return x > 3; })

Because I feel it contains more noise.

Yes you can split it into many lines:

  list
  .map(function(x){ return x*x;})
  .filter(function(x){ return x > 3; })

or what about
   
  var sqr = function(x){ return x* x; };
  var f = function(x){ return x > 3; };
  list.map(sqr).filter(f);

?

I understand that users may uncomfortable with such a syntax at the
beginning. But there is a reason why Ruby and grails and such are
popular.
Such sugar is one of them (IMHO).

About the compiler: You're right. It has to disambiguate

map((3)
vs
map((a){..})

However the look ahead is small. Its only about some characters and
arguments. So if (foo) is followed by either { or : its a function.

And if that wastes too much CPU cycles you could implement it
differently, eg the Ruby block way {|args| body } and replace {} by $ or
such..

You can't protect against programmers abusing a language. So I always
assume people use sugar wisely. I posted enough examples illustrating
what I think is more readable. Of course you can think differently.

I think that whether someone finds code readable or not depends heavily
on which languages he used in the past :)

I'll shut up and watch whether its only me preferring tight syntax for
examples like the ones given above.

Marc Weber

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: sugar for functions?

Heinz Hölzer-2
By the way, you can already write:

list
   .map(function(x) return x*x )
   .filter(function(x) return x>  3 )

i would generally prefer the csharp way for lambdas (no brackets):

list
   .map(x =>  x*x )
   .filter( x =>  x>  3 )

and for tuples:

var add = (a,b) =>  a+b;

trace(add(2,2));

you can find a long discussion about this here:
http://haxe.1354130.n2.nabble.com/Suggestion-Lambda-Expressions-like-a-a-0-as-haxe-imprevement-tt3431220.html#a3431220






Am 01.08.2010 19:36, schrieb Marc Weber:

> Hi Simon (&list),
>
> Excerpts from interaction-designer's message of Sun Aug 01 18:50:38 +0200 2010:
>    
>> You can try to shorthand everything until it goes beyond the point of making sense, the point where it becomes unreadable.
>>      
> I prefer
>
> list.map((x){ x*x;}).filter((x){ x>  3; })
>
> over
>
> list.map(function(x){ return x*x;}).filter(function(x){ return x>  3; })
>
> Because I feel it contains more noise.
>
> Yes you can split it into many lines:
>
>    list
>    .map(function(x){ return x*x;})
>    .filter(function(x){ return x>  3; })
>
> or what about
>
>    var sqr = function(x){ return x* x; };
>    var f = function(x){ return x>  3; };
>    list.map(sqr).filter(f);
>
> ?
>
> I understand that users may uncomfortable with such a syntax at the
> beginning. But there is a reason why Ruby and grails and such are
> popular.
> Such sugar is one of them (IMHO).
>
> About the compiler: You're right. It has to disambiguate
>
> map((3)
> vs
> map((a){..})
>
> However the look ahead is small. Its only about some characters and
> arguments. So if (foo) is followed by either { or : its a function.
>
> And if that wastes too much CPU cycles you could implement it
> differently, eg the Ruby block way {|args| body } and replace {} by $ or
> such..
>
> You can't protect against programmers abusing a language. So I always
> assume people use sugar wisely. I posted enough examples illustrating
> what I think is more readable. Of course you can think differently.
>
> I think that whether someone finds code readable or not depends heavily
> on which languages he used in the past :)
>
> I'll shut up and watch whether its only me preferring tight syntax for
> examples like the ones given above.
>
> Marc Weber
>
>    


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: sugar for functions?

Andy Li
To me it's how much you like and want to use functional programming. One should realize the benefit of having short-hand function if Lambda is used frequently.

I understand others may not use to short-hand notation, just as they may not use to functional programming or some design patterns. But it doesn't necessarily mean short-hand notation, function programming or any design pattern itself is bad.

Andy

2010/8/2 Heinz Hölzer <[hidden email]>
By the way, you can already write:

list
 .map(function(x) return x*x )
 .filter(function(x) return x>  3 )

i would generally prefer the csharp way for lambdas (no brackets):


list
 .map(x =>  x*x )
 .filter( x =>  x>  3 )

and for tuples:

var add = (a,b) =>  a+b;

trace(add(2,2));

you can find a long discussion about this here:
http://haxe.1354130.n2.nabble.com/Suggestion-Lambda-Expressions-like-a-a-0-as-haxe-imprevement-tt3431220.html#a3431220






Am 01.08.2010 19:36, schrieb Marc Weber:

Hi Simon (&list),

Excerpts from interaction-designer's message of Sun Aug 01 18:50:38 +0200 2010:
 
You can try to shorthand everything until it goes beyond the point of making sense, the point where it becomes unreadable.
   
I prefer

list.map((x){ x*x;}).filter((x){ x>  3; })

over

list.map(function(x){ return x*x;}).filter(function(x){ return x>  3; })

Because I feel it contains more noise.

Yes you can split it into many lines:

  list
  .map(function(x){ return x*x;})
  .filter(function(x){ return x>  3; })

or what about

  var sqr = function(x){ return x* x; };
  var f = function(x){ return x>  3; };
  list.map(sqr).filter(f);

?

I understand that users may uncomfortable with such a syntax at the
beginning. But there is a reason why Ruby and grails and such are
popular.
Such sugar is one of them (IMHO).

About the compiler: You're right. It has to disambiguate

map((3)
vs
map((a){..})

However the look ahead is small. Its only about some characters and
arguments. So if (foo) is followed by either { or : its a function.

And if that wastes too much CPU cycles you could implement it
differently, eg the Ruby block way {|args| body } and replace {} by $ or
such..

You can't protect against programmers abusing a language. So I always
assume people use sugar wisely. I posted enough examples illustrating
what I think is more readable. Of course you can think differently.

I think that whether someone finds code readable or not depends heavily
on which languages he used in the past :)

I'll shut up and watch whether its only me preferring tight syntax for
examples like the ones given above.

Marc Weber

 


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


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: sugar for functions?

MarcWeber
In reply to this post by Heinz Hölzer-2
Excerpts from Heinz Hölzer's message of Sun Aug 01 20:04:00 +0200 2010:
> By the way, you can already write:
> you can find a long discussion about this here:
> http://haxe.1354130.n2.nabble.com/Suggestion-Lambda-Expressions-like-a-a-0-as-haxe-imprevement-tt3431220.html#a3431220

I even remember having read parts of it once.
http://haxe.1354130.n2.nabble.com/Suggestion-Lambda-Expressions-like-a-a-0-as-haxe-imprevement-tt3431220.html#a3444690

This is an interesting point: hunting for all functions.
grep -r function .

Martijn Loots, why did you want to do that?
This looks like "I want to add debugging lines everywhere".. Something
which is done by Aspects when coding Java.

Take it the way it is: HaXe *is* lacking man power. Many libraries are
yet to be written. People chose Ruby over PHP for good reasons. And
concise syntax is one of those. IMHO.

By the way: I don't care whether => (C#) or (){} (my proposal) or {|| ..} (Ruby blocks) or haskell like
\arg -> body is used.

I want a way to write BDD style because I find it more readable. Yes
execution is slower. But for most tasks it only matters that you can get
a job done fast. Get done first, then start improving performance.

Marc Weber

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: sugar for functions?

Cauê W.
by the way, lambda functions can be just as fast as normal imperative programming, You just have to make it inline. The compiler will take the function as an argument, and inline it as well.

2010/8/1 Marc Weber <[hidden email]>
Excerpts from Heinz Hölzer's message of Sun Aug 01 20:04:00 +0200 2010:
> By the way, you can already write:
I even remember having read parts of it once.
http://haxe.1354130.n2.nabble.com/Suggestion-Lambda-Expressions-like-a-a-0-as-haxe-imprevement-tt3431220.html#a3444690

This is an interesting point: hunting for all functions.
grep -r function .

Martijn Loots, why did you want to do that?
This looks like "I want to add debugging lines everywhere".. Something
which is done by Aspects when coding Java.

Take it the way it is: HaXe *is* lacking man power. Many libraries are
yet to be written. People chose Ruby over PHP for good reasons. And
concise syntax is one of those. IMHO.

By the way: I don't care whether => (C#) or (){} (my proposal) or {|| ..} (Ruby blocks) or haskell like
\arg -> body is used.

I want a way to write BDD style because I find it more readable. Yes
execution is slower. But for most tasks it only matters that you can get
a job done fast. Get done first, then start improving performance.

Marc Weber

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


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: sugar for functions?

John A. De Goes
In reply to this post by MarcWeber

This is absolutely a wonderful idea!

When using Future's, and chaining them together, you often have constructs like this:

urlLoader.load('http://domain.com/assets/library.xml').map(function(data) return Xml.parse(data)).flatMap(function(xml) return urlLoader.load(xml.getAttribute('background.swf')).map(function(loaderSwf) return loaderSwf.getChildAt(0));

The intention of this code is obscured by its verbosity. It's not easy to read what it's doing because the mind has to parse out all the noise. Consider how this would look in Scala:

urlLoader.load('http://domain.com/assets/library.xml').map(Xml.parse(_)).flatMap(urlLoader.load(_.getAttribute('background.swf')).map(_.getChildAt(0));

Or more tersely using Monadic notation:

for (text <- urlLoader.load('http://domain.com/assets/library.xml');
       xml <- Xml.parse(text);
       loaderSwf <- urlLoader.load(xml.getAttribute('background.swf')))
    yield loaderSwf.getChildAt(0);

Or more verbosely:

urlLoader.load('http://domain.com/assets/library.xml').map(text => Xml.parse(text)).flatMap(xml => urlLoader.load(xml.getAttribute('background.swf')).map(loaderSwf => loaderSwf.getChildAt(0));

It's widely considered that one of JavaScript's largest pain points for functional programming is the verbose nature of its lambda syntax. People don't use monads in JavaScript, for example -- not because you can't use them, but because they're so hideous to look at.

I would love a syntax like this:

list.map((x) -> x * x);

Equivalent to: list.map(function(x) return x * x);

In other words, the parameter list, followed by '->', followed by an expression. This can be parsed unambiguously (requiring only lookahead, which is already used for lambdas) and resembles HaXe's notation for type signature.

Another possibility is: list.map(x -> x * x); Or with two arguments: map.transform(k -> v -> v * v); This matches the notation for type signatures exactly. Although personally, I think the first syntax (map.transform((k, v) -> v * v)) is more inline with HaXe style.

Even simply shortening 'function' to 'fn' as is done in some languages, would permit an increase in conciseness: list.map(fn(x) return x * x); Not as clean, but much more readable than the present standard.

Regards,

John

On Aug 1, 2010, at 8:33 AM, Marc Weber wrote:

Some popular languages have a way to write functions (lambdas) much
shorter than
 function (x) { return 3*x; }

Examples:

- Haskell
 \x -> 3 * x
 or
 (3 *)

- Ruby:
 def foo(x) x * 3 end
 it can do even better:
 {|x| 3}

-Scala:
 { case x of i => i * 3 }
 or
 (_ * 3)


By hiding the "function" text some DSLs look more notural. Example:
Scalatest:

 class StackSpec extends FlatSpec with ShouldMatchers {

   "A Stack" should "pop values in last-in-first-out order" in {
     stack.pop() should equal (2)
     stack.pop() should equal (1)
   }


Even Java can do this kind now by using xtext which is a DSL for writing
DSL's.

I personally think that this is more natural to write:

"my test ".shouldnt.throwException( functions(){
 throw "failure";
});

than the Assertions which is implemented in both: hxunit and unit.

A funny extension could be defining functions this way:
(a,b){"result"}      // << assume it returns something
(a,b):Void{"result"} // :Void makes this a function returning Void only

Same for classes. Why write function all the time? Its obvious that you
want a function, isn't it?

classs X{
 public static foo(a,b){ }
}

Of course I can make editors insert function, return etc (eg by using
templates). I'd still prefer not having to write them at all.

Have you already thought about sugaring functions in HaXe?

Marc Weber

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


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: sugar for functions?

wvxvw
In reply to this post by MarcWeber
http://yosefk.com/c++fqa/
This is for whoever thinks that omitting the word "function" in the function declaration is a great idea. Read more on that site, it actually has many other valid points too, I just don't want to copy every link from it.
Now, lambdas implementation sucks in many if not most of the languages HaXe compiles to, and there's nothing HaXe can do about it. Practically, in the production code it is always better to avoid them. Yes, I know, it's nice idea, and I like it very much... in Lisp. I don't like it when ECMAScript tries to be "like" Lisp, it cannot. It's not bad or good, it's a fact. (Search Wiki on closures and read the discussion on closures in JavaScript, if you want more info on that). Closures or lambdas are kind of an "in" things now, but this is nothing but fashion, this will come and go in a few years, but practically, there's no point of using it in languages like AS or JS simply because it has more quirks and disadvantages, and zero advantages.
This is not the case in C# for example, but, well, HaXe doesn't compile to C# or any other .NET language.

In the end, I'd like to post this link, I think it kind of sums up the discussion ;)

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: sugar for functions?

Cauê W.
Oleg, haXe already has the possibility to have lambdas with the same performance as imperative programming. That is because if the Lambda's static functions were declared as inline, the compiler would inline your function definition as well, and it would produce code close to the imperative version.

2010/8/2 Oleg Sivokon <[hidden email]>
This is not the case in C# for example, but, well, HaXe doesn't compile to C# or any other .NET language.
..yet... : )


cheers!

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: sugar for functions?

wvxvw
Cauê, it's not about performance, it's about memory usage (unwise in case of lambdas), scope problems (lambdas in ECMAScript sort of languages are NOT first order functions, they have scope, and this means that the problems may arise from it, when resolving scope incorrectly, they are difficult to compare (or impossible sometimes).
There's another rule about languages like ECMAScript, local function variables should not outlive the function (otherwise you may have memory leaks, because the environment will not know how to manage the heap properly). The fact that JavaScript or ActionScript (and their environments) allow lambdas is, in fact, a disadvantage because they are poorly implemented, and using them is dangerous.
Reply | Threaded
Open this post in threaded view
|

Re: sugar for functions?

Cauê W.
so...
but all of this will be gone in an inline version of lambdas.
This is because haXe will take an anonymous function and inline it as actual code, so there is no anonymous function, at all!

The only "problem" is about memory usage, but if you're not doing it on a million-based array or something like that, I don't think there is need to worry about that! : )

2010/8/2 wvxvw <[hidden email]>

Cauê, it's not about performance, it's about memory usage (unwise in case of
lambdas), scope problems (lambdas in ECMAScript sort of languages are NOT
first order functions, they have scope, and this means that the problems may
arise from it, when resolving scope incorrectly, they are difficult to
compare (or impossible sometimes).
There's another rule about languages like ECMAScript, local function
variables should not outlive the function (otherwise you may have memory
leaks, because the environment will not know how to manage the heap
properly). The fact that JavaScript or ActionScript (and their environments)
allow lambdas is, in fact, a disadvantage because they are poorly
implemented, and using them is dangerous.
--
View this message in context: http://haxe.1354130.n2.nabble.com/sugar-for-functions-tp5361034p5364518.html
Sent from the Haxe mailing list archive at Nabble.com.

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


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