design of lambda type signatures

Hey /praha/, what do you guys look for in a lambda type signature?

I personally like to see their smile. No, i mean, homoiconicity and uniform definition and declaration.

Anyways, which would you rather use everyday?


function<int, int -> int> foo;

foo = [int a, int b -> int] {
  return a + b;
}

or perhaps


function<int | int, int> foo;

foo = [int | int, int] {
  return a + b;
}

or anything else? Comparisons to other languages would be appreciated.

Go-style: foo = [int a, int b] int { return a + b; }
Actionscript-style: foo = [a:int, b:int]:int { return a + b; }

Static typing considered harmful.

"Considered harmful" considered a premature optimization.

Not Lisp, not 2hu, not j00s, not feminism, not /frog/

Languages adopting -> in their syntax to get in ``the functional fad'' feels like languages wearing hot topic t-shirts. Especially when they aren't importing the currying mechanism behind that arrow.

functional programming considered a ghetto

Algol 68's declaration syntax extends to procedures, operators and even type declarations. It is also the first language to separate mutability from identity and to make the immutable types basic. An INT is immutable, but REF INT is mutable. This meaning of ref is still used in ML family languages.
PROC foo = (INT a, b)INT: a + b
Curried:
PROC foo = (INT a)(INT b)INT: a + b
Callback:
do something((INT a, b)INT: a + b)
Procedured:
INT a, b;
do something else(a + b, a, b)
S-combinator:
MODE C = PROC(C)C;
PROC s = (C x)(C y)(C z)C: x(z)(y(z))
In the "procedured" form, a and b are references. The first parameter is transformed into a procedure (thunk) which implements call-by-name. "Mode equivalencing" determines that type PROC(C)(C)(C)C of the S-combinator is equivalent to C by expanding C's tree until they are equivalent.
Algol 68 has no forward declarations because there is no use for them in the abstract machine. The abstract machine interpreted Algol 68 as a tree of text and could access all parts of the program simultaneously. All types are known at all times. Forward declarations are a hack for compiler writers.
Curried form, closures and proceduring were proposed before 1973 with this very syntax, but were dropped from the Revised Report because the heap was extremely expensive at the time and they wanted to simplify things because no compilers implemented the whole language.

Statically-typed lambdas without type inference considered absurdly verbose and ugly.

>>1
You shouldn't even use a lambda for this. If a functional language doesn't provide some binary addition function then it's shit.

I like the lambda syntax in D; it's similar to C#:


//Parameter types inferred, can be declared if desired
auto arr = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9];
auto res = arr.filter!(x => x < 5);
assert(equal(res, [0, 1, 2, 3, 4]));

auto sum = res.reduce!((a, b) => a + b);
assert(sum == 10);

Also, because of D's string mixins, there is an even terser syntax available for functions that expect a predicate.


auto twice = res.map!"a * 2";
assert(equal(res, [0, 2, 4, 6, 8]));

>>11

assert(equal(res, [0, 2, 4, 6, 8]));

Replace res with twice.

javascript considered the future

>>13
Javashit's lambda syntax is ugly and verbose.

>>14
oh contrere, that's not what other js users say

>>15
*contraire

/polecat kebabs/

>>15
i eat shit and my fellow shit eaters say it's pretty good! XD

Fuck off, Javashit kike.

>>18
I'm going to start supporting javascript just to enrage you you little racist faggot.

>>19
I don't give a shit, you're still a kike, Shlomo.

I'm not ``enraged'', I'm simply pointing out the truth.

>>20
The truth is that you are an illogical racist piece of shit.

>>20
simply pointing out the truth.
why so mad?

>Javascript
Frozenvoid is anus retarded.

>>21
Back to Reddit.

>>22
lel i so mad XD e/b/in win /b/ro :P


foo :: Int -> Int -> Int
foo = (+)

[/thread]

>>25
That's not lambda, a lambda would be (\x, y -> x + y). C#'s (x, y => x + y) is better by one symbol.

Actually, they're the same length:
(\x y -> x + y)
(x, y => x + y)

But even if you insist on an unnecessary lambda, Haskell can do it better than that: (\x -> (x+))

Why not just use + (or wrap it in parentheses if necessary)? Languages are so verbose these days. Higher-level languages were supposed to be about doing more with less code, but a function that adds two integer parameters is shorter in most assembly languages!

>>28
Except that x and y aren't limited to integer values.

FIBONACCI BUTT SORT
Anti-spam bump