www.digitalmars.com         C & C++   DMDScript  

D - Externally processed blocks

reply Russ Lewis <russ deming-os.org> writes:
Warning: what I'm posting here is *very* ugly.  I don't think it would
actually work, but maybe we can brainstorm based on it...



Looking at some of the ideas about operator overloading, I came up with
a ponder.  What if we allowed preprocessing of the file by arbitrary
programs - but only in specified blocks.  The compiler would cut out a
certain block of code, pass it as stdin to that program, and the stdout
from it would be replaced into the file that was being compiled.

Ofc, this would not be nearly as portable, but it might allow people to
use some syntax sugar that doesn't fit into the regular language.  As
such, it works kind of like asm blocks...you get a special feature at
the expense of portability.

Example:

const char *infix = "/usr/bin/infix-preprocessor --interestingArg1
--interestingArg2";
void foo()
{
   MyClass a,b,c,d;
 ....
   pp(infix) {
      a = b*c + d;
      d++;
      c /= a;
   };
....
}

The compiler would cut out the 3 lines in the pp() declaration and pass
them to the command specified.  The command would output something like
this:

a.Set( b.Mult(c).Add(d) );
d.Increment();
c.Set( c.Divide(a) );
Sep 05 2001
next sibling parent reply Dan Hursh <a b.c> writes:
	Frankly, I wouldn't want a plain text preprocessor.  Besides, some
folks will do that anyway.  Where I work, they've kludged up
preprocessors for everything excepted for some of the script languages. 
(Even html gets run through m4 first.)  For what you are suggesting
though, it sounds like you would be interested in Mozart and LX.  There
whole idea was to have a language where you could write modules for the
compiler to supplement the behavior of the language.  They let the
plugins mess with the parse tree.  What I could follow of it was really
kinda nifty.  I'd like to see more work done in that area, but I don't
know if the idea is ready for D.  Once the academics get a better feel
for reflective (and not just introspective) programming, it might fit
into a practical language.  It may be more of an 'E' thing.
	I am curious if it would be possible to swing some kind of symbolic
preprocessor.  It might be a nice way to fake/do generic programming and
get a number of the interesting features of the macro preprocessor
without the interesting side affects.  Instead of working at the text
level, it would work at the parse tree/symbol table level.
	Not so as to have unbridled access to the parse tree or symbol table,
but to have the ability to declare a symbolic macro with symbolic
arguments (types, variables, literals, whatever makes a complete
parsable unit) that will generate blocks of code and declarations with
the argument symbols substituted in.  Since we wouldn't want a compiler
to be needed in the runtime, these symbolic macros would need to be
fully evaluated at compiler time.  It wouldn't quite be lisp style
macros (assuming I understand them correctly.)
	Alas, my idea is also too wild for D though.  Plus mine can't be
handled by something as simple and eligant as stdin & stdout.

Dan

Russ Lewis wrote:

 
 Warning: what I'm posting here is *very* ugly.  I don't think it would
 actually work, but maybe we can brainstorm based on it...
 
 Looking at some of the ideas about operator overloading, I came up with
 a ponder.  What if we allowed preprocessing of the file by arbitrary
 programs - but only in specified blocks.  The compiler would cut out a
 certain block of code, pass it as stdin to that program, and the stdout
 from it would be replaced into the file that was being compiled.
 
 Ofc, this would not be nearly as portable, but it might allow people to
 use some syntax sugar that doesn't fit into the regular language.  As
 such, it works kind of like asm blocks...you get a special feature at
 the expense of portability.
 
 Example:
 
 const char *infix = "/usr/bin/infix-preprocessor --interestingArg1
 --interestingArg2";
 void foo()
 {
    MyClass a,b,c,d;
  ....
    pp(infix) {
       a = b*c + d;
       d++;
       c /= a;
    };
 ....
 }
 
 The compiler would cut out the 3 lines in the pp() declaration and pass
 them to the command specified.  The command would output something like
 this:
 
 a.Set( b.Mult(c).Add(d) );
 d.Increment();
 c.Set( c.Divide(a) );
