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

 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

 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

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

 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

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

 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

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

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

 build Prolog-like resolution engines with minimum support from the

Under such a perspective, it definitely looks sexy! Ric
Aug 01 2003