View mode: basic / threaded / horizontal-split · Log in · Help
May 18, 2004
mixins vs. macros
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
Re: mixins vs. macros
"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
Re: mixins vs. macros
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 19, 2004
Re: mixins vs. macros
>> 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 19, 2004
Re: mixins vs. macros
"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.
May 19, 2004
Re: mixins vs. macros
>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 19, 2004
Re: mixins vs. macros
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 19, 2004
Re: mixins vs. macros
"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
Re: mixins vs. macros
"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.
May 20, 2004
Re: mixins vs. macros
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/
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home