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) );

You might make the pp block a # block instead, dunno.

	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) );
> 
> You might make the pp block a # block instead, dunno.

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) );
>
>You might make the pp block a # block instead, dunno.
>

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

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
>