Sep 05 2001
parent reply Roland <rv ronetech.com> writes:
Dan Hursh a écrit :


         Not so as to have unbridled access to the parse tree or symbol table,
 but to have the ability to declare a symbolic macro with symbolic
 arguments (types, variables, literals, whatever makes a complete
 parsable unit) that will generate blocks of code and declarations with
 the argument symbols substituted in.  Since we wouldn't want a compiler
 to be needed in the runtime, these symbolic macros would need to be
 fully evaluated at compiler time.  It wouldn't quite be lisp style
 macros (assuming I understand them correctly.)


MASM macros do just that.
they are incredibly powerfull.
Walter knows them well as he wrote a langage for chip design called ABEL HDL
whose macros are inspired
of MASM one.
I was wondering if it's worth to propose something like that for D to replace
templates and C macros as well.
I'm still thinkin and wondering, not ready yet.
I tried to write a sample of macro MASM style to create vector classes on any
type and any dimension but my netscape
crashed befor i finish.
it's 10pm now, i go.

But it can be used like:

mkVector point,int,2;

to create vector class of int, 2 dimensions or

mkVector dspoint,double,3

to create vector class of double, 3 dimension.

the macro can implement all the methodes, operator overloading, type convertion,
etc.. in one piece of code.

The problems are:

- difficult to implement, i guess,
- compliler just point on the macro when compile error, no on the code.

In fact you really need the listing of developped macros.

Roland
Sep 06 2001
parent "Walter" <walter digitalmars.com> writes:
Yeah, the Abel macro language was far more advanced than the C one (and was
simple to implement, too <g>).

Roland wrote in message <3B97D90B.7E323380 ronetech.com>...

Dan Hursh a écrit :


         Not so as to have unbridled access to the parse tree or symbol




table,

 but to have the ability to declare a symbolic macro with symbolic
 arguments (types, variables, literals, whatever makes a complete
 parsable unit) that will generate blocks of code and declarations with
 the argument symbols substituted in.  Since we wouldn't want a compiler
 to be needed in the runtime, these symbolic macros would need to be
 fully evaluated at compiler time.  It wouldn't quite be lisp style
 macros (assuming I understand them correctly.)


MASM macros do just that.
they are incredibly powerfull.
Walter knows them well as he wrote a langage for chip design called ABEL


HDL

whose macros are inspired
of MASM one.
I was wondering if it's worth to propose something like that for D to


replace

templates and C macros as well.
I'm still thinkin and wondering, not ready yet.
I tried to write a sample of macro MASM style to create vector classes on


any

type and any dimension but my netscape
crashed befor i finish.
it's 10pm now, i go.

But it can be used like:

mkVector point,int,2;

to create vector class of int, 2 dimensions or

mkVector dspoint,double,3

to create vector class of double, 3 dimension.

the macro can implement all the methodes, operator overloading, type


convertion,

etc.. in one piece of code.

The problems are:

- difficult to implement, i guess,
- compliler just point on the macro when compile error, no on the code.

In fact you really need the listing of developped macros.

Roland
Sep 06 2001
prev sibling parent "Walter" <walter digitalmars.com> writes:
One nice fallout of D being exceptionally easy to parse is it becomes easy
to write preprocessors for it that are syntactically aware (as opposed to
just being text aware like the C preprocessor).

Russ Lewis wrote in message <3B969F85.A3C63C9B deming-os.org>...

Warning: what I'm posting here is *very* ugly.  I don't think it would
actually work, but maybe we can brainstorm based on it...



Looking at some of the ideas about operator overloading, I came up with
a ponder.  What if we allowed preprocessing of the file by arbitrary
programs - but only in specified blocks.  The compiler would cut out a
certain block of code, pass it as stdin to that program, and the stdout
from it would be replaced into the file that was being compiled.

Ofc, this would not be nearly as portable, but it might allow people to
use some syntax sugar that doesn't fit into the regular language.  As
such, it works kind of like asm blocks...you get a special feature at
the expense of portability.

Example:

const char *infix = "/usr/bin/infix-preprocessor --interestingArg1
--interestingArg2";
void foo()
{
   MyClass a,b,c,d;
 ....
   pp(infix) {
      a = b*c + d;
      d++;
      c /= a;
   };
....
}

The compiler would cut out the 3 lines in the pp() declaration and pass
them to the command specified.  The command would output something like
this:

a.Set( b.Mult(c).Add(d) );
d.Increment();
c.Set( c.Divide(a) );
Sep 05 2001