Forums

Anonymous methods, also known as closures

General discussion about Cobra. Releases and general news will also be posted here.
Feel free to ask questions or just say "Hello".

Re: Anonymous methods, also known as closures

Postby Charles » Mon Dec 08, 2008 12:38 am

gauthier wrote: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.
Charles
 
Posts: 2510
Location: Los Angeles, CA

Re: Anonymous methods, also known as closures

Postby gauthier » Mon Dec 08, 2008 12:53 am

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.
gauthier
 
Posts: 116

Re: Anonymous methods, also known as closures

Postby Charles » Mon Dec 08, 2008 2:01 am

Fixed, tested and checked in.
Charles
 
Posts: 2510
Location: Los Angeles, CA

Re: Anonymous methods, also known as closures

Postby helium » Mon Dec 08, 2008 11:08 am

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

OK, now it gets plain stupid. :roll: Sorry, but I leave this forum.
helium
 
Posts: 14

Re: Anonymous methods, also known as closures

Postby gauthier » Mon Dec 08, 2008 11:18 am

helium wrote:OK, now it gets plain stupid. :roll: Sorry, but I leave this forum.


I don't get it...

helium wrote: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 ;)
gauthier
 
Posts: 116

Re: Anonymous methods, also known as closures

Postby Charles » Mon Dec 08, 2008 2:04 pm

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
 
Posts: 2510
Location: Los Angeles, CA

Re: Anonymous methods, also known as closures

Postby Charles » Mon Dec 08, 2008 2:13 pm

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

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

Chuck wrote:-- 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.
Charles
 
Posts: 2510
Location: Los Angeles, CA

Re: Anonymous methods, also known as closures

Postby jonathandavid » Wed Feb 04, 2009 6:32 am

Chuck wrote: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.


Chuck wrote: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.
jonathandavid
 
Posts: 159

Re: Anonymous methods, also known as closures

Postby Charles » Wed Feb 04, 2009 6:58 am

-- 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.
Charles
 
Posts: 2510
Location: Los Angeles, CA

Re: Anonymous methods, also known as closures

Postby jonathandavid » Wed Feb 04, 2009 10:09 am

Chuck wrote: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# :)
jonathandavid
 
Posts: 159

PreviousNext

Return to Discussion

Who is online

Users browsing this forum: No registered users and 2 guests

cron