Syntax for typed lamdas

Help me /prog/, i'm making a language and i can't decide on what syntax to use for typed lambdas

>>40
Making up original quotes when almost-correct quotes already exist is inefficient.

>>39
http://rosettacode.org/wiki/Sorting_algorithms/Sleep_sort#Haskell

I think Umena is a pretty lovable girl. Ehs kills poelcat kbeabs and doesnt afraid of anything.

Do it the Ruby way

square = lambda { |x| x * x }

Do it the postscript way


/square {dup mul} def

(INT x)INT: x * x;
(INT x, y)INT: x + y;
INT: (INT i; read(i); i);
PROC f := (REF INT x)PROC REF INT: INT: x *:= 2;
INT i := 10;
PROC INT g = f(i);
MODE P = PROC(P)P;
# Y combinator: #
PROC y = (P f)P: ((P x)P: f((P v)P: x(x)(v))) ((P x)P: f((P v)P: x(x)(v)))
Algol 68's function syntax is the best because it's clean and uncluttered, with no unnecessary keywords like "return" and "function". The value returned by the function is simply the value of the last expression. All statements are also expressions, so you don't need to distinguish between parentheses and curly braces and you could insert the text of a procedure anywhere you can use a call to that procedure.

Do it the HMA way

>>45

Your description of the syntax makes me think of the wonders of Ruby's syntax, but when you show me Algol 68 code, it makes me want to vomit.

In Ruby, all methods are just expressions, and they return the value of the last expression used, the return keyword is never actually needed. Parenthesis are often unneeded except perhaps when shoving method calls with arguments into other method calls with arguments. Even then however, you have a choice between the traditional style

foo(x, y)

and the lisp style

(foo x, y) # This is my preferred method, although I know no one else who actually does this.

Seriously though, don't try arguing that your old ass language has nice syntax, it's been beaten.

>>47
(foo x, y)
Shitstorm shall ensue.

>>45
>because it's clean and uncluttered
Yeah, also ununderstandable.

>>48

*Yawn* go ahead. It's just my way of handling things, and in my opinion it looks better

(foo bat, baz).bar [:test, :argument]

>>47
Some of those expressions, such as the Y-combinator, will probably only be used in examples. It's translated from this JavaScript:
var Y = function (F) {
 return (function (x) {
  return F(function (y) { return (x(x))(y);});
  })
        (function (x) {
  return F(function (y) { return (x(x))(y);});
  }) ;
} ;
Algol 68 (same as before, but with whitespace):
PROC y = (P f) P: (
     (P x) P:
          f((P v) P: x(x)(v))
     )((P x) P:
          f((P v) P: x(x)(v)))
The other is a procedure that takes a reference to an integer as a parameter, and returns a procedure that stores the result of the integer times 2 into the original variable, and then returns a reference to that variable. Again, it's not something likely to be used in real code, just an example of references and functions returning functions. Even though it might look ugly, it still looks better IMO than it would in a C-like language.
C-like language with nested functions (works in GCC):
int *(*f(int* px))(void) {
     int *g(void) { *px *= 2; return px; };
     return g;
}
int n = 10;
int *(*pfpi)(void) = f(&n);
int *pi = f(&n)();
int i = *f(&n)();
printf("%d %d %d", *pfpi(), *pi, i);
If you want an int*(*)(void), you use f(&n). If you want an int*, you use f(&n)(). If you want an int, you use *f(&n)().
Algol 68 (Revised Report):
PROC f := (REF INT x)PROC REF INT: REF INT: x *:= 2;
INT n := 10;
PROC REF INT pri := f(n);
REF INT ri := f(n);
INT i := f(n);
print((pri, ri, i))
Whether you want a PROC REF INT, a REF INT, or an INT, you use f(n).
Algol 68 (Original):
PROC f := (REF INT x)PROC REF INT: x *:= 2;
The original Algol 68 also had a proceduring coercion, which converted an expression into a procedure in a context that requires one. It made a cast (e.g. INT:) equivalent in syntax and behavior to a function with no arguments that is called immediately. It was dropped because it was considered too complex for compilers to implement. To this day, no Algol 68 compiler has ever supported proceduring.

>>49
Opinion.

>>43
If it's not typed, it's shit

Does that close over variables in scope?

>>53

Ruby is strongly dynamically typed, and regarding how it closes over variables, well....

http://innig.net/software/ruby/closures-in-ruby

Take of that what you will. 2.0 will probably make closures even kind of weirder. Hopefully it will make it more functional though.

>>55

Duby is strongly dynamically checked, and regarding how it GETs over threads, well....

httip://getting.net/shitware/duby/getting-in-duby

Check of my dubs what you will. D.2 will probably make getting even kind of easier. Hopefully it will make it more fashionable though.

Ruby is shit.

>>56

Yes, but it's better shit than Python, which is good shit.