www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Anonymous Delegates

reply Erik Lechak <prochak netzero.net> writes:
Hello all,

This is a trivial example that got me excited about delegates:

import std.stdio;

class Dog{
    string name;
    
    this( string name){
        this.name = name;
    }
    
    void printName(){
        writefln(name);
    }
}

int main(string [] args){
    Dog kippy = new Dog("kippy");
    void delegate() name = &kippy.printName;
    name();
    return 0;
}


Now for some real-world gtk stuff.  What does the anonymous delegate buy me in
the next bit of code.  Even if it wasn't a super trivial callback, I don't know
why it is better as a delegate than a function pointer.

Button b = cast(Button)g.getWidget("button1");
b.addOnClicked( delegate void(Button aux){ exit(0); } );

I found myself using the equivalent C code to connect the widget to the
callback, but I want to do it the D ( or at least the gtkd ) way.  But it just
seems to complicate the code without reason.

I though maybe I could do this:
b.addOnClicked( delegate void(Button aux){ 
    this.doSomethingAButtonCanDo(); 
} );

And somehow the the callback would populate the 'this' variable with the button
that generated the callback.  But instead I get a compile-time error: Error:
'this' is only allowed in non-static member functions, not __dgliteral1.

So if anonymous delegates don't (can't) have an object associated with them,
why do they exist if they are functionally equivalent to a function pointer? 
Or are they not equivalent?  

Then I thought maybe I could cast a callback function to a delegate.  So at
least at some point in the future the signal_autoconnect feature might work,
and I could easily remove the manual registration of callbacks.  But I just get
this error: conversion to non-scalar type requested.

void bc(Button a){
    writefln("adsf");
}

b.addOnClicked( cast( void delegate(Button)) &bc );

Then I read the following documentation:
  "If the keywords function or delegate are omitted, it defaults to being a
delegate."
  "and the following where the return type int is inferred:"

And I saw this:
  int abc(int delegate(long i));
  void test()
  {   int b = 3;
     abc( (long c) { return 6 + b; } );
  }

And this:
   loop(5, 100, { d += 1; } );

Since delegates have a nice shorthand syntax, they must be more important than
I realize. Without an associated object, they just sound like function pointers
to me.

What am I missing?

Thanks,
Erik Lechak
Jun 16 2008
next sibling parent Lutger <lutger.blijdestin gmail.com> writes:
Erik Lechak wrote:
...

 Since delegates have a nice shorthand syntax, they must be more important
 than I realize. Without an associated object, they just sound like
 function pointers to me.
 
 What am I missing?
 
 Thanks,
 Erik Lechak


Anonymous delegates do have of sort-of-this pointer: the stack frame.

An example is clearest:

char[] clickedMessage = "you clicked me!";
button.addOnClicked( (Button aux) { 
    Stdout(clickedMessage).newline; 
} ); 

In D1, as long as the scope where clickedMessage lives is valid, the
delegate passed to addOnClicked can access any variable in it. This can
result in weird bugs of course when that scope is no longer valid, but also
makes delegates very fast. In D2 on the other hand, I believe this will
result in a closure, heap-allocating the surrounding stack frame and
storing it with the delegate. Correct me if I'm wrong, I haven't used this
yet.
Jun 16 2008
prev sibling parent reply Russell Lewis <webmaster villagersonline.com> writes:
Erik Lechak wrote:

 I though maybe I could do this:
 b.addOnClicked( delegate void(Button aux){ 
     this.doSomethingAButtonCanDo(); 
 } );


Not having used gtk much, I'll assume that the Button object passed to 
the callback is the same button as the variable 'b' in your attempt 
above.  So if you want 'b' to call doSomethingAButtonCanDo() when it is 
clicked, then you could write:

BEGIN CODE
   b.addOnClicked(
       delegate void(Button ignored)
       {
         b.doSomethingAButtonCanDo();
       });
END CODE

or, since the argument is the same button, this also works:

BEGIN CODE
   b.addOnClicked(
       delegate void(Button aux)
       {
         aux.doSomethingAButtonCanDo();
       });
END CODE


This still seems a little bit useless.  But as you get more advanced, 
whole new worlds open up.  Let's look at how we might change the gtk API 
to be more delegate-aware.  Since a delegate can carry with it some 
context, we could remove the Button argument from the callback:

BEGIN CODE
    b.addOnClicked_noArg( &b.doSomethingAButtonCanDo );
END CODE

Notice that the syntax above constructs a delegate with 'b' as the 
'this' pointer, and 'doSomethingAButtonCanDo' as the function.

The cool thing, of course, is that you can pass delegates which point to 
any other type of object, so long as the delegate takes no arguments. 
For instance:

BEGIN CODE
    SomeWindowClass w = GetSomeSpecificWindow();
    b.addOnClicked_noArg( &w.closeWindow );
