Walter,

Can I do anonymous delegates? Something along the lines of

void someFunction( Collection c, int i )
{
...
     c.traverse( int delegate( Object x ) {
        x.doSomething();
        return i + x.getCount();
     } );
...
}

( again some restrictions here in not allowing 'traverse' to store a reference to this local delegate )

Yes!

"Jeroen van Bemmel" <anonymous@somewhere.com> wrote in message news:b3o6t2$30mt$1@digitaldaemon.com...
> Walter,
>
> Can I do anonymous delegates? Something along the lines of
>
> void someFunction( Collection c, int i )
> {
> ...
>      c.traverse( int delegate( Object x ) {
>         x.doSomething();
>         return i + x.getCount();
>      } );
> ...
> }
>
> ( again some restrictions here in not allowing 'traverse' to store a reference to this local delegate )
>
>

Jeroen van Bemmel wrote:
> void someFunction( Collection c, int i )
> {
> ...
>      c.traverse( int delegate( Object x ) {
>         x.doSomething();
>         return i + x.getCount();
>      } );
> ...
> }

Just reverse the delegate and the int keywords and it'll be hot to trot.

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:b3ohda$62a$2@digitaldaemon.com...
> Jeroen van Bemmel wrote:
> > void someFunction( Collection c, int i )
> > {
> > ...
> >      c.traverse( int delegate( Object x ) {
> >         x.doSomething();
> >         return i + x.getCount();
> >      } );
> > ...
> > }
>
> Just reverse the delegate and the int keywords and it'll be hot to trot.
>

WARNING .... the delegate references the parameter 'i', this is only safe to
do if traverse does not store the delegate.
it is not like a Java anon class (which can only access finals in the outer
scope.).
underneath the simple syntax waits a smoking gun.

> WARNING .... the delegate references the parameter 'i', this is only safe
to
> do if traverse does not store the delegate.
> it is not like a Java anon class (which can only access finals in the
outer
> scope.).
> underneath the simple syntax waits a smoking gun.
>

See the ( comment ) on my original post, that's why I chose a method 'traverse' with semantics that are likely to use the delegate immediately, rather than storing it. 'setCallback' for example would have been bad

"Jeroen van Bemmel" <anonymous@somewhere.com> wrote in message news:b3oroo$dep$1@digitaldaemon.com...
>
> > WARNING .... the delegate references the parameter 'i', this is only
safe
> to
> > do if traverse does not store the delegate.
> > it is not like a Java anon class (which can only access finals in the
> outer
> > scope.).
> > underneath the simple syntax waits a smoking gun.
> >
>
> See the ( comment ) on my original post, that's why I chose a method 'traverse' with semantics that are likely to use the delegate immediately, rather than storing it. 'setCallback' for example would have been bad
>
O.k., but its still BIG warning, nested function are ok in my book, but
delegates (being an object and a method) especially in a language with GC
one would expect to be safe to hang onto for a bit.
IMHO this is another example of D being lead by implementation and not by
semantics.
(the Object to which the delgate is attached could be a copy of the stack
frame at the time of creation [might cause problems in a  deaper nested func
where you would need several stack frames copied])

just like the code I posted before (returning a slice from static array)
this is just another way for the unwary to scrible on the stack
yet again I am confused by the direction that D is progressing more features
are being added and each adds more pit falls rather than removing them. to
anyone who has used (dare I mention it) Perl, Java or Scheme might not
expect the dangers that lurk within the use of inner functions as delegates.
in 90% of the projects I've worked on robustness and ability to prove
robustness where more important than speed, so I'm a bit anti features that
would adversly effect potential changes to the code they call.

in you example what would happen if someone implemented lazy traversal (hold the delegate and only process if the result was required). the beauty of GC'd lang's is you can (usually) without worrying about who hold what when and why.

"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:b3p5fg$lj2$1@digitaldaemon.com...
> (the Object to which the delgate is attached could be a copy of the stack frame at the time of creation [might cause problems in a  deaper nested
func
> where you would need several stack frames copied])

