www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - IDEA: Member Function Literals

reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Hopefully, the following syntax is marginally readable without an 
explanation:

class Foo {
   int x(int) {...};
   int y() {...};
};

Foo f = ...;
int delegate() d = f.delegate int() {
     return this.x(this.y());
   }


Ok, in case it's not immediately readable, here's the idea.  The 
'f.delegate...' code declares a class delegate (a delegate where the 
built-in pointer points to an object) as a literal (that is, the 
function body is provided in the statement instead of in a separate 
declaration).

Currently, the only supported way to do this in D would be to derive a 
wrapper class:

class Foo_DelegateWrapper {
   Foo foo;
   int func() {
     return foo.x(foo.y());
   }
}
Foo_DelegateWrapper wrapper = new Foo_DelegateWrapper;
wrapper.foo = f;
del = &wrapper.func;


Thoughts?
Jun 06 2004
next sibling parent Arcane Jill <Arcane_member pathlink.com> writes:
In article <ca13oe$1p9e$1 digitaldaemon.com>, Russ Lewis says...

Thoughts?

Have you been studying Lisp or Haskell? :-) But yeah, it's cool. Actually, a lot of interpreted languages can do similar stuff. BASIC has always had EVAL(), and PHP can execute its own strings. Never seen it in a non-functional compiled language though. Jill
Jun 07 2004
prev sibling parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
Russ Lewis wrote:

 Hopefully, the following syntax is marginally readable without an
 explanation:
 
 class Foo {
    int x(int) {...};
    int y() {...};
 };
 
 Foo f = ...;
 int delegate() d = f.delegate int() {
      return this.x(this.y());
    }

How about doing: Foo f = ...; int delegate() d = delegate int() { return f.x(f.y()); } The delegate will remember the stack frame and take f from there. Of course this will have two major drawbacks: * The value of f is not taken at definition time of the delegate but at the time of execution. * The delegate cannot be returned from the function. To solve these two problems, you would either need bound arguments for function closures (As Sather has them) or define a wrapper class as you do it.
Jun 07 2004
parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Stack duplicates need a way to be copied so that they can be returned. 
Basically, the process would be to copy the stack frame into the heap. 
This would mean that, when the delegate is executed, it would use the 
values that were valid in the stack when the delegate was created.

I have two ideas for the syntax for this.  The first is more "correct", 
but is sort of hard to read; the latter is more readable but requires 
some special syntax:

FIRST:
int delegate() d = delegate int() {
     return f.x(f.y());
   }.dup;

SECOND:
int delegate() d = delegate.dup int() {
     return f.x(f.y());
   };


My thoughts on the rules of stack copying:
* Only allow it at the moment the delegate is created...never later
* Make it illegal if there are any 'auto' locals in the stack frame

I'm working on a function which (sort of hackishly) copies a stack 
delegate to a heap delegate...but haven't had time to polish it yet. 
Hopefully I'll be able to post it before too long.

Russ

Norbert Nemec wrote:
 Russ Lewis wrote:
 
 
Hopefully, the following syntax is marginally readable without an
explanation:

class Foo {
   int x(int) {...};
   int y() {...};
};

Foo f = ...;
int delegate() d = f.delegate int() {
     return this.x(this.y());
   }

How about doing: Foo f = ...; int delegate() d = delegate int() { return f.x(f.y()); } The delegate will remember the stack frame and take f from there. Of course this will have two major drawbacks: * The value of f is not taken at definition time of the delegate but at the time of execution. * The delegate cannot be returned from the function. To solve these two problems, you would either need bound arguments for function closures (As Sather has them) or define a wrapper class as you do it.

Jun 07 2004