END CODE

Now you see that (in D2, which has full and automatic closure support), 
an anonymous delegate is just another cool thing that can be passed:

BEGIN CODE
    SomeInterestingValue v = <whatever>;
    SomeWindowClass w = GetSomeSpecificWindow();
    b.addOnClicked_noArg({ w.setSomeProperty(v) });
END CODE

Note that in the above example, the 'this' pointer will point to the 
automatically-allocated heap frame, which will store your 'v' and 'w' 
variables, and when the delegate is called, that one-line function will 
be executed.


In my experience, the more that I port my code (and my callbacks) to use 
delegates, the more amazing things get.  It's sometimes hard to see why 
they are so important in trivial examples...but imagine that you were 
carrying around a few dozen local variables.  Then delegates (and 
closures in particular) get *really* nice.

BEGIN CODE
    void myFunction(<some arguments>)
    {
       <set some variables>

       CallLibraryFunction(
          delegate void(<some more arguments>)
          {
             <do something nontrivial which includes all the args & vars 
above>
          });
    }
END CODE
Jun 16 2008
next sibling parent Milke Wey <no.spam example.com> writes:
On Mon, 2008-06-16 at 07:25 -0700, Russell Lewis wrote:

 Not having used gtk much, I'll assume that the Button object passed
 to 
 the callback is the same button as the variable 'b' in your attempt 
 above.


Yes this is the case, but b != this.

-- 
Mike Wey
Jun 16 2008
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Russell Lewis" <webmaster villagersonline.com> wrote in message 
news:g35t4n$22n6$1 digitalmars.com...

 Now you see that (in D2, which has full and automatic closure support), an 
 anonymous delegate is just another cool thing that can be passed:

 BEGIN CODE
    SomeInterestingValue v = <whatever>;
    SomeWindowClass w = GetSomeSpecificWindow();
    b.addOnClicked_noArg({ w.setSomeProperty(v) });
 END CODE

 Note that in the above example, the 'this' pointer will point to the 
 automatically-allocated heap frame, which will store your 'v' and 'w' 
 variables, and when the delegate is called, that one-line function will be 
 executed.


In D1 and D2, what happens if you do something like this:

class MyClass
{
    int delegate() callback;

    void registerCallback(int delegate() callback)
    {
        this.callback = callback;
    }

    void display()
    {
        writefln("{0}", callback());
    }
}

void foo()
{
    int val;
    auto c = new MyClass();

    val = 1;
    c.registerCallback({ return val; })

    val = 2;
    c.display();  // Does this display "1" or "2"?
}

In D1 and D2, does that display "1" or "2"?

As long as I'm asking about delegate stuff, something else I've been 
wondering too: I know this following syntax for calling a function isn't 
supported, but is there any technical reason preventing it from being 
possible?:

// Note that the delegate is the last parameter:
void repeat(int times, int delegate() body)
{
    // BTW, is "auto" omittable here? I didn't
    // think so, but the example here omits it:
    // http://www.digitalmars.com/d/2.0/statement.html#ForeachRangeStatement

    for(auto i; 0..times)
        body();
}

void foo()
{
    // Current method of calling, ugly:
    repeat(7,
    {
        writefln("Calling Callback");
    });

    // Not currently allowed, but is it possibly doable?
    // Much nicer-looking.
    repeat(7)
    {
        writefln("Calling Callback");
    }
}

Sorry if I already brought that up before, I can't remember if I did or not.

Or, maybe for the sake of language consistency it could do something like 
this:

void myfunc(int a, int b, void delegate() foo1, void delegate() foo2, void 
delegate() foo3)
{
  // Do stuff
}

// Standard way:
myfunc(1, 2,
   { /+ do stuff 1 +/ },
   { /+ do stuff 2 +/ },
   { /+ do stuff 3 +/ });

// Crazy Fancy way inspired by the
// function contract "in{}out{}body{}" stuff:
myfunc()
foo1
{
    // do stuff 1
}
a: /+expression here+/,
b
{
    // Do stuff
    return /+expression here+/;
}
foo3
{
    // do stuff 3
}
foo2
{
    // do stuff 2
}
Jun 16 2008
parent reply Jason House <jason.james.house gmail.com> writes:
Nick Sabalausky Wrote:

 In D1 and D2, what happens if you do something like this:
 
 class MyClass
 {
     int delegate() callback;
 
     void registerCallback(int delegate() callback)
     {
         this.callback = callback;
     }
 
     void display()
     {
         writefln("{0}", callback());
     }
 }
 
 void foo()
 {
     int val;
     auto c = new MyClass();
 
     val = 1;
     c.registerCallback({ return val; })
 
     val = 2;
     c.display();  // Does this display "1" or "2"?
 }
 
 In D1 and D2, does that display "1" or "2"?


