www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Extention Idea (for 2.0)

reply 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/
Aug 02 2004
next sibling parent reply 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];

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/
Aug 02 2004
parent "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];

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/

Aug 17 2004
prev sibling parent 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.
Aug 03 2004