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?

"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>.

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/

>> 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.

"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.

>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?

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

"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> 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.

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/