It would be nice if D's syntax was extendable in some ways.  I'm thinking something like:

Forms:


@[name]
{
     [code]
}


@[name] [instruction];


Note that I use a symbol because I think syntax like this needs to be as short as possible so that the code appears to be part of the language.  Now all D would do is ignore these chunks of code unless it was given the program to run for the given bit of code.  One use example would be for something like dfilter to instruct doxygen to ignore a bit of code: ie

@dox_ignore;


@end_dox_ignore;


Another use would be for adding other languages into D.

@Basic
{
      print "hi"
}

@StateMachine
{
      state X
      {
            transition (X)
            {
                                goto Y;
             }

       }

      state Y
      {

       }
}

D would be passed a list like this:

Basic c:\dmd\filters\dbasic.exe
StateMachine c:\dmd\filters\dstatemachine.exe

Eventually the filters would write a D version of the given code and pass it back, even going as low as ASM if they had to.

Also parhaps something like this could be possible:

ubyte[] mybmp  = @BMP
{
      loadBMP("filename.bmp");
}


I guess all of this could be done without the help of D however having it standardised would be a great help.  It would encourage many useful extensions to be written for D.  It would also be a neat way of removing annoying code redundancies that can't be removed with mixins and other coding styles.

-- 
-Anderson: http://badmama.com.au/~anderson/

J Anderson wrote:

> It would be nice if D's syntax was extendable in some ways.  I'm thinking something like:
>
> Forms:
>
>
> @[name]
> {
>      [code]
> }
>
>
> @[name][instruction];
>
Oh, and I forgot the best parts.  You would be able to try out/test/fine tune/fix new D syntaxes before they are put into the language itself.  Good extensions could make there way into D like good extensions make there way into openGL.   Humm let me see,  the simple test case would be a message assert:

@assert(x == true, "%d", value);

The sc.ini would have this entry in it:

[Plugin]
assert=c:\dmd\filters\dassert.exe

The dassert.exe in c:\dmd\filters\ would be called like:

dassert.exe "(x == true"", %d"", value)"

and it would return

debug {if (assertx == true) {printf("%d", value); assert(x == true);}} //One line on purpose

Which would be placed (invisibly) into the D code replacing the @assert(x == true, "%d", value);


We wouldn't need to wait for Walter to do something, we could try it out ourselves and have code ready before it is even implemented.


>
> Note that I use a symbol because I think syntax like this needs to be as short as possible so that the code appears to be part of the language.  Now all D would do is ignore these chunks of code unless it was given the program to run for the given bit of code.  One use example would be for something like dfilter to instruct doxygen to ignore a bit of code: ie
>
> @dox_ignore;
>
>
> @end_dox_ignore;
>
>
> Another use would be for adding other languages into D.
>
> @Basic
> {
>       print "hi"
> }
>
> @StateMachine
> {
>       state X
>       {
>             transition (X)
>             {
>                                 goto Y;
>              }
>
>        }
>
>       state Y
>       {
>
>        }
> }
>
> D would be passed a list like this:
>
> Basic c:\dmd\filters\dbasic.exe
> StateMachine c:\dmd\filters\dstatemachine.exe
>
> Eventually the filters would write a D version of the given code and pass it back, even going as low as ASM if they had to.
>
> Also parhaps something like this could be possible:
>
> ubyte[] mybmp  = @BMP
> {
>       loadBMP("filename.bmp");
> }
>
>
> I guess all of this could be done without the help of D however having it standardised would be a great help.  It would encourage many useful extensions to be written for D.  It would also be a neat way of removing annoying code redundancies that can't be removed with mixins and other coding styles.
>


-- 
-Anderson: http://badmama.com.au/~anderson/

Don't we get this already with 'version'?

version ( StateMachine )
{
       state X
       {
       transition (X){ goto Y; }
       }
       state Y {}
}
else
{
// hand-coded state machine...
}

...and if we don't, shouldn't we?  One would think that if the compiler doesn't support 'StateMachine', then it would just skip to the matching right-brace.

I think I could like that.


"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message news:cele5q$1i4$1@digitaldaemon.com...
> J Anderson wrote:
>
> > It would be nice if D's syntax was extendable in some ways.  I'm thinking something like:
> >
> > Forms:
> >
> >
> > @[name]
> > {
> >      [code]
> > }
> >
> >
> > @[name][instruction];
> >
> Oh, and I forgot the best parts.  You would be able to try out/test/fine tune/fix new D syntaxes before they are put into the language itself. Good extensions could make there way into D like good extensions make there way into openGL.   Humm let me see,  the simple test case would be a message assert:
>
> @assert(x == true, "%d", value);
>
> The sc.ini would have this entry in it:
>
> [Plugin]
> assert=c:\dmd\filters\dassert.exe
>
> The dassert.exe in c:\dmd\filters\ would be called like:
>
> dassert.exe "(x == true"", %d"", value)"
>
> and it would return
>
> debug {if (assertx == true) {printf("%d", value); assert(x == true);}}
> //One line on purpose
>
> Which would be placed (invisibly) into the D code replacing the
> @assert(x == true, "%d", value);
>
>
> We wouldn't need to wait for Walter to do something, we could try it out ourselves and have code ready before it is even implemented.
>
>
> >
> > Note that I use a symbol because I think syntax like this needs to be as short as possible so that the code appears to be part of the language.  Now all D would do is ignore these chunks of code unless it was given the program to run for the given bit of code.  One use example would be for something like dfilter to instruct doxygen to ignore a bit of code: ie
> >
> > @dox_ignore;
> >
> >
> > @end_dox_ignore;
> >
> >
> > Another use would be for adding other languages into D.
> >
> > @Basic
> > {
> >       print "hi"
> > }
> >
> > @StateMachine
> > {
> >       state X
> >       {
> >             transition (X)
> >             {
> >                                 goto Y;
> >              }
> >
> >        }
> >
> >       state Y
> >       {
> >
> >        }
> > }
> >
> > D would be passed a list like this:
> >
> > Basic c:\dmd\filters\dbasic.exe
> > StateMachine c:\dmd\filters\dstatemachine.exe
> >
> > Eventually the filters would write a D version of the given code and pass it back, even going as low as ASM if they had to.
> >
> > Also parhaps something like this could be possible:
> >
> > ubyte[] mybmp  = @BMP
> > {
> >       loadBMP("filename.bmp");
> > }
> >
> >
> > I guess all of this could be done without the help of D however having it standardised would be a great help.  It would encourage many useful extensions to be written for D.  It would also be a neat way of removing annoying code redundancies that can't be removed with mixins and other coding styles.
> >
>
>
> -- 
> -Anderson: http://badmama.com.au/~anderson/