Thread overview
IDEA: Member Function Literals
Jun 07, 2004
Russ Lewis
Jun 07, 2004
Arcane Jill
Jun 07, 2004
Norbert Nemec
Stack Delegate Copying was: IDEA: Member Function Literals
Jun 07, 2004
Russ Lewis
June 07, 2004
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?

June 07, 2004
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


June 07, 2004
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.

June 07, 2004
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.