I am writing a preprocessor for D that can add new syntaxes to D,
and have implemented noreturn statement that basically throws
an exception
int func(int x)
{
    if(x>0){}
    else if(x<0){}
    noreturn;
    //or noreturn("Some message");
}

and another iterating construct i call each, It is used like this: int[] numbers;

(each numbers)++;

and translated to
for(int index=0;index<numbers.length; index++)
{
    numbers[index]++;
}

You can also specify an index:

(each[int i] numbers) = i*i;
===
for(int i=0;i<numbers.length; i++)
{
    numbers[i]=i*i;
}

Or use it in function calls
writef("\n",(each numbers));

But now my brain has stopped and i can't figure out how
this should work for a multidimensional case?
int[][] a; //initialized somwhere
sum += (each[int x,int y] a);
//or should it be each[int y,int x]

This should translate to what?
for(int y=0;y<a.length; y++)
{
    for(int x=0;x<a[y].length;x++)
    {
        sum+= a[x][y];
    }
}

Is this correct or did i get the indexes wrong? Should x and y be the other way around? Comments?

Ivan Senji wrote:
> I am writing a preprocessor for D that can add new syntaxes to D

Cool, so I'm not the only one, I've done a preprocessor in Python to allow for some aspect oriented programming yet it's very limited ATM and kinda slowish (gonna rewrite in D and add functionality).
I hope these 'modifications' can eventually find their way in D 2.0

> But now my brain has stopped and i can't figure out how
> this should work for a multidimensional case?
> int[][] a; //initialized somwhere
> sum += (each[int x,int y] a);
> //or should it be each[int y,int x]

Are you sure this should be done like this for more than 1 dimension ? I think it would be relatively simple to do sth like

int[][] a;
sum += (each(each a));

or something along these lines :]


Tom

Ivan Senji wrote:
> I am writing a preprocessor for D that can add new syntaxes to D,
> and have implemented noreturn statement that basically throws
> an exception
> int func(int x)
> {
>     if(x>0){}
>     else if(x<0){}
>     noreturn;
>     //or noreturn("Some message");
> }
> 
> and another iterating construct i call each, It is used like this:
> int[] numbers;
> 
> (each numbers)++;
> 
> and translated to
> for(int index=0;index<numbers.length; index++)
> {
>     numbers[index]++;
> }
> 
> You can also specify an index:
> 
> (each[int i] numbers) = i*i;
> ===
> for(int i=0;i<numbers.length; i++)
> {
>     numbers[i]=i*i;
> }
> 
> Or use it in function calls
> writef("\n",(each numbers));
> 
> But now my brain has stopped and i can't figure out how
> this should work for a multidimensional case?
> int[][] a; //initialized somwhere
> sum += (each[int x,int y] a);
> //or should it be each[int y,int x]
> 
> This should translate to what?
> for(int y=0;y<a.length; y++)
> {
>     for(int x=0;x<a[y].length;x++)
>     {
>         sum+= a[x][y];
>     }
> }
> 
> Is this correct or did i get the indexes wrong? Should x and y
> be the other way around? Comments?
> 
Great work!

Work on Aspect Oriented development. This would be a nice addition to D.

Regards,
Sjoerd

Ivan Senji wrote:

[snip]
> You can also specify an index:
> 
> (each[int i] numbers) = i*i;
> ===
> for(int i=0;i<numbers.length; i++)
> {
>     numbers[i]=i*i;
> }

If this is literally what your preprocessor produces, then it should produce this instead:

   foreach (size_t i, inout typeof (*(numbers)) __item; numbers)
   {
       __item = i * i;
   }

Your code requires a bounds check every iteration, and might require evaluating numbers every iteration.

> Or use it in function calls
> writef("\n",(each numbers));
> 
> But now my brain has stopped and i can't figure out how
> this should work for a multidimensional case?
> int[][] a; //initialized somwhere
> sum += (each[int x,int y] a);
> //or should it be each[int y,int x]

