• Russ Lewis (3/3) May 18 2004 Walter (and everybody else), I was looking for your opinion on how
• Walter (30/33) May 18 2004 It's an excellent question. Mixins are the same (and different from)
• Regan Heath (6/44) May 18 2004 These should all be on the mixin page, and/or the "The C Preprocessor
• John Q. Curmudgeon (11/13) May 18 2004 So how then do I substitute arbitrary tokens that have no organization?
• Walter (10/23) May 18 2004 You can't in D.
• John Q. Curmudgeon (1/3) May 18 2004 Yes, but said output can't be piped into dmd... yet?
• Walter (3/6) May 19 2004 That's right. You'll need to use a makefile or a build script.
• Norbert Nemec (4/23) May 18 2004 The CPP does not allow that either. What you can do, though, is to
• Walter (11/14) May 19 2004 desired
• J Anderson (6/43) May 19 2004 It seems to me that mixins are just a pre-processor with better rules.
• Kevin Bealer (11/16) May 21 2004 Macros are like a box of chocolates: you never know what you're gonna ge...
• J Anderson (5/26) May 21 2004 True but that is still a comparison with C's pre-processor system not
• Walter (4/6) May 23 2004 any

Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:

Walter (and everybody else), I was looking for your opinion on how 
mixins are different than macros.  Haven't we just recreated the old 
moster in a new guise?

"Walter" <newshound digitalmars.com> writes:

"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:c8do2v$1v33$1 digitaldaemon.com...
 Walter (and everybody else), I was looking for your opinion on how
 mixins are different than macros.  Haven't we just recreated the old
 moster in a new guise?

It's an excellent question. Mixins are the same (and different from)
templates just like C++ templates are the same and different from macros.
Some of the differences are:

1) Mixins substitute in parsed declaration trees that pass muster with the
language syntax, macros substitute in arbitrary preprocessor tokens that
have no organization.

2) Mixins are in the same language. Macros are a *separate* and distinct
language layered on top of C++, with its own expression rules, its own
types, its distinct symbol table, its own scoping rules, etc.

3) Mixins are selected based on partial specialization rules, macros have no
overloading.

4) Mixins create a scope, macros do not.

5) Mixins are compatible with syntax parsing tools, macros are not.

6) Mixin semantic information and symbol tables are passed through to the
debugger, macros are lost in translation.

7) Mixins have override conflict resolution rules, macros just collide.

8) Mixins automatically create unique identifiers as required using a
standard algorithm, macros have to do it manually with kludgy token pasting.

9) Mixin value arguments with side effects are evaluated once, macro value
arguments get evaluated each time they are used in the expansion (leading to
weird bugs).

10) Mixin argument replacements don't need to be 'protected' with
parentheses to avoid operator precedence regrouping.

11) Mixins can be typed as normal D code of arbitrary length, multiline
macros have to be backslash line-spliced, can't use // to end of line
comments, etc.

12) Mixins can define other mixins. Macros cannot create other macros.

I'm sure I'll think of more <g>.

Regan Heath <regan netwin.co.nz> writes:

On Tue, 18 May 2004 14:42:50 -0700, Walter <newshound digitalmars.com> 
wrote:
 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:c8do2v$1v33$1 digitaldaemon.com...
 Walter (and everybody else), I was looking for your opinion on how
 mixins are different than macros.  Haven't we just recreated the old
 moster in a new guise?

 It's an excellent question. Mixins are the same (and different from)
 templates just like C++ templates are the same and different from macros.
 Some of the differences are:

 1) Mixins substitute in parsed declaration trees that pass muster with 
 the
 language syntax, macros substitute in arbitrary preprocessor tokens that
 have no organization.

 2) Mixins are in the same language. Macros are a *separate* and distinct
 language layered on top of C++, with its own expression rules, its own
 types, its distinct symbol table, its own scoping rules, etc.

 3) Mixins are selected based on partial specialization rules, macros 
 have no
 overloading.

 4) Mixins create a scope, macros do not.

 5) Mixins are compatible with syntax parsing tools, macros are not.

 6) Mixin semantic information and symbol tables are passed through to the
 debugger, macros are lost in translation.

 7) Mixins have override conflict resolution rules, macros just collide.

 8) Mixins automatically create unique identifiers as required using a
 standard algorithm, macros have to do it manually with kludgy token 
 pasting.

 9) Mixin value arguments with side effects are evaluated once, macro 
 value
 arguments get evaluated each time they are used in the expansion 
 (leading to
 weird bugs).

 10) Mixin argument replacements don't need to be 'protected' with
 parentheses to avoid operator precedence regrouping.

 11) Mixins can be typed as normal D code of arbitrary length, multiline
 macros have to be backslash line-spliced, can't use // to end of line
 comments, etc.

 12) Mixins can define other mixins. Macros cannot create other macros.

 I'm sure I'll think of more <g>.