It will print "2".  The internal context pointer refers to the stack frame from
foo.  When the delegate is called, it'll look up val and find the value of 2. 
If you want to get the value of 1, you'll need to bind val to the call... or
find a way to make capturing a variable by value work for you.  I don't
remember if full closures are part of the latest dmd v1 compiler or if it's
just dmd v2.



 As long as I'm asking about delegate stuff, something else I've been 
 wondering too: I know this following syntax for calling a function isn't 
 supported, but is there any technical reason preventing it from being 
 possible?:


I believe converting from function to delegate is no problem, but the reverse
is.  I believe functions exist for compatibility with C where just a function
pointer is passed in.
Jun 16 2008
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Jason House" <jason.james.house gmail.com> wrote in message 
news:g36f18$lmr$1 digitalmars.com...

 Nick Sabalausky Wrote:

 In D1 and D2, what happens if you do something like this:

 class MyClass
 {
     int delegate() callback;

     void registerCallback(int delegate() callback)
     {
         this.callback = callback;
     }

     void display()
     {
         writefln("{0}", callback());
     }
 }

 void foo()
 {
     int val;
     auto c = new MyClass();

     val = 1;
     c.registerCallback({ return val; })

     val = 2;
     c.display();  // Does this display "1" or "2"?
 }

 In D1 and D2, does that display "1" or "2"?


 It will print "2".  The internal context pointer refers to the stack frame 
 from foo.
 When the delegate is called, it'll look up val and find the value of 2. 
 If you want
 to get the value of 1, you'll need to bind val to the call... or find a 
 way to make
 capturing a variable by value work for you.


I see. The talk about D2's closures creating a copy of the stack frame made 
me wonder if that meant anonymous delegates *normally* acted on a copy of 
the original stack frame (would have printed "1") or on the actual stack 
frame itself (prints "2").


 I don't remember if full closures are part of the latest dmd v1 compiler 
 or if it's just dmd v2.


According to the docs, full closures are D2-only.

In the section "Delegates, Function Pointers, and Closures":

D1 docs: http://www.digitalmars.com/d/1.0/function.html
"The stack variables, however, are not valid once the function declaring 
them has exited, in the same manner that pointers to stack variables are not 
valid upon exit from a function:"

D2 docs: http://www.digitalmars.com/d/2.0/function.html
"The stack variables referenced by a nested function are still valid even 
after the function exits (this is different from D 1.0). This is called a 
closure. Returning addresses of stack variables, however, is not a closure 
and is an error."


 As long as I'm asking about delegate stuff, something else I've been
 wondering too: I know this following syntax for calling a function isn't
 supported, but is there any technical reason preventing it from being
 possible?:


 I believe converting from function to delegate is no problem, but the
 reverse is.  I believe functions exist for compatibility with C where
 just a function pointer is passed in.


That's not what I was referring to. I meant that if you have a function that 
takes a delegate as a paramater, then it would be nice (if it would even be 
possible for the language to allow this) to rewrite a call to that function 
like this:

// From this:
// (Current method of calling, ugly)
repeat(7,
{
    writefln("Calling Callback");
});

// To this (Syntactical sugar):
// (Not currently allowed, but is it possibly doable?
// Much nicer-looking.)
repeat(7)
{
    writefln("Calling Callback");
}
Jun 16 2008
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:g36kpk$15rb$1 digitalmars.com...

 "Jason House" <jason.james.house gmail.com> wrote in message 
 news:g36f18$lmr$1 digitalmars.com...

 Nick Sabalausky Wrote:

 In D1 and D2, what happens if you do something like this:

 class MyClass
 {
     int delegate() callback;

     void registerCallback(int delegate() callback)
     {
         this.callback = callback;
     }

     void display()
     {
         writefln("{0}", callback());
     }
 }

 void foo()
 {
     int val;
     auto c = new MyClass();

     val = 1;
     c.registerCallback({ return val; })

     val = 2;
     c.display();  // Does this display "1" or "2"?
 }

 In D1 and D2, does that display "1" or "2"?


 It will print "2".  The internal context pointer refers to the stack 
 frame from foo.
 When the delegate is called, it'll look up val and find the value of 2. 
 If you want
 to get the value of 1, you'll need to bind val to the call... or find a 
 way to make
 capturing a variable by value work for you.


 I see. The talk about D2's closures creating a copy of the stack frame 
 made me wonder if that meant anonymous delegates *normally* acted on a 
 copy of the original stack frame (would have printed "1") or on the actual 
 stack frame itself (prints "2").


 I don't remember if full closures are part of the latest dmd v1 compiler 
 or if it's just dmd v2.


 According to the docs, full closures are D2-only.

 In the section "Delegates, Function Pointers, and Closures":

 D1 docs: http://www.digitalmars.com/d/1.0/function.html
 "The stack variables, however, are not valid once the function declaring 
 them has exited, in the same manner that pointers to stack variables are 
 not valid upon exit from a function:"

 D2 docs: http://www.digitalmars.com/d/2.0/function.html
 "The stack variables referenced by a nested function are still valid even 
 after the function exits (this is different from D 1.0). This is called a 
 closure. Returning addresses of stack variables, however, is not a closure 
 and is an error."


 As long as I'm asking about delegate stuff, something else I've been
 wondering too: I know this following syntax for calling a function isn't
 supported, but is there any technical reason preventing it from being
 possible?:


 I believe converting from function to delegate is no problem, but the
 reverse is.  I believe functions exist for compatibility with C where
 just a function pointer is passed in.


 That's not what I was referring to. I meant that if you have a function 
 that takes a delegate as a paramater, then it would be nice (if it would 
 even be possible for the language to allow this) to rewrite a call to that 
 function like this:

 // From this:
 // (Current method of calling, ugly)
 repeat(7,
 {
    writefln("Calling Callback");
 });

 // To this (Syntactical sugar):
 // (Not currently allowed, but is it possibly doable?
 // Much nicer-looking.)
 repeat(7)
 {
    writefln("Calling Callback");
 }


