www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Suggestion: "new delegate" - delegates useable outside of the nesting

reply Burton Radons <burton-radons smocky.com> writes:
I use delegates a lot but the fact that they can only live until the end 
of the nesting function scope means I need to use classes in many cases, 
which is a lot more typing (and fluff telling the autodoc that it's not 
part of the public API, and other problems) when it could be easily 
fixed. The syntax change would be very simple:

	dispatcher.add (new delegate void (Event event) { ... });

And the effect would be simple as well: duplicate the calling context's 
stack to the extent that the delegate can see it and use the duplicated 
pointer as the "this" pointer; otherwise it's a regular nested delegate. 
Five minutes work max, very topical changes, explicit allocation, big 
benefits. Is good!
Jun 02 2006
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Burton Radons" <burton-radons smocky.com> wrote in message 
news:e5qkhd$2a1u$1 digitaldaemon.com...
I use delegates a lot but the fact that they can only live until the end of 
the nesting function scope means I need to use classes in many cases, which 
is a lot more typing (and fluff telling the autodoc that it's not part of 
the public API, and other problems) when it could be easily fixed. The 
syntax change would be very simple:

 dispatcher.add (new delegate void (Event event) { ... });

 And the effect would be simple as well: duplicate the calling context's 
 stack to the extent that the delegate can see it and use the duplicated 
 pointer as the "this" pointer; otherwise it's a regular nested delegate. 
 Five minutes work max, very topical changes, explicit allocation, big 
 benefits. Is good!
Haha, funny thing is, I'm implementing this _exact_ feature with virtually the same syntax in a small D-like scripting language I'm writing, although I use 'function' instead of 'delegate' (as there is no distinction between the two in my language). This feature is called "static closures," and is very useful indeed. D's dynamic closures (that is, the context for the nested function exists as long as its owning function doesn't return) are fairly useful, but have the one major downside which you point out. Implementing static closures in D would be an interesting proposition, as they would technically be objects, though implicitly. Then there's the problem with RAII class references. Consider something like: char delegate() createFileReader(char[] fileName) { auto File f = new File(fileName, FileMode.In); return new delegate char() { return f.getc(); }; } This function would return a function that would be used to read (very simply) a file, one character at a time. The problem is that the File reference in the enclosing scope could not be deleted when createFileReader returns. I suppose the way around this would be to disallow using RAII class references inside static closures, but..
Jun 02 2006
parent reply Markus Dangl <danglm in.tum.de> writes:
 Implementing static closures in D would be an interesting proposition, as 
 they would technically be objects, though implicitly.  Then there's the 
 problem with RAII class references.  Consider something like:
 
 char delegate() createFileReader(char[] fileName)
 {
     auto File f = new File(fileName, FileMode.In);
 
     return new delegate char()
     {
         return f.getc();
     };
 }
 
 This function would return a function that would be used to read (very 
 simply) a file, one character at a time.  The problem is that the File 
 reference in the enclosing scope could not be deleted when createFileReader 
 returns.  I suppose the way around this would be to disallow using RAII 
 class references inside static closures, but.. 
You might find my "AdvancedDelegate" library useful, i recently posted it to the announce newsgroup. Using its templates for partial application of functions and delegates, you can do something very similiar to the code above: AdvancedDelegate0!(char) createFileReader(char[] fileName) { auto File f = new File(fileName, FileMode.In); auto readerFunc = AdvancedDelegate( function char(File f) { return f.getc(); } ); return readerFunc(f); }
Jun 14 2006
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Markus Dangl" <danglm in.tum.de> wrote in message 
news:e6pr8e$28k3$1 digitaldaemon.com...

 You might find my "AdvancedDelegate" library useful, i recently posted it 
 to the announce newsgroup. Using its templates for partial application of 
 functions and delegates, you can do something very similiar to the code 
 above:
I have been eyeing that ;)
Jun 14 2006
prev sibling parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Markus Dangl wrote:
 You might find my "AdvancedDelegate" library useful, i recently posted 
 it to the announce newsgroup. Using its templates for partial 
 application of functions and delegates, you can do something very 
 similiar to the code above:
 
 AdvancedDelegate0!(char) createFileReader(char[] fileName)
 {
     auto File f = new File(fileName, FileMode.In);
 
     auto readerFunc = AdvancedDelegate(
         function char(File f)
         {
             return f.getc();
         }
     );
     return readerFunc(f);
 }
