www.digitalmars.com         C & C++   DMDScript  

D - futuristic foreach

reply Helmut Leitner <leitner hls.via.at> writes:
Just an idea that hounts me. 

====

Let's start with delegates. 

Sometimes passing delegates is pretty annoying because you 
have to write wordy things like (from memory, may be wrong):

   myfunction(parx,pary,void delegate (void) { somecode; } );

It would be much nicer this way:

   myfunction(parx,pary, { somecode; } );

assuming void parameter list and return value by default.

====

Now if the compiler now could be convinced that

   myfunction(parx,pary, { somecode; } );

may also be written (without changing in meaning) as

   myfunction(parx,pary) { somecode; }

anybody were free to write e.g. loop control functions:

  object_from_myclass.foreach() {
    ...
  }

  object_from_myclass.for_range(1,100) {
    ...
  }

without needing further compiler support.

====

This might also suggest

   myarray.foreach() {

   }

   myhash.foreach() {

   }

syntax.

Shouldn't iterators look like methods anyway?

-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com
Jul 31 2003
next sibling parent Patrick Down <Patrick_member pathlink.com> writes:
In article <3F293DE3.31BE1A21 hls.via.at>, Helmut Leitner says...

Just an idea that hounts me. 

====

Let's start with delegates. 

Sometimes passing delegates is pretty annoying because you 
have to write wordy things like (from memory, may be wrong):

   myfunction(parx,pary,void delegate (void) { somecode; } );

It would be much nicer this way:

   myfunction(parx,pary, { somecode; } );

assuming void parameter list and return value by default.

====

Now if the compiler now could be convinced that

   myfunction(parx,pary, { somecode; } );

may also be written (without changing in meaning) as

   myfunction(parx,pary) { somecode; }

anybody were free to write e.g. loop control functions:

  object_from_myclass.foreach() {
    ...
  }

  object_from_myclass.for_range(1,100) {
    ...
  }

without needing further compiler support.

====

This might also suggest

   myarray.foreach() {

   }

   myhash.foreach() {

   }

syntax.

Shouldn't iterators look like methods anyway?


This is like the Ruby language where a code block following 
the fuction is an invisible parameter to the function.  
The one comment I would make is that you will proably want 
pass parameters to the delegate. At least the current item
the iterator is on.
Jul 31 2003
prev sibling next sibling parent reply Burton Radons <loth users.sourceforge.net> writes:
Helmut Leitner wrote:


 Sometimes passing delegates is pretty annoying because you 
 have to write wordy things like (from memory, may be wrong):
 
    myfunction(parx,pary,void delegate (void) { somecode; } );


"delegate void () { somecode; }".


 It would be much nicer this way:
 
    myfunction(parx,pary, { somecode; } );
 
 assuming void parameter list and return value by default.
 
 ====
 
 Now if the compiler now could be convinced that
 
    myfunction(parx,pary, { somecode; } );
 
 may also be written (without changing in meaning) as
 
    myfunction(parx,pary) { somecode; }


I've thought about this for a couple languages.  I don't think it would 
work with D because of the very common need for arguments to the 
delegate, and because the delegate is executed in a nested frame, not 
the parent one - its similarity to the control structures is a lie.

I do think the inline function declaration syntax is too heavy.  I think 
it would work better like this:

    myfunction(parx, pary, &(a, b)
    {
        return a + somecode;
    });

That way we've given it the parameter names but didn't have to supply 
the types.
Jul 31 2003
next sibling parent reply Burton Radons <loth users.sourceforge.net> writes:
Burton Radons wrote:

 I've thought about this for a couple languages.  I don't think it would 
 work with D because of the very common need for arguments to the 
 delegate, and because the delegate is executed in a nested frame, not 
 the parent one - its similarity to the control structures is a lie.
 
 I do think the inline function declaration syntax is too heavy.  I think 
 it would work better like this:


I think I use the word "think" a lot.
Jul 31 2003
parent "Matthew Wilson" <matthew stlsoft.org> writes:
Glad to see I've got an always-changing-one's-mind-after-the-post brother!

"Burton Radons" <loth users.sourceforge.net> wrote in message
news:bgbm9j$1del$2 digitaldaemon.com...

 Burton Radons wrote:

 I've thought about this for a couple languages.  I don't think it would
 work with D because of the very common need for arguments to the
 delegate, and because the delegate is executed in a nested frame, not
 the parent one - its similarity to the control structures is a lie.

 I do think the inline function declaration syntax is too heavy.  I think
 it would work better like this:


 I think I use the word "think" a lot.
Jul 31 2003
prev sibling parent reply "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Burton Radons" <loth users.sourceforge.net> ha scritto nel messaggio
news:bgbm8a$1del$1 digitaldaemon.com...

 I do think the inline function declaration syntax is too heavy.  I think
 it would work better like this:

     myfunction(parx, pary, &(a, b)
     {
         return a + somecode;
     });

 That way we've given it the parameter names but didn't have to supply
 the types.


With respect to Helmut's proposed syntax, this one at least does not look
like a nested function in the middle of code :) Nonetheless, IMHO having to
type the type names is not so bad. Suppose, for instance, that you have to
change the type of the second parameter to myfunction's delegate parameter,
say from int to uint: isn't it nice having the compiler automatically point
you to all the places where you better have a look to ensure your delegates
aren't broken by the change?

Ric

P.S: I, too, seem to repeat words a lot... please bear with me, this is not
my native language so I tend to reuse the dozen of words I know :)
Aug 01 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Riccardo De Agostini" <riccardo.de.agostini email.it> wrote in message
news:bgd39t$2r3d$2 digitaldaemon.com...

 P.S: I, too, seem to repeat words a lot... please bear with me, this is