I think it would be less confusing if it were "each[int x][int y]" because comma-separated indices have special meaning in operator overloading.

Declarations are read from left to right; expressions are read from right to left.  So:

   char [x] [y] value;

   value [y] [x] = 0;

> This should translate to what?
> for(int y=0;y<a.length; y++)
> {
>     for(int x=0;x<a[y].length;x++)
>     {
>         sum+= a[x][y];
>     }
> }

Similarly this should be:

   foreach (size_t y, inout typeof (*a) __item0; a)
   {
       foreach (size_t x, inout typeof (*__item0) __item1; __item0)
       {
           sum += __item1;
       }
   }

"h3r3tic" <foo@bar.baz> wrote in message news:cjhqqh$1hbe$1@digitaldaemon.com...
> Ivan Senji wrote:
> > I am writing a preprocessor for D that can add new syntaxes to D
>
> Cool, so I'm not the only one, I've done a preprocessor in Python to allow for some aspect oriented programming yet it's very limited ATM and kinda slowish (gonna rewrite in D and add functionality).

Cool! Isn't it great how people all over the world can get simillar ideas!

> I hope these 'modifications' can eventually find their way in D 2.0

I'm not hoping for anything like this, just playing around, although it would be very nice.

>
> > But now my brain has stopped and i can't figure out how
> > this should work for a multidimensional case?
> > int[][] a; //initialized somwhere
> > sum += (each[int x,int y] a);
> > //or should it be each[int y,int x]
>
> Are you sure this should be done like this for more than 1 dimension ? I think it would be relatively simple to do sth like
>
> int[][] a;
> sum += (each(each a));

Well, it looks nice but it would break how things work :(
I only expect one each in a statement, so it will generate
a loop for only th first each and some strange looking code.

> or something along these lines :]
>
>
> Tom

"Burton Radons" <burton-radons@smocky.com> wrote in message news:cjhvlu$1v4f$1@digitaldaemon.com...
> Ivan Senji wrote:
>
> [snip]
> > You can also specify an index:
> >
> > (each[int i] numbers) = i*i;
> > ===
> > for(int i=0;i<numbers.length; i++)
> > {
> >     numbers[i]=i*i;
> > }
>
> If this is literally what your preprocessor produces, then it should produce this instead:

>     foreach (size_t i, inout typeof (*(numbers)) __item; numbers)


:) I had a feeling i should use foreach

but this will have to be (i think)
foreach (indexTypeGivenByUser i, inout typeof (numbers[i]) __item; numbers)

>     {
>         __item = i * i;
>     }
>

So i could even (maybe) iterate asociative arrays this way.

> Your code requires a bounds check every iteration, and might require evaluating numbers every iteration.

100% right and a good point, thanks!

> > Or use it in function calls
> > writef("\n",(each numbers));
> >
> > But now my brain has stopped and i can't figure out how
> > this should work for a multidimensional case?
> > int[][] a; //initialized somwhere
> > sum += (each[int x,int y] a);
> > //or should it be each[int y,int x]
>
> I think it would be less confusing if it were "each[int x][int y]" because comma-separated indices have special meaning in operator overloading.

I know but i think this is what i tried first and got an ambiguous grammar, i'll try it again.

> Declarations are read from left to right; expressions are read from right to left.  So:
>
>     char [x] [y] value;
>
>     value [y] [x] = 0;
>
> > This should translate to what?
> > for(int y=0;y<a.length; y++)
> > {
> >     for(int x=0;x<a[y].length;x++)
> >     {
> >         sum+= a[x][y];
> >     }
> > }
>
> Similarly this should be:
>
>     foreach (size_t y, inout typeof (*a) __item0; a)
>     {
>         foreach (size_t x, inout typeof (*__item0) __item1; __item0)
>         {
>             sum += __item1;
>         }
>     }