Hmm.. what's stopping you from returning a 'normal' delegate, thru return &readerFunc(f).Eval or &readerFunc(f).opCall ? it would make more sense to functions which accept char delegate() and have no idea what AdvancedDelegate0!(char) is :) -- Tomasz Stachowiak /+ a.k.a. h3r3tic +/
Jun 14 2006
parent Markus Dangl <danglm in.tum.de> writes:
 Hmm.. what's stopping you from returning a 'normal' delegate, thru 
 return &readerFunc(f).Eval or &readerFunc(f).opCall ? it would make more 
 sense to functions which accept char delegate() and have no idea what 
 AdvancedDelegate0!(char) is :)
The Eval() method is there to really do the evaluation of the delegate. You can easily "convert" an AdvancedDelegate to a delegate by referencing its Eval() method: char delegate() createFileReader(char[] fileName) { File f = new File(fileName, FileMode.In); auto readerFunc = AdvancedDelegate( function char(File f) { return f.getc(); } ); return &(readerFunc(f).Eval); } I see that this isn't very intuitive, so i'm going to add a "GetDelegate" method and overload the "opCast" operator - you can then also write: return readerFunc(f).GetDelegate; or: return cast(char delegate()) (readerFunc(f));
Jun 15 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Burton Radons wrote:
 I use delegates a lot but the fact that they can only live until the end 
 of the nesting function scope means I need to use classes in many cases, 
 which is a lot more typing (and fluff telling the autodoc that it's not 
 part of the public API, and other problems) when it could be easily 
 fixed. The syntax change would be very simple:
 
     dispatcher.add (new delegate void (Event event) { ... });
 
 And the effect would be simple as well: duplicate the calling context's 
 stack to the extent that the delegate can see it and use the duplicated 
 pointer as the "this" pointer; otherwise it's a regular nested delegate. 
 Five minutes work max, very topical changes, explicit allocation, big 
 benefits. Is good!
Unfortunately, it's quite a bit more work than that. You have to copy all the frames of the lexically enclosing functions, too. Then you have the issue of updates to the framed variable copies not being reflected in the stack variables. Then there's the problem of things like: int x; int* px = &x;
Jun 02 2006
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:e5qli2$2ale$1 digitaldaemon.com...

 Then you have the issue of updates to the framed variable copies not being 
 reflected in the stack variables.
This, at least, seems to be a requirement of static closures. In Lua, which supports them, when you instantiate a static closure, the values it uses from enclosing scopes ("upvalues") are "frozen" - they are copied into the closure's instance. Then, updating the value using the closure doesn't affect the original variable. This is an important feature so that multiple instances of closures can be created which don't step on each others' toes, so to speak.
Jun 02 2006
parent Walter Bright <newshound digitalmars.com> writes:
Jarrett Billingsley wrote:
 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:e5qli2$2ale$1 digitaldaemon.com...
 
 Then you have the issue of updates to the framed variable copies not being 
 reflected in the stack variables.
This, at least, seems to be a requirement of static closures. In Lua, which supports them, when you instantiate a static closure, the values it uses from enclosing scopes ("upvalues") are "frozen" - they are copied into the closure's instance. Then, updating the value using the closure doesn't affect the original variable. This is an important feature so that multiple instances of closures can be created which don't step on each others' toes, so to speak.
Sure, you can design the language that way. But I've had uses for ones that *did* update the local variables.
Jun 02 2006
prev sibling parent reply Burton Radons <burton-radons smocky.com> writes:
Walter Bright wrote:

 Burton Radons wrote:
 
 I use delegates a lot but the fact that they can only live until the 
 end of the nesting function scope means I need to use classes in many 
 cases, which is a lot more typing (and fluff telling the autodoc that 
 it's not part of the public API, and other problems) when it could be 
 easily fixed. The syntax change would be very simple:

     dispatcher.add (new delegate void (Event event) { ... });

 And the effect would be simple as well: duplicate the calling 
 context's stack to the extent that the delegate can see it and use the 
 duplicated pointer as the "this" pointer; otherwise it's a regular 
 nested delegate. Five minutes work max, very topical changes, explicit 
 allocation, big benefits. Is good!
Unfortunately, it's quite a bit more work than that. You have to copy all the frames of the lexically enclosing functions, too. Then you have the issue of updates to the framed variable copies not being reflected in the stack variables. Then there's the problem of things like: int x; int* px = &x;
Good points (I forgot about multiple nesting - did I ever compliment you for putting that in with the first release containing nested functions? - but you need to chain anyway so the logic must already be in there to piggyback onto), it is more work but compare it to the work required when it's omitted. I have done terrible things, committed sins against good engineering just because my nesting scope exits, and while it hasn't had a cooling effect on me, I'm sure there have been other people who have resorted to inferior Java class-inheritance techniques just to get around this problem. I have to admit I've done it once or twice. I was young and naive! Frozen variables are, of course, a feature, not a bug, and one the user would opt into by using the "new" variant. We discussed this in 2003. ;-) Anyway in three years and four months I haven't depended on the nesting scope's variables varying once, and while I haven't really wanted them to be frozen either, I've used it a few times in languages which freeze the nesting scopes (like Python). The only really good argument against this originally, in my opinion, was that it was a hidden allocation, but it's explicit like this.
Jun 02 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Burton Radons wrote:
 Walter Bright wrote:
 Unfortunately, it's quite a bit more work than that. You have to copy 
 all the frames of the lexically enclosing functions, too. Then you 
 have the issue of updates to the framed variable copies not being 
 reflected in the stack variables. Then there's the problem of things 
 like:

   int x;
   int* px = &x;
