Don Clugston wrote:
> Jari-Matti Mäkelä wrote:

>> I hope that when macros come there will be a possibility to choose between hygienic and unhygienic versions. I've started to think string mixins are a big design mistake. Looking at those compile time unique id hacks from Lisp coder's POV it's amazing to see how badly you can implement something so obvious. I wrote about macros a while ago and noticed that by increasing the power of template mixins and alias parameters it would be possible to achieve the same things and more without sacrificing e.g. syntactical transparency.
> 
> My post was actually to indicate that this lack of hygiene is a genuine nuisance (not merely aesthetically undesirable). I wonder when an unhygienic macro would actually be useful.

Speaking of aesthetics makes it sound like it's only some academic nonsense not applicable in "real world". I've experienced the same problems even with very short metaprograms and created ugly looking ad-hoc workarounds. Most other languages solve the problem using similar techniques so I just wanted to tell there's no need to reimplement the wheel this time. This is a bad example, but hopefully highlights some of the problems with current constructs:

import tango.io.Stdout;

char[] a, i;

char[] foo(char[] a) {
  return "for (int i=0; i<"~a~".length;i++)
  Stdout("~a~"[i]).newline;";
}

mixin GenNewUniqPrefix!(); // defined elsewhere
char[] ad_hoc_foo(char[] a) {
  char[] safe_prefix = getLastUniqPrefix(); // defined elsewhere

  char[] safe_a = safe_prefix ~ "a";
  char[] safe_i = safe_prefix ~ "i";

  return "for (int "~safe_i~"=0; i<"~safe_a ~".length;"~safe_i~"++)
  Stdout("~safe_a~"["~safe_i~"]).newline;";
}

template hygienic_foo(alias a) {
  void hygienic_foo() {
    for(int i=0; i<a.length; i++)
      Stdout(a[i]).newline;
  }
}

/* not implemented yet
macro macro_foo(alias a) {
  for(int i=0; i<a.length; i++)
    Stdout(a[i]).newline;
}
*/

void main() {
  int[3] bar = [1,2,3];
  class i {}
  mixin(foo("bar")); // collision
  hygienic_foo!(bar)();
  macro_foo(bar); // not implemented yet
}

Jari-Matti Mäkelä wrote:
> Don Clugston wrote:
>> Jari-Matti Mäkelä wrote:
> 
>>> I hope that when macros come there will be a possibility to choose
>>> between hygienic and unhygienic versions. I've started to think string
>>> mixins are a big design mistake.
>> My post was actually to indicate that this lack of hygiene is a genuine
>> nuisance (not merely aesthetically undesirable). I wonder when an
>> unhygienic macro would actually be useful.
> 
> Speaking of aesthetics makes it sound like it's only some academic nonsense
> not applicable in "real world".

Yup. I've heard "hygienic" used as if it was purely academic. It's certainly not.

> Most other languages solve the problem using similar techniques so I just
> wanted to tell there's no need to reimplement the wheel this time.

Maybe. I hope macros can do it. It's going to be very hard to match the power of mixins, though. In particular, the case where symbol names are embedded in a string seems to be useful, important, and difficult.

"Pragma" <ericanderton@yahoo.removeme.com> wrote in message news:f85gh5$g8l$1@digitalmars.com...
<snip>
> It kinda makes me wish D had a __UNIQUE__ symbol (reliably unique for a given module/compilation unit?)  for this kind of stuff.
>
> const char[] sym = __UNIQUE__;
> mixin("for (int " ~ sym ~ "=0; " ~ sym ~ "<10; ++" ~ sym ~ ") { func(" ~ sym ~ "); }");

Why create a workaround for this language deficiency rather than fixing it?

http://www.digitalmars.com/d/pretod.html#mixins
"Mixins create a scope, macros do not."
"Mixins automatically create unique identifiers as required using a standard algorithm, macros have to do it manually with kludgy token pasting."

This of course applies to template mixins.  But why not make these points apply to text mixins just the same?

Stewart. 

Stewart Gordon wrote:

> "Pragma" <ericanderton@yahoo.removeme.com> wrote in message
> news:f85gh5$g8l$1@digitalmars.com...
> <snip>
>> It kinda makes me wish D had a __UNIQUE__ symbol (reliably unique for a given module/compilation unit?)  for this kind of stuff.
>>
>> const char[] sym = __UNIQUE__;
>> mixin("for (int " ~ sym ~ "=0; " ~ sym ~ "<10; ++" ~ sym ~ ") { func(" ~
>> sym ~ "); }");
> 
> Why create a workaround for this language deficiency rather than fixing it?
> 
> http://www.digitalmars.com/d/pretod.html#mixins
> "Mixins create a scope, macros do not."
> "Mixins automatically create unique identifiers as required using a
> standard algorithm, macros have to do it manually with kludgy token
> pasting."
> 
> This of course applies to template mixins.  But why not make these points apply to text mixins just the same?

Or extend templates to contain statements so you get three flies with one hit: macros, a fix to this problem & syntax highlighting back. Well, not completely, but the other deficiencies should be obvious by then.