Some long overdue features.

www.digitalmars.com/d/changelog.html

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))) ]

"Walter" <walter@digitalmars.com> wrote in news:b3fdlo$kp1$1 @digitaldaemon.com:

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

Walter, you are the man!

In article <b3fdlo$kp1$1@digitaldaemon.com>, Walter says...
>
>Some long overdue features.
>
>www.digitalmars.com/d/changelog.html
>

Cool!
Quick question: In the delegates section under types, a function pointer is
shown as:

int function(int) fp;     //function pointer
int func(int);

fp = &func;               //now points to func

whereas, in the functions section under closures, the assignment is shown as:

fp = foo;

Is one of these incorrect? If so, just for the record I like not needing the address-of operator.

Thanks,
-Jon

Excellent all around.  You needn't thank me for berating you.  :-)

Here's a couple problems:

   void delegate () delegate (int x) store;

   void delegate () zoom (int x)
   {
      return delegate void () { };
   }

   void main ()
   {
      store = &zoom;
   }

Which is to say that I'm attempting to assign an incorrect type to "store"; I get:

   Assertion failure: '!ident' on line 1854 in file 'mtype.c'

Also:

   void delegate () delegate (int x) store;

   void delegate () zoom (int x)
   {
      return delegate void () { };
   }

   void main ()
   {
      store = &zoom;
      store () ();
   }

Where I'm not passing an argument to the delegate in main, I get "Error: expected 1 arguments to constructor, not 0"; calling "zoom" directly with the same error results in the proper "function zoom (int x) does not match argument types ()".

Finally:

   void main ()
   {
       { const int [] list = [ 1, 2 ]; }
       { const int [] list = [ 3, 4 ]; }
   }

Each "list" is in its own scope, but it fails with a "Previous Definition Different" error in linking.  While I'm dealing with scopes:

   void main ()
   {
      while (1)
      {
         int x;
      }

      while (1)
      {
         int x;
      }
   }

Fails with "declaration main.x is already defined"; this is long standing.  Finally:

   void main ()
   {
      int x;

      for (int x; ; )
      {
      }
   }

Compiles, even though the "for" loop covers the previous variable; this is also long standing.

"Jonathan Andrew" <Jonathan_member@pathlink.com> wrote in message news:b3g944$14k4$1@digitaldaemon.com...
> Quick question: In the delegates section under types, a function pointer
is
> shown as:
>
> int function(int) fp;     //function pointer
> int func(int);
>
> fp = &func;               //now points to func
>
> whereas, in the functions section under closures, the assignment is shown as:
>
> fp = foo;
>
> Is one of these incorrect? If so, just for the record I like not needing
the
> address-of operator.

In earlier versions, the & was required. In 0.57, either will work. I'm thinking of obsoleting the & version.

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:b3gavs$15ol$1@digitaldaemon.com...
> Excellent all around.  You needn't thank me for berating you.  :-)

Your idea of using the frame pointer as the hidden this pointer was pretty cool.

Kudos and many thanks for the new function/delegate types!

Some notes:

Especially for marketing purposes, you may want to refer to D's closures as "lexical closures", as most closures I've seen implented currently are "semantic closures" -- or "real" closures if you listen to the academics.  This is an old dead battle in the Lisp community.

Essentially, semantic closures are those that are described in the Vault language description (there are a few links in previous posts). Lisp and Scheme also implement them.  They are "full" closures in that when a function is defined it fully captures its enclosing scope, such that even variables on the stack are retained for later reference.

The lexical closures are the more implementationally sane version, which only captures the scope that exists anyway at the moment the function is called later. So in the documentation's example:

int delegate () dg;

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

dg = foo;
}

void bar()
{   test();
int i = dg();	// error, test.a no longer exists
return;
}

In semantic closure, there would be no error. The definition of "foo" would invisibily capture the scope of "test()" in a garbage collected block, so that when it is called later through the dg delegate, "a" exists and is still valid.


Semantic closures can play havoc with memory and performance. The scope retention happens invisibly, and can keep otherwise gc-able memory tied up.  The implementation is also complex.  I believe these are reasons you don't see them in languages like Java and C#.  And they are part of the reason why Lisp memory usage is atrocious (even the mature commercial environments) and its garbage collection is often a joke.

Dan

p.s. I don't want to start a Lisp flame war, so I take it all back if you're
offended!  Also, I use Lisp (again, a commercial version) daily so I'm not
(necessarily) speaking from ignorance....


In article <b3fdlo$kp1$1@digitaldaemon.com>, Walter says...
>
>Some long overdue features.
>
>www.digitalmars.com/d/changelog.html
>
>
>

I knew there was a difference, but I didn't know the right terminology. Now that I know it, I'll update the documentation. Semantic closure, at least in a C-style language, just does not feel intuitive to me. The vault style closures, especially the example they give on what values the captured variables have, to me just seems mighty peculiar. Implementing them is also obviously far more complex and expensive, and doesn't look worthwhile for something that is just confusing anyway.

The lexical closure implementation turns out to be reasonably simple, easy to understand, and efficiently implementable.

Thanks,
-Walter

Walter wrote:
> "Jonathan Andrew" <Jonathan_member@pathlink.com> wrote in message
> news:b3g944$14k4$1@digitaldaemon.com...
> 
>>Quick question: In the delegates section under types, a function pointer
> 
> is
> 
>>shown as:
>>
>>int function(int) fp;     //function pointer
>>int func(int);
>>
>>fp = &func;               //now points to func
>>
>>whereas, in the functions section under closures, the assignment is shown
>>as:
>>
>>fp = foo;
>>
>>Is one of these incorrect? If so, just for the record I like not needing
> 
> the
> 
>>address-of operator.
> 
> 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.