Good points (I forgot about multiple nesting - did I ever compliment you for putting that in with the first release containing nested functions? - but you need to chain anyway so the logic must already be in there to piggyback onto), it is more work but compare it to the work required when it's omitted. I have done terrible things, committed sins against good engineering just because my nesting scope exits, and while it hasn't had a cooling effect on me, I'm sure there have been other people who have resorted to inferior Java class-inheritance techniques just to get around this problem. I have to admit I've done it once or twice. I was young and naive! Frozen variables are, of course, a feature, not a bug, and one the user would opt into by using the "new" variant. We discussed this in 2003. ;-) Anyway in three years and four months I haven't depended on the nesting scope's variables varying once, and while I haven't really wanted them to be frozen either, I've used it a few times in languages which freeze the nesting scopes (like Python). The only really good argument against this originally, in my opinion, was that it was a hidden allocation, but it's explicit like this.
What about the px problem above? This wouldn't occur in Python which doesn't have pointers, but it sure happens in D.
Jun 02 2006
parent reply Burton Radons <burton-radons smocky.com> writes:
Walter Bright wrote:

 Burton Radons wrote:
 
 Walter Bright wrote:

 Unfortunately, it's quite a bit more work than that. You have to copy 
 all the frames of the lexically enclosing functions, too. Then you 
 have the issue of updates to the framed variable copies not being 
 reflected in the stack variables. Then there's the problem of things 
 like:

   int x;
   int* px = &x;
Good points (I forgot about multiple nesting - did I ever compliment you for putting that in with the first release containing nested functions? - but you need to chain anyway so the logic must already be in there to piggyback onto), it is more work but compare it to the work required when it's omitted. I have done terrible things, committed sins against good engineering just because my nesting scope exits, and while it hasn't had a cooling effect on me, I'm sure there have been other people who have resorted to inferior Java class-inheritance techniques just to get around this problem. I have to admit I've done it once or twice. I was young and naive! Frozen variables are, of course, a feature, not a bug, and one the user would opt into by using the "new" variant. We discussed this in 2003. ;-) Anyway in three years and four months I haven't depended on the nesting scope's variables varying once, and while I haven't really wanted them to be frozen either, I've used it a few times in languages which freeze the nesting scopes (like Python). The only really good argument against this originally, in my opinion, was that it was a hidden allocation, but it's explicit like this.
What about the px problem above? This wouldn't occur in Python which doesn't have pointers, but it sure happens in D.
What about if the user calls a nested function outside of the nesting scope? They both have pitfalls. I don't really want to mention it, but if you invert the logic it continues to act the same without this pitfall; the only change is that you can call the nested function outside of the nesting scope. What I mean is that instead of just passing the delegate a pointer to the frame, allocate the frame at the start if it or a nested scope has a "new delegate" and use that for both the delegate and that scope: float bar = 6; void delegate () dg = new delegate void () { bar = 8; } Becomes: struct Delegate { void *self, func; } struct Frame { float bar; Delegate dg; } Frame *frame = new Frame; Delegate dg; frame.bar = 6; frame.dg = Delegate { frame, function void (Frame *frame) { frame.bar = 8; } }; Oh no, it's all syntax sugar! :-) The logic for doing this should mostly already be in the code. This might be well-justified because it makes nested functions behave consistently, and with some more effort it would only allocate a frame containing variables the nesting functions actually use.
Jun 03 2006
parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Burton Radons wrote:
 (...)
Please, don't use suspicious whitespace sequences ! LOL http://158.75.59.9/~h3/tmp/lolAtAvast.png
Jun 03 2006
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Tom S wrote:
 Burton Radons wrote:
 (...)
Please, don't use suspicious whitespace sequences ! LOL http://158.75.59.9/~h3/tmp/lolAtAvast.png
Wow. That's one touchy virus scanner. I never knew that whitespace was so dangerous (well, I suppose if you feed to the http://en.wikipedia.org/wiki/Whitespace_programming_language interpreter, it might be). -- Daniel -- Unlike Knuth, I have neither proven or tried the above; it may not even make sense. v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP http://hackerkey.com/
Jun 03 2006