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

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.

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.

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.

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.
>

"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

"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 :)

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

"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

"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