www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - mixins vs. macros

reply 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?
May 18 2004
parent reply "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>.
May 18 2004
next sibling parent reply 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/
May 18 2004
parent reply 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.
May 18 2004
next sibling parent reply "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.



You can't in D.
 In my never-ending quest for reasons to use a text replacement tool (e.g.

 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

 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

 code

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

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

 in a (temporary) file.

Actually, the D compiler will accept the output of the C standalone preprocessor. You can use that if you wish.
May 18 2004
parent reply 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?
May 18 2004
parent "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.
May 19 2004
prev sibling parent reply 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
May 18 2004
parent "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

 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.
May 19 2004
prev sibling parent reply 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>.

Many languages have better preproccessors then C. Not that I don't like mixins. -- -Anderson: http://badmama.com.au/~anderson/
May 19 2004
parent reply 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
May 21 2004
next sibling parent 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

other languages pre-processors. That is what I'm trying to point out. -- -Anderson: http://badmama.com.au/~anderson/
May 21 2004
prev sibling parent "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

 civilized society.

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