Thanks! Again, this doesnt look bad at all. I will only have to replace *a with a[y] and *__item0 with __itemo0[x]!

"Ivan Senji" <ivan.senji@public.srce.hr> wrote in message news:cjitk8$s0$1@digitaldaemon.com...
> "h3r3tic" <foo@bar.baz> wrote in message news:cjhqqh$1hbe$1@digitaldaemon.com...
> > I hope these 'modifications' can eventually find their way in D 2.0
>
> I'm not hoping for anything like this, just playing around, although it would be very nice.

I think your preprocessor idea is a great way for experimenting with new syntactical forms.

"Walter" <newshound@digitalmars.com> wrote in message news:cjk1er$pdu$1@digitaldaemon.com...
>
> "Ivan Senji" <ivan.senji@public.srce.hr> wrote in message news:cjitk8$s0$1@digitaldaemon.com...
> > "h3r3tic" <foo@bar.baz> wrote in message news:cjhqqh$1hbe$1@digitaldaemon.com...
> > > I hope these 'modifications' can eventually find their way in D 2.0
> >
> > I'm not hoping for anything like this, just playing around, although it would be very nice.
>
> I think your preprocessor idea is a great way for experimenting with new syntactical forms.

I thought so too. :) But I am not sure if preprocessor is the right word because it sound like C preprocessor, but it is actually parsing code and creating the syntax tree with which i am playing.

"Ivan Senji" <ivan.senji@public.srce.hr> wrote in message news:cjk4kg$se5$1@digitaldaemon.com...
> "Walter" <newshound@digitalmars.com> wrote in message news:cjk1er$pdu$1@digitaldaemon.com...
> >
> > "Ivan Senji" <ivan.senji@public.srce.hr> wrote in message news:cjitk8$s0$1@digitaldaemon.com...
> > > "h3r3tic" <foo@bar.baz> wrote in message news:cjhqqh$1hbe$1@digitaldaemon.com...
> > > > I hope these 'modifications' can eventually find their way in D 2.0
> > >
> > > I'm not hoping for anything like this, just playing around, although it would be very nice.
> >
> > I think your preprocessor idea is a great way for experimenting with new syntactical forms.
>
> I thought so too. :) But I am not sure if preprocessor is the right word because it sound like C preprocessor, but it is actually parsing code and creating the syntax tree with which i am playing.

Technically, that would be called a 'translator'. RATFOR and Cfront are particularly famous examples of the genre.

"Walter" <newshound@digitalmars.com> wrote in message news:cjmhr2$2ju9$1@digitaldaemon.com...
>
> "Ivan Senji" <ivan.senji@public.srce.hr> wrote in message news:cjk4kg$se5$1@digitaldaemon.com...
> > "Walter" <newshound@digitalmars.com> wrote in message news:cjk1er$pdu$1@digitaldaemon.com...
> > >
> > > "Ivan Senji" <ivan.senji@public.srce.hr> wrote in message news:cjitk8$s0$1@digitaldaemon.com...
> > > > "h3r3tic" <foo@bar.baz> wrote in message news:cjhqqh$1hbe$1@digitaldaemon.com...
> > > > > I hope these 'modifications' can eventually find their way in D
2.0
> > > >
> > > > I'm not hoping for anything like this, just playing around, although it would be very nice.
> > >
> > > I think your preprocessor idea is a great way for experimenting with
new
> > > syntactical forms.
> >
> > I thought so too. :) But I am not sure if preprocessor is the right word because it sound like C preprocessor, but it is actually parsing code
and
> > creating the syntax tree with which i am playing.
>
> Technically, that would be called a 'translator'. RATFOR and Cfront are particularly famous examples of the genre.

Thanks, translator is the word i have been looking for. I have to add that D is a great language to translate to. Thanks for that!

BTW: I am not that great at understanding licenses, and i was wondering if the license would permit translating D's lexer to D and changing it to fit my needs? (The lexer i use is really idiotic)