not

 my native language so I tend to reuse the dozen of words I know :)


Basically, I basically had basically a colleague basically who basically
liked basically to basically use basically the word 'basically' basically as
basically filler, basically.

Basically,
-Walter
Aug 12 2003
parent reply "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Walter" <walter digitalmars.com> ha scritto nel messaggio
news:bhcntd$2pr4$1 digitaldaemon.com...

 Basically, I basically had basically a colleague basically who basically
 liked basically to basically use basically the word 'basically' basically


as

 basically filler, basically.

 Basically,
 -Walter


LOL - I'll try to pay more attention in the future. Promise.
And BTW, I'm always trying to improve my English, so feel free to point out
any incorrect English you find in my messages; use e-mail if you don't want
to pollute the NG. I'd be very grateful for that (or _about_ that?!?)

Ric
Aug 25 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Riccardo De Agostini" <riccardo.de.agostini email.it> wrote in message
news:bicsq3

 And BTW, I'm always trying to improve my English, so feel free to point


out

 any incorrect English you find in my messages; use e-mail if you don't


want

 to pollute the NG. I'd be very grateful for that (or _about_ that?!?)


Your english is excellent. I wouldn't worry about it.
Sep 03 2003
parent "Matthew Wilson" <matthew stlsoft.org> writes:
It's better than most Americans. (And don't get me started on the
Australians!)

The Pimpled Popinjay

[Name and address withheld, for justified fear of lynching.]


"Walter" <walter digitalmars.com> wrote in message
news:bj5sas$19bk$1 digitaldaemon.com...

 "Riccardo De Agostini" <riccardo.de.agostini email.it> wrote in message
 news:bicsq3

 And BTW, I'm always trying to improve my English, so feel free to point


 out

 any incorrect English you find in my messages; use e-mail if you don't


 want

 to pollute the NG. I'd be very grateful for that (or _about_ that?!?)


 Your english is excellent. I wouldn't worry about it.
Sep 03 2003
prev sibling parent reply "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Helmut Leitner" <leitner hls.via.at> ha scritto nel messaggio
news:3F293DE3.31BE1A21 hls.via.at...

 Now if the compiler now could be convinced that

    myfunction(parx,pary, { somecode; } );

 may also be written (without changing in meaning) as

    myfunction(parx,pary) { somecode; }

 anybody were free to write e.g. loop control functions:

   object_from_myclass.foreach() {
     ...
   }

   object_from_myclass.for_range(1,100) {
     ...
   }

 without needing further compiler support.


Call me a dummy, but it looks confusing to me. Not so immediate, at least...
Besides, it would only work for delegates returning void. And, apart from
commonly-used iterators and such, one would have to look at myfunction's
declaration to see what the parameter types are expected to be, thus the
code would be less self-documenting.

Ric
Jul 31 2003
parent reply Helmut Leitner <leitner hls.via.at> writes:
Riccardo De Agostini wrote:

 
 "Helmut Leitner" <leitner hls.via.at> ha scritto nel messaggio
 news:3F293DE3.31BE1A21 hls.via.at...

 Now if the compiler now could be convinced that

    myfunction(parx,pary, { somecode; } );

 may also be written (without changing in meaning) as

    myfunction(parx,pary) { somecode; }

 anybody were free to write e.g. loop control functions:

   object_from_myclass.foreach() {
     ...
   }

   object_from_myclass.for_range(1,100) {
     ...
   }

 without needing further compiler support.


 
 Call me a dummy, but it looks confusing to me. Not so immediate, at least...
 Besides, it would only work for delegates returning void. And, apart from
 commonly-used iterators and such, one would have to look at myfunction's
 declaration to see what the parameter types are expected to be, thus the
 code would be less self-documenting.


It may look confusing. But in the end, if all syntax problems could be removed,
it would show that something like an
   if() {} else {}
construction need not be a natively defined part of a language...

...but an inlined function defined in a standard module about
this way (using the new string syntax for keyword extensions):

   inline block if(expression bool b, block btrue, keyword k"else", block
bfalse) {
      _if(b) { 
         btrue;
         return;
      }
      bfalse;
   }

and a normal "for" could be defined 

   inline block for(block binit; expression bool cond; block binc; block bloop)
{
      binit;
      label: _if(cond) {
         bloop; 
         binc;
         goto label;
      }
   }

For the user and the compiler backend this should be the same like a normal
for loop.

C was a revolution in having standard but no intrinsic functions. 

This could be a step towards having standard but no intrinsic control
structures.

Of course this wouldn't make sense in itself, but it could be a powerful tool
for
building all types of new things. E. g. it would be only a small step then to
build Prolog-like resolution engines with minimum support from the compiler.

-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com
Aug 01 2003
parent "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Helmut Leitner" <leitner hls.via.at> ha scritto nel messaggio
news:3F2A395C.66BFB7FC hls.via.at...

 ...but an inlined function defined in a standard module about
 this way (using the new string syntax for keyword extensions):


Oops... I didn't know about this new syntax. Mea culpa!


 C was a revolution in having standard but no intrinsic functions.

 This could be a step towards having standard but no intrinsic control


structures.

 Of course this wouldn't make sense in itself, but it could be a powerful


tool for

 building all types of new things. E. g. it would be only a small step then


to

 build Prolog-like resolution engines with minimum support from the


compiler.

Under such a perspective, it definitely looks sexy!

Ric
Aug 01 2003