Anonymous methods, also known as closures

[Charles]

Also, it seems your sample has the same issue when adding a level of indentation (in if true block):

I didn't understand the above statement. Also, you have a colon at the end. Perhaps you intended to include some code?

No problem on the questions. It helps improve the samples. But please feel free to enhance the wiki some more. I could use help in that area while I'm busy on the compiler and forum support.

[gauthier]

I didn't understand the above statement. Also, you have a colon at the end. Perhaps you intended to include some code?

Sorry, added the code.

I will try add some more examples on the wiki soon.

[Charles]

Fixed, tested and checked in.

[helium]

Well we don't have lambda expressions yet, but we have anonymous methods, aka closures.

OK, now it gets plain stupid. Sorry, but I leave this forum.

[gauthier]

OK, now it gets plain stupid. Sorry, but I leave this forum.

I don't get it...

As I explained before closures and anonymous functions are two completly unrelated things. Anonymous functions are NOT known as closures. A Closure is just a function that encloses it's scope.

And the reverse is also true: A local function - named or unnamed - doesn't necessarily have to be a closure.

Sticking with the definition, you are right, but who is to blame for introducing "anonymous methods" first? I think the blame is for misnaming them with c# language before cobra came here.

To thoses that aren't using ruby, smalltalk or javascript, the closure term is not readily known, where as anonymous methods are known because of c# or java (or class)

So, the best will be to rename the thread "closures (aka c# anonymous methods)" so everyone can find the information and you are not forced to leave

[Charles]

Sometimes people get real picky about a particular thing and then leave if it isn't done exactly how they wanted. But then I figure if it wasn't that thing, it would have just been another thing later.

[Charles]

"Moved" from viewtopic.php?f=4&t=218#p1187

------------

-- Added anonymous methods, also known as closures.

Code: Select all

// D

void globalFunction()
{
   int x = 0;  // local variable
   void NAMED_localFunction()
   {
       printf("I can access x, I'm a closure, see: %d", x);
   }
   NAMED_localFunction();
}


Or:

Code: Select all

-- Haskell
globalFunction =
   let
      x = 0
      NAMED_localFunction = print "I can access x, I'm a closure, see: " ++ show x
   in
      NAMED_localFunction


As I explained before closures and anonymous functions are two completly unrelated things. Anonymous functions are NOT known as closures. A Closure is just a function that encloses it's scope.

And the reverse is also true: A local function - named or unnamed - doesn't necessarily have to be a closure.

Code: Select all

// D

void globalFunction()
{
   int x = 0;  // local variable
   static void NAMED_nonClosure_localFunction() // in D static makes the local function a non-closure
   {
       printf("I'm not a closure. Trying to access x woulb be a failure, as this function does not enclose its scope!");
   }
   NAMED_nonClosure_localFunction();
}


Okay, sure, but Cobra has methods instead of functions. Cobra is not LISP or Haskell. And Cobra does not yet have nested, named methods, but will someday. When it does, I'm not sure I'll bother supporting declaring a static/shared method inside an instance method.

And yes, if an anon method does not access vars in its containing method then we can say it's not a closure. But that's a particular case that isn't distinguishing every time, especially in subject headers. And even when that case takes place, the term "anonymous method" still holds which is probably why the C# guys chose it as the primary term.

In both C# and Cobra, an anonymous method is always an anonymous method. It's also a closure if it references outer variables (http://en.wikipedia.org/wiki/Closure_(computer_science)). So the primary term will remain "anonymous method" as in "a method without a name".

I hope that clears things up.

[jonathandavid]

Currently it does not. The syntax I'm contemplating is:

.foo(x, do(a is int, b as int), do(s as String))
    do
        return a + b
    do
        return s.trim.toLower

So if you have more than one anonymous method then you have a "do" for each one and put the block of code underneath that.

Feedback is welcome.

I like this idea very much. I think Guido Van Rossum once said that multiline lambdas were impossible syntactically, but maybe this option did not occur to him.

Since lambdas are used for the conciseness they bring, I would vote for the following shortcut version that would be used when only one delegate is expected:

.foo(x, do(a,b))      # parameter types implicit, would not work in case of ambiguity (i..e, more than one foo that takes an "x" and a two param. delegate)
      result = a + b
      return result

Note that this reminiscent of Ruby's block parameters, or whatever they're called. So much, that we could add an elegant "each" extension method to IList<of T>:

names.each(do(name))
    print name

I know this can be achieved with "for name in names...", but this feature would allow for a much greater flexibility. For example, a count method for collections:

n = names.count(do(name))  # n = strings in "names" with length > 10
    return name.length > 10

Finally, maybe Ruby's || syntax could lead to cleaner code. Judge for yourselves:

names.each(|name|)
    print name

n = names.count(|name|) 
    return name.length > 10

We could even drop the parentheses when all they do is wrap a pair of "|"s.

Also, how often are you encountering this with .NET libraries (whether from MS or third party)?

Not very often, but I think that is because typical .NET languages are not too functional programming-friendly, and thus hinder the adoption of this kind of constructs. For example, an "each" method like the one above would be writable in C#, but its use would be to cumbersome to make it a viable alternative to a regular foreach loop. One feature I would definitely like to see in Cobra is a function that takes a delegate can be declared without having to declare the delegate first. For example, the count method above:

extend IList<of T>
def count(pred as |String -> bool|) as int
     # implement the counting logic, calling "pred" for each item in the list

Note that I've made up a syntax for declaring a delegate on the fly.

[Charles]

-- I'm guessing Gudio probably did consider that syntax on his own or as a suggestion, but didn't like it. I thought what he/they got hung up on was the way the call is closed with a right paren even though there is more stuff to follow (the body of the closure). In any case, I've always felt it was more important to have them than to not. In other words, even if the syntax is not 100% perfect, I still want closures!

-- The shortcut syntax you are proposing is the current syntax!
Give it a try and let me know if you have any problems. Poke around the test cases for examples. Make a wiki page. (Unless I misread; I'm tired right now...)

-- I'm not fond of the Ruby/Smalltalk syntax for Cobra. The do(a,b) in Cobra is reminiscent of its own def(a, b) syntax.

-- If we allowed delegate declaration on the fly it would be something more like:

def count(pred as sig StringToBool(s as String) as bool) as int

# or

def count(pred as do(s as String) as bool) as int

I'm undecided as to allowing them to be inlined or not. The sig's are pretty easy. They're just like a "def" but use "sig" and a capped type name.

[jonathandavid]

I'm undecided as to allowing them to be inlined or not

Please allow them, I hate having to think of a name for something that I won't use on any other place. I'm not particularly fond of the syntax you suggest, but of course yours is the last voice. And I agree that sticking with "do(...) as" is more consistent with the rest of the language that my "|->|"-based proposal.

One thing I would really like is the ability to omit the names of the parameters on a delegate. Again, it's one of those situations where I don't like having to come up with names for things that I will not be referring too.

sig SomeFunc(x as int, y as float) as String    # would become:  sig SomeFunc(as int, as float) as String

I've left the "as" so that it doesn't look too much like C#