February 25, 2003
"Dan Liebgold" <Dan_member@pathlink.com> wrote in message news:b3ghmn$1al3$1@digitaldaemon.com...
> p.s. I don't want to start a Lisp flame war, so I take it all back if
you're
> offended!

Not at all! I'm in the wrong business if I'm easilly offended!

> Also, I use Lisp (again, a commercial version) daily so I'm not
> (necessarily) speaking from ignorance....

And that makes your comments on it especially worth reading. My knowledge of Lisp is minimal, and I've written little more in it than a few emacs functions.


February 25, 2003
I second that,
anon delegates do replace inner classes in most places (but I still like
them).
before I run into problems I just want to check something

in your example of a nested function uses as a delegate
A delegate can be set to a non-static nested function:
	int delegate() dg;

	void test()
	{   int a = 7;
	    int foo() { return a + 3; }

	    dg = foo;
	    int i = dg();	// i is set to 10
	}
I assume at the time dg = foo is executed foo is closed so changes to a do
not effect the return value of foo
also is the following valid
	int delegate() dg;

	dg test( int param )
	{
            int a = param+1;
            int foo() { return a + 3; }

	    return foo;
	}

or will foo try to reference a value on the stack which will not exist when
test returns
or even worse
	int delegate() dg;

	dg test( int param )
	{            int a = param+1;            int foo() { return a = a + 3; }

	    return foo;
	}

fyi: Java does have closures of a sort
MyInferface foo( int param ) {
    final int a = param + 1; // is realy int[]a = new int [1]; a[0] =
param+1;
    return new MyInterface() { int func() { return a = a + 3; }
// class this$0 implements MyInterface { final int[] _a; this$0(int[] a0)
{ _a = a0; }
// public int func() { return _a[0] = _a[0] + 3; }
// }
// return new this$0( a );
}



"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3E5B8A00.5E699634@deming-os.org...
> Walter wrote:
>
> > Some long overdue features.
> >
> > www.digitalmars.com/d/changelog.html
>
> Non C-style function pointer declaration?
> Function literals?
> Nested functions?
> Closures???
> YAAAAAAAAAAAAAAAAAAAAAAAAAY!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>
> --
> The Villagers are Online! http://villagersonline.com
>
> .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
> .[ (a version.of(English).(precise.more)) is(possible) ]
> ?[ you want.to(help(develop(it))) ]
>
>


February 25, 2003
"Burton Radons" <loth@users.sourceforge.net> wrote in message news:b3gis9$1bf0$1@digitaldaemon.com...
> > In earlier versions, the & was required. In 0.57, either will work. I'm thinking of obsoleting the & version.
> Removing that would make properties impossible.

Please elaborate.


February 25, 2003
"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:b3gj28$1bii$1@digitaldaemon.com...
> in your example of a nested function uses as a delegate
> A delegate can be set to a non-static nested function:
> int delegate() dg;
>
> void test()
> {   int a = 7;
>     int foo() { return a + 3; }
>
>     dg = foo;
>     int i = dg(); // i is set to 10
> }
> I assume at the time dg = foo is executed foo is closed so changes to a do
> not effect the return value of foo

No. Both foo() and bar() are referring to the same instance of 'a', so
either can read/write to it and affect the other. It works exactly as if
foo() was passed &a, and the body of foo() was accessing it through that
pointer.

> also is the following valid
> int delegate() dg;
>
> dg test( int param )
> {
>             int a = param+1;
>             int foo() { return a + 3; }
>
>     return foo;
> }
>
> or will foo try to reference a value on the stack which will not exist
when
> test returns

That is invalid code. The reference to 'a' is invalid after test() returns. If you think about it as being implemented with pointers to 'a', the semantics will become clear.

> or even worse
> int delegate() dg;
>
> dg test( int param )
> {            int a = param+1;            int foo() { return a = a + 3; }
>
>     return foo;
> }

That's invalid too for the same reason. As Dan pointed out, D implements lexical closures, not semantic closures.


> fyi: Java does have closures of a sort
> MyInferface foo( int param ) {
>     final int a = param + 1; // is realy int[]a = new int [1]; a[0] =
> param+1;
>     return new MyInterface() { int func() { return a = a + 3; }
> // class this$0 implements MyInterface { final int[] _a; this$0(int[] a0)
> { _a = a0; }
> // public int func() { return _a[0] = _a[0] + 3; }
> // }
> // return new this$0( a );
> }

I'm not sure if those could be considered closures or not.


February 25, 2003
OK, I'm gonna play the devil's advocate some more now, hope you'll excuse me for that, but...why is it useful to be able to declare nested functions?

The reason for having general functions / procedures is to have the ability to break up a problem into smaller subproblems, and then solving each subproblem which is easier to do. You continue to do so until you arrive at problems that can be solved by single statements or machine instructions. Basic divide-and-conquer

Nested functions are normal functions with additional scoping restrictions. Do they allow you to better match the structure of a problem? Could it be a matter of taste perhaps? I don't see a real use case, and since I am sort of a minimalist I would leave them out unless there is a good reason to put them in. Yes, I believe you can implement them, even efficiently. But being able to jump off a cliff doesn't mean that you have to...


February 25, 2003
"Jeroen van Bemmel" <anonymous@somewhere.com> wrote in message news:b3grne$1hat$1@digitaldaemon.com...
> OK, I'm gonna play the devil's advocate some more now, hope you'll excuse
me
> for that, but...why is it useful to be able to declare nested functions?

Speak of the devil <g> I just wrote this example:

www.digitalmars.com/d/pretod.html#codefactoring

The C version is done with macros, but if you want, try it with C++ inline functions.


February 25, 2003
That's fast....

I can see your point when comparing it to old-style C macro's, no argument there. However, in the "OO world" ( many discussions on OO vs functional aside ) you would probably introduce 'stack' as an abstract data type (it might already be in your runtime libary under, say, lang.util...) and encapsulate all those little functions there. Agreed, it's a matter of taste/hype/era, a different cross section of the problem domain. But still, thinking also in terms of reuse, if you end up with a couple of those inline functions you'll probably find yourself declaring them time and time again ( the push() and pop() in your example are most likely not the only place in the program where they are used, JVMs tend to push and pop a lot) until you finally decide to factor them out to only have to declare them once...

So, resuming, nested functions are one way of factoring, there are others


February 26, 2003
The linker doesn't seem to like it when you put two function literals in the same function.

Also, this doesn't seem to work.  Should it? (not that it's useful in any way)

delegate() { printf("stop the insanity!\n"); }();

Walter wrote:
> Some long overdue features.
> 
> www.digitalmars.com/d/changelog.html
> 
> 
> 

February 26, 2003
"Andy Friesen" <andy@ikagames.com> wrote in message news:b3h201$1l7n$1@digitaldaemon.com...
> The linker doesn't seem to like it when you put two function literals in the same function.

I should fix that.

> Also, this doesn't seem to work.  Should it? (not that it's useful in
> any way)
>
> delegate() { printf("stop the insanity!\n"); }();