These should all be on the mixin page, and/or the "The C Preprocessor 
Versus D" and/or their own "mixins vs macros" page.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

John Q. Curmudgeon <John_member pathlink.com> writes:

 macros substitute in arbitrary preprocessor tokens that
 have no organization.


So how then do I substitute arbitrary tokens that have no organization?

In my never-ending quest for reasons to use a text replacement tool (e.g. the C
preprocesor) as the first step in compilation I thought of these:

1) If you want the compile date and time added to the code

2) If you want the id of the user who requested the build (which may not be the
userid under which the compile executes) added to the code

3) If you want the version and build number or whatever you like added to the
code

Now of course these aren't "macroes", just simple arbitrary items, but there
needs to be a way of simply passing them into a build without saving the values
in a (temporary) file.

"Walter" <newshound digitalmars.com> writes:

"John Q. Curmudgeon" <John_member pathlink.com> wrote in message
news:c8ebgh$2u2j$1 digitaldaemon.com...
 macros substitute in arbitrary preprocessor tokens that
 have no organization.


 So how then do I substitute arbitrary tokens that have no organization?

You can't in D.

 In my never-ending quest for reasons to use a text replacement tool (e.g.

the C
 preprocesor) as the first step in compilation I thought of these:

 1) If you want the compile date and time added to the code

 2) If you want the id of the user who requested the build (which may not

be the
 userid under which the compile executes) added to the code

 3) If you want the version and build number or whatever you like added to

the
 code

 Now of course these aren't "macroes", just simple arbitrary items, but

there
 needs to be a way of simply passing them into a build without saving the

values
 in a (temporary) file.

Actually, the D compiler will accept the output of the C standalone
preprocessor. You can use that if you wish.

John Q. Curmudgeon <John_member pathlink.com> writes:

Actually, the D compiler will accept the output of the C standalone
preprocessor. You can use that if you wish.

Yes, but said output can't be piped into dmd...  yet?

"Walter" <newshound digitalmars.com> writes:

"John Q. Curmudgeon" <John_member pathlink.com> wrote in message
news:c8euc4$pun$1 digitaldaemon.com...
Actually, the D compiler will accept the output of the C standalone
preprocessor. You can use that if you wish.

 Yes, but said output can't be piped into dmd...  yet?

That's right. You'll need to use a makefile or a build script.

Norbert Nemec <Norbert.Nemec gmx.de> writes:

John Q. Curmudgeon wrote:

 macros substitute in arbitrary preprocessor tokens that
 have no organization.


 
 So how then do I substitute arbitrary tokens that have no organization?
 
 In my never-ending quest for reasons to use a text replacement tool (e.g.
 the C preprocesor) as the first step in compilation I thought of these:
 
 1) If you want the compile date and time added to the code
 
 2) If you want the id of the user who requested the build (which may not
 be the userid under which the compile executes) added to the code
 
 3) If you want the version and build number or whatever you like added to
 the code
 
 Now of course these aren't "macroes", just simple arbitrary items, but
 there needs to be a way of simply passing them into a build without saving
 the values in a (temporary) file.

The CPP does not allow that either. What you can do, though, is to
automatically create a .d file that holds string constants with the desired
values. Just like in C, where you would include a version.h or config.h

"Walter" <newshound digitalmars.com> writes:

"Norbert Nemec" <Norbert.Nemec gmx.de> wrote in message
news:c8eutp$pov$2 digitaldaemon.com...
 The CPP does not allow that either. What you can do, though, is to
 automatically create a .d file that holds string constants with the

