Function folding is my idea (Compute is my effort) for syntactical sugar to
make chained functional programming less verbose.  Does anyone know of
another language which uses similar folding syntax?  It also cooperates
with a more generalized iteration paradigm than HaXe's for( in ):

http://copute.com/dev/docs/Copute/ref/iteration.html

Additionally, the iteration paradigm above eliminates the confirmed
( http://lists.motion-twin.com/pipermail/haxe/2010-February/033464.html )
confusion when trying to explain HaXe's iterators:

http://lists.motion-twin.com/pipermail/haxe/2010-February/033429.html
http://lists.motion-twin.com/pipermail/haxe/2010-February/033423.html
http://lists.motion-twin.com/pipermail/haxe/2010-February/033449.html

The above contains a few improvements over HaXe's OOP design which could
also be considered a proposal.  For one thing, it unifies concepts, making
it easier to see know how they relate and interact.

Note:

http://copute.com/dev/docs/Copute/ref/iteration.html

"empty () is optional in function folding"

This means we can read access functions that take a void,
as if they were variables (without trailing parentheis).
It is a more concise way to achieve a getter
( http://haxe.org/ref/properties ), and not limited to
getting a member variable.

Thus Iteration.length() will not conflict with for example
existing Array.length, because the compiler can infer they
are the same.

I see no ambiguity in the grammar, as variables can be
functions normally anyway.

Function folding can so something similar to list comprehension:

http://www.oreillynet.com/onlamp/blog/2005/10/pythons_weak_functional_progra.html

And is more generally applicable.

Typo above "do" instead of "so"

I am trying to think of more concise, yet more comprehensible syntax, e.g. this example:

'\n'.join( (list.map( foo ) return foo.name).filter( s ) return s != '' )

Without the proposed function folding is:

'\n'.join( list.map( function( foo ) { return foo.name } ).filter( function( s ) { return s != '' } ) )

One breakthrough might be to use a larger charset for the language, and supply a clickable popup keypad for inserting the characters in the editor, assuming we only use these esoteric characters for infrequent syntax, e.g.:

'\n'.join( list.map( λ( foo ) { « foo.name } ).filter( λ( s ) { « s != '' } ) )

Or we could utilize unused symbols on the keyboard:

'\n'.join( list.map( $( foo ) { @foo.name } ).filter( λ( s ) { @s != '' } ) )

Or we could use single letter capital keywords:

'\n'.join( list.map( F( foo ) { R foo.name } ).filter( λ( s ) { R s != '' } ) )

Perhaps the best would be lamba syntax that could even re-use operators that are not possible where a function type is expected, but this would not allow such a function type to declared where a general expression is expected:

'\n'.join( list.map( /foo = foo.name ).filter( /s = s != '' ) )

The best is probably to utilize unused symbols on the keyboard for the lambda syntax:

'\n'.join( list.map( \foo = foo.name ).filter( \s = s != '' ) )

Haskell prefers -> instead of =:

'\n'.join( list.map( \foo -> foo.name ).filter( \s -> s != '' ) )

Types could be optionally specified:


'\n'.join( list.map( \x:Foo -> x.name ).filter( \x:String -> x != '' ) )

Multiple arguments could also be possible with lambda syntax:

\a b -> a + b
\a,b -> a + b
\a:Int b:Int -> a + b
\a:Int,b:Int -> a + b

Note for lambda syntax, the purity is inferred:

http://copute.com/dev/docs/Copute/ref/function.html#Purity

I think it would be unambiguous if we further folded to:

'\n'.join( list.map( \foo.name ).filter( \s != '' ) )

Which is equivalent to:

'\n'.join( list.map( \foo.name ).filter( '' != \s ) )

Types could still be optionally specified:

'\n'.join( list.map( \x:Foo.name ).filter( \x:String != '' ) )

Multiple arguments would be problemmatic because order would not be orthogonally specifiable, unless we put a digit after the \ symbol.

Also how could lambda shorthand syntax handle multiple expressions (separated by semicolons?)? Would the last expression be the return value?

If the expected return type is Void, then any return value of lambda expression is discarded. Note it is possible for the lambda expression to call a function that returns Void, then if the expected return type is not Void, then compile error must be generated.