Lambdas in C (walfield.org)

Bah, beat me to it. It's still kind of cool though.

    qsort (array, sizeof (array) / sizeof (array[0]), sizeof (array[0]),
         lambda (int, (const void *a, const void *b),
                 {
                   dump ();
                   printf ("Comparison %d: %d and %d\n",
                           ++ comparison, *(const int *) a, *(const int *) b);
                   return *(const int *) a - *(const int *) b;
                 }));

That's slightly sloppy phrasing. It captures it, but it does not duplicate it, so it's lifetime is tied to the stack frame of the function you declared it in.

In short, you can only do downwards funargs.

If an anonymous function can capture state from the enclosing code block, and outlive that code block, then it's a lambda.

So this probably isn't really a lambda.

They should try to make something syntactically compatible with C++ lambdas. It's annoying that the two languages are more and more incompatible for cosmetic reasons.

To me it's a bit more surprising: it's a statement expression, containing a nested function, then we take the address of that nested function.

Having that series of operations produce something useful is unexpected, to say the least.

It's nothing I'd want to see in code that I maintain, but I think you have to give it a bit more credit. Besides that, it's cute :)

     Ian Lance Taylor replied that the behavior is 
     undefined, but so far stable. His suggestion was 
     to open a bug and request that this desirable (!!!)
     behavior be explicitly permitted.

Right. And of course the whole idea is prone to insane amounts of fail.

    > Thus, if you access the enclosing environment, you
    > must ensure that the lifetime of this lambda is bound by the
    > lifetime of the enclosing environment (i.e., until the enclosing
    > function returns).  This means that if you access local
    > variables, bad things will happen.  If you don't access local
    > variables, you're fine.

Might as well avoid the complications, hoist the function and pass a function pointer with some context (assuming it's needed).

One might say, to paraphrase Douglas Adams, that it's almost, but not quite, entirely unlike lambdas.

Anonymous functions are very handy, and I think they should really be taken a step further. There's really no reason why it shouldn't be possible to pass an actual function body where a function pointer is required:

  int v[...];

  qsort( v, ..., (a, b) { return *(int*)a - *(int*)b } );

Such usage would also have an added benefit of letting the compiler do the type inference for a, b and the return value and not needing to explicitly specify them in qsort() call.

Local functions would be a nice compromise between the unreadable glop that was posted and the need to declare an entirely separate function to execute localized actions.

also, this works too:

  val := func(x int, y int) int{return x+y}(2,4)

Is that really that much better than C blocks?

    #include <stdio.h>
    int main (int argc, char const *argv[]) {
        int (^add)(int, int) = ^(int x, int y) {
            return x + y;
        };
        int (^max)(int, int) = ^(int x, int y) {
            return (x > y) ? x : y;
        };
        printf("block: add:%d\n", add(2,3));
        printf("block: max:%d\n", max(2,3));
        return 0;
    }

  func(x int, y int){fmt.Printf("%d\n",x+y)}(2,4)

   ^(int x, int y){printf("%d\n",x+y);}(2,4);