It should work, although I agree it's useless.


February 26, 2003
"Jeroen van Bemmel" <anonymous@somewhere.com> wrote in message news:b3guds$1ja3$1@digitaldaemon.com...
> I can see your point when comparing it to old-style C macro's, no argument there. However, in the "OO world" ( many discussions on OO vs functional aside ) you would probably introduce 'stack' as an abstract data type (it might already be in your runtime libary under, say, lang.util...) and encapsulate all those little functions there. Agreed, it's a matter of taste/hype/era, a different cross section of the problem domain.

Also, nested functions aren't really an OO concept. But the example I used is a (greatly simplified) example of production quality code I've encountered more than once. The nested function route has the great advantage of resulting in code that is every bit as efficient as the C macro technique - there's no compromise.

> But still,
> thinking also in terms of reuse, if you end up with a couple of those
inline
> functions you'll probably find yourself declaring them time and time again
> ( the push() and pop() in your example are most likely not the only place
in
> the program where they are used, JVMs tend to push and pop a lot) until
you
> finally decide to factor them out to only have to declare them once...

Inline functions suffer from the same problem of lack of access to local variables in the enclosing scope - you need to create a context struct and pass that as a pointer. See the next example www.digitalmars.com/d/ctod.html#traversal which is a (again, greatly simplified) piece of code from my own work.

> So, resuming, nested functions are one way of factoring, there are others

Sure. But nested functions are a simple and direct way of doing it without using pointers or creating extra wrapper object types just to encapsulate/transmit them.