• J Anderson (51/51) Aug 02 2004 It would be nice if D's syntax was extendable in some ways. I'm
• J Anderson (21/70) Aug 02 2004 Oh, and I forgot the best parts. You would be able to try out/test/fine...
• Matthew (2/97) Aug 17 2004
• James Widman (16/16) Aug 03 2004 Don't we get this already with 'version'?

J Anderson <REMOVEanderson badmama.com.au> writes:

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 <REMOVEanderson badmama.com.au> writes:

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/

"Matthew" <admin.hat stlsoft.dot.org> writes:

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/

James Widman <james jwidman.com> writes:

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.