The semantic downside of that is that the stack variables so captured cannot be modified in a way that the outer function can access, for example, see www.digitalmars.com/d/cpptod.html#closures

"Walter" <walter@digitalmars.com> wrote in message news:b3p6cc$m0j$1@digitaldaemon.com...
>
> "Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:b3p5fg$lj2$1@digitaldaemon.com...
> > (the Object to which the delgate is attached could be a copy of the
stack
> > frame at the time of creation [might cause problems in a  deaper nested
> func
> > where you would need several stack frames copied])
>
> The semantic downside of that is that the stack variables so captured
cannot
> be modified in a way that the outer function can access, for example, see www.digitalmars.com/d/cpptod.html#closures
>

then follow the Java approach use final and put the value into the heap.

final int i;   // becomes int * i = new int;

this gives the same semantics, but without the pit falls, at the expence of
a new,
with a thread local memory block to allocate from this is not a great
overhead, unless you using a delegate from a nested func within a recusive
func that is recuring. or you are calling that function a lot (in which case
the old phrase optimise your algorithm not your code, comes to mind).

or allow something like

 class Collection
	{
	    int[10] array;

	    void apply(void delegate(int) fp)
	    {
		for (int i = 0; i < array.length; i++)
		    fp(array[i]);
	    }
	}

	void func(Collection c)
	{
	    int max = int.min;

	    void comp_max(int i)
	    {
		if (i > max)
		    max = i;
	    }

    // creation of delegate from comp_max captures stack frame at this point
in the code
     c.apply(comp_max);
    max = com_max.max; // restore from captured frame
 }

against the java way

 void func(Collection c)
{
    final int max = int.min; // int * max = new int; *max = int.min; or C++
int & max = *new int;

    void comp_max(int i)
    {
if (i > max)        //  i>*max
    max = i;    // *max = i;
    }

    // creation of delegate from comp_max captures stack frame at this point
in the code still, but its capturing
    // int * not int.
     c.apply(comp_max);
    foo = max; // foo = *max;
 }

In article <b3p5fg$lj2$1@digitaldaemon.com>, Mike Wynn says...
>
>just like the code I posted before (returning a slice from static array)
>this is just another way for the unwary to scrible on the stack
>yet again I am confused by the direction that D is progressing more features
>are being added and each adds more pit falls rather than removing them. to
>anyone who has used (dare I mention it) Perl, Java or Scheme might not
>expect the dangers that lurk within the use of inner functions as delegates.
>in 90% of the projects I've worked on robustness and ability to prove
>robustness where more important than speed, so I'm a bit anti features that
>would adversly effect potential changes to the code they call.
>


Yikes...  well my initial enthusiasm for the idea has given way to dread.  I must completely concur with Mike's assessment.  Again, someone coming from a Lisp/Scheme background would be unpleasantly surprised by this sort of closure behavior.  Even coming from a more C/C++ background -- the bug you might introduce is just too subtle and (seemingly) unrelated.

It doesn't seem right for the language to contain this sort of built-in hole (and I don't believe a run time check would really be both sufficient and efficient enough).   The design-by-contract features of D indicate a push for reliability that this sort of dynamic stack-based closures undermine.

The method Lisp uses to ensure that both the current function and any delegates access the same copies of the local environment is to not keep the locals on the stack (the environment is heap allocated when the function is called). In theory, only functions which require closures will need to avoid using the stack... so performance can be maintained in the majority of cases.

Dan

Mike Wynn wrote:
> just like the code I posted before (returning a slice from static array)
> this is just another way for the unwary to scrible on the stack
> yet again I am confused by the direction that D is progressing more features
> are being added and each adds more pit falls rather than removing them. to
> anyone who has used (dare I mention it) Perl, Java or Scheme might not
> expect the dangers that lurk within the use of inner functions as delegates.
> in 90% of the projects I've worked on robustness and ability to prove
> robustness where more important than speed, so I'm a bit anti features that
> would adversly effect potential changes to the code they call.

This reminds me of an ancient joke.  Guy in an appointment with his doctor says "Doc, it hurts when I do this."  Doctor replies, "Well, don't do that."