desired
 values. Just like in C, where you would include a version.h or config.h

Yes. One could write a simple program that accepted a few arguments and
output a .d file along the lines of:

void main(char[][] args)
{
      printf("module config;\n");
      printf("char[] name = \"%.*s\";\n", args[1]);
}

I use such a technique for building the compiler, see \dmd\src\dmd\idgen.c.

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

Walter wrote:

"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:c8do2v$1v33$1 digitaldaemon.com...
  

Walter (and everybody else), I was looking for your opinion on how
mixins are different than macros.  Haven't we just recreated the old
moster in a new guise?
    

It's an excellent question. Mixins are the same (and different from)
templates just like C++ templates are the same and different from macros.
Some of the differences are:

1) Mixins substitute in parsed declaration trees that pass muster with the
language syntax, macros substitute in arbitrary preprocessor tokens that
have no organization.

2) Mixins are in the same language. Macros are a *separate* and distinct
language layered on top of C++, with its own expression rules, its own
types, its distinct symbol table, its own scoping rules, etc.

3) Mixins are selected based on partial specialization rules, macros have no
overloading.

4) Mixins create a scope, macros do not.

5) Mixins are compatible with syntax parsing tools, macros are not.

6) Mixin semantic information and symbol tables are passed through to the
debugger, macros are lost in translation.

7) Mixins have override conflict resolution rules, macros just collide.

8) Mixins automatically create unique identifiers as required using a
standard algorithm, macros have to do it manually with kludgy token pasting.

9) Mixin value arguments with side effects are evaluated once, macro value
arguments get evaluated each time they are used in the expansion (leading to
weird bugs).

10) Mixin argument replacements don't need to be 'protected' with
parentheses to avoid operator precedence regrouping.

11) Mixins can be typed as normal D code of arbitrary length, multiline
macros have to be backslash line-spliced, can't use // to end of line
comments, etc.

12) Mixins can define other mixins. Macros cannot create other macros.

I'm sure I'll think of more <g>.
  

It seems to me that mixins are just a pre-processor with better rules.  
Many languages have better preproccessors then C.  Not that I don't like 
mixins.

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

Kevin Bealer <Kevin_member pathlink.com> writes:

In article <c8hcv1$1qth$1 digitaldaemon.com>, J Anderson says...
..
It seems to me that mixins are just a pre-processor with better rules.  
Many languages have better preproccessors then C.  Not that I don't like 
mixins.

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

Macros are like a box of chocolates: you never know what you're gonna get (when
you use an identifier).  You can't name a variable "SWAP" or "MAX", because it
is probably defined somewhere, badly.  You need a source code search for every
identifier before you really know what the program means.  With mixins, there is
a keyword "mixin", saying "i'm pulling in stuff, and you can find what it is by
this name".

Plus there are rules for who gets to clobber who, which is the hallmark of any
civilized society.

Kevin

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

Kevin Bealer wrote:

In article <c8hcv1$1qth$1 digitaldaemon.com>, J Anderson says...
..
  

It seems to me that mixins are just a pre-processor with better rules.  
Many languages have better preproccessors then C.  Not that I don't like 
mixins.

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

Macros are like a box of chocolates: you never know what you're gonna get (when
you use an identifier).  You can't name a variable "SWAP" or "MAX", because it
is probably defined somewhere, badly.  You need a source code search for every
identifier before you really know what the program means.  With mixins, there is
a keyword "mixin", saying "i'm pulling in stuff, and you can find what it is by
this name".

Plus there are rules for who gets to clobber who, which is the hallmark of any
civilized society.

Kevin
  

True but that is still a comparison with C's pre-processor system not 
other languages pre-processors.  That is what I'm trying to point out.

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

"Walter" <newshound digitalmars.com> writes:

"Kevin Bealer" <Kevin_member pathlink.com> wrote in message
news:c8l83c$9u0$1 digitaldaemon.com...
 Plus there are rules for who gets to clobber who, which is the hallmark of

any
 civilized society.

I like that definition of civilization, I think I'll steal it <g>.