Although, come to think of it, if member-function-syntax (is that what it's 
called?) ever gets expanded from arrays to all types, then you'd probably be 
able to do something like this:

{
   writefln("Calling Callback");
}.repeat(7);


Which still isn't quite as nice, but it's (arguably) an improvement over the 
current style. Although, it would require repeat()'s paramaters to be 
defined in the opposite order (unless the "repeat(7){}" syntax *didn't* 
require the delegate to be the last param. Or if it just simply required the 
delegate to be the first param *instead* of requiring it to be the last 
param as I had originally proposed.)

I guess my main point is that I *love* the power that delegates give to D 
(ex: Easy map/reduce in a C-style language, yay!), but I'm jealous of the 
incredibly clean syntax that other languages (like ruby and python) provide 
for their anonymous delegates.
Jun 16 2008
prev sibling parent reply Russell Lewis <webmaster villagersonline.com> writes:
Nick Sabalausky wrote:

  That's not what I was referring to. I meant that if you have a 


function that

 takes a delegate as a paramater, then it would be nice (if it would even be 
 possible for the language to allow this) to rewrite a call to that function 
 like this:
 
 // From this:
 // (Current method of calling, ugly)
 repeat(7,
 {
     writefln("Calling Callback");
 });
 
 // To this (Syntactical sugar):
 // (Not currently allowed, but is it possibly doable?
 // Much nicer-looking.)
 repeat(7)
 {
     writefln("Calling Callback");
 }


Many people have asked for this; we haven't yet been able to convince 
Walter that it is a good idea.
Jun 16 2008
parent downs <default_357-line yahoo.de> writes:
Russell Lewis wrote:

 Nick Sabalausky wrote:

  That's not what I was referring to. I meant that if you have a 


 function that

 takes a delegate as a paramater, then it would be nice (if it would
 even be possible for the language to allow this) to rewrite a call to
 that function like this:

 // From this:
 // (Current method of calling, ugly)
 repeat(7,
 {
     writefln("Calling Callback");
 });

 // To this (Syntactical sugar):
 // (Not currently allowed, but is it possibly doable?
 // Much nicer-looking.)
 repeat(7)
 {
     writefln("Calling Callback");
 }


 
 Many people have asked for this; we haven't yet been able to convince
 Walter that it is a good idea.


Afaik, the closest you can come is repeat(7) = { writefln("Calling callback
back"); } by making repeat return a struct that overloads opAssign. Or opCat.
Or whichever you want.
Jun 17 2008
prev sibling parent Russell Lewis <webmaster villagersonline.com> writes:
Jason House wrote:

 As long as I'm asking about delegate stuff, something else I've been 
 wondering too: I know this following syntax for calling a function isn't 
 supported, but is there any technical reason preventing it from being 
 possible?:


 
 I believe converting from function to delegate is no problem, but the reverse
is.  I believe functions exist for compatibility with C where just a function
pointer is passed in.


We don't have implicit conversion of function pointers to delegates, 
though people have asked for it.  But it's an easy thing to do with an 
anonymous delegate:

BEGIN CODE
    void function(<args>) my_fp = <whatever>;
    void delegate(<args>) my_dg =
               delegate void(<args>) { my_fp(<args>); };
END CODE

You can't convert a delegate to a function pointer because a function 
pointer doesn't have any way to store a 'this' parameter.  However, if 
you need to call a delegate from C code, it's still possible; you simply 
have to allocate a delegate on the heap (with new), and save the 
delegate there; pass the pointer to that heap variable as a void* to the 
C code.  Then write an extern(C) wrapper which, given a void*, will turn 
it into a pointer-to-delegate and then call the delegate.
Jun 16 2008