Here's another thing the preprocessor can do that mixins can't do.

This is the kewl way I used to write forever loops:

#define EVER ;;

for(EVER) { /* more kewl code */ }

So much for mixins. ;)

James McComb

"James McComb" <alan@jamesmccomb.id.au> wrote in message news:c8hast$1nt7$1@digitaldaemon.com...
> Here's another thing the preprocessor can do that mixins can't do.
>
> This is the kewl way I used to write forever loops:
>
> #define EVER ;;
>
> for(EVER) { /* more kewl code */ }
>
> So much for mixins. ;)

D is suitably chastised.

James McComb wrote:
> Here's another thing the preprocessor can do that mixins can't do.
> 
> This is the kewl way I used to write forever loops:
> 
> #define EVER ;;
> 
> for(EVER) { /* more kewl code */ }
> 
> So much for mixins. ;)
> 
> James McComb

No, mixins cannot be used to butcher the syntax of the language.  Sorry.

#define sizeof(x) rand()
#define if(x) while(!x)
et cetera

 -- andy

>> #define EVER ;;
>>
>> for(EVER) { /* more kewl code */ }
>>
>> So much for mixins. ;)
>
>D is suitably chastised.

Meaning "not at all" I hope. I see no comparison between mixins and pre-processor symbols. Mixins do what they do far better than the pre-processor would (not that I've tried them yet).

In my opinion the above code is vile misuse of the pre-processor. But maybe the language should have a special "endless loop" construct?

Or does Walter's reply simply mean, "Where C is F***ed, D is chaste"?

"Juan C" <Juan_member@pathlink.com> wrote in message news:c8hjrs$24vc$1@digitaldaemon.com...
> >> #define EVER ;;
> >>
> >> for(EVER) { /* more kewl code */ }
> >>
> >> So much for mixins. ;)
> >
> >D is suitably chastised.
>
> Meaning "not at all" I hope. I see no comparison between mixins and pre-processor symbols. Mixins do what they do far better than the
pre-processor
> would (not that I've tried them yet).

LOL. I was just making a joke. In general, syntax-altering macros should not be used. Despite that, C must support such macros, which is an anchor around its neck.

> In my opinion the above code is vile misuse of the pre-processor.
> But maybe the
> language should have a special "endless loop" construct?

What's wrong with:
    while (1) { ... }
?

Walter wrote:

> 
> "Juan C" <Juan_member@pathlink.com> wrote in message news:c8hjrs$24vc$1@digitaldaemon.com...
>> >> #define EVER ;;
>> >>
>> >> for(EVER) { /* more kewl code */ }
>> >>
>> >> So much for mixins. ;)
>> >
>> >D is suitably chastised.
>>
>> Meaning "not at all" I hope. I see no comparison between mixins and pre-processor symbols. Mixins do what they do far better than the
> pre-processor
>> would (not that I've tried them yet).
> 
> LOL. I was just making a joke. In general, syntax-altering macros should not be used. Despite that, C must support such macros, which is an anchor around its neck.
> 
>> In my opinion the above code is vile misuse of the pre-processor.
>> But maybe the
>> language should have a special "endless loop" construct?
> 
> What's wrong with:
>     while (1) { ... }
> ?

Or, if you want to be more purist:

        while (true) { ... }
?

Bruno A. Costa wrote:

> Walter wrote:
> 
> 
>>"Juan C" <Juan_member@pathlink.com> wrote in message
>>news:c8hjrs$24vc$1@digitaldaemon.com...
>>
>>>>>#define EVER ;;
>>>>>
>>>>>for(EVER) { /* more kewl code */ }
>>>>>
>>>>>So much for mixins. ;)
>>>>
>>>>D is suitably chastised.
>>>
>>>Meaning "not at all" I hope. I see no comparison between mixins and
>>>pre-processor symbols. Mixins do what they do far better than the
>>
>>pre-processor
>>
>>>would (not that I've tried them yet).
>>
>>LOL. I was just making a joke. In general, syntax-altering macros should
>>not be used. Despite that, C must support such macros, which is an anchor
>>around its neck.
>>
>>
>>>In my opinion the above code is vile misuse of the pre-processor.
>>>But maybe the
>>>language should have a special "endless loop" construct?
>>
>>What's wrong with:
>>    while (1) { ... }
>>?
> 
> 
> Or, if you want to be more purist:
> 
>         while (true) { ... }
> ?
> 
>

or the classic loop :-)

void main()
{
    int i = 0;
    STARTLOOP:
        printf("%d\n",++i);
    goto STARTLOOP;
}

roel

Juan C schrieb:

> [...] But maybe the
> language should have a special "endless loop" construct?

Why a special? Sather, a very sympathic language (though by far not as useful as D), only has one looping construct. Exactly, it's an endless loop, called "loop". Then the only other thing you need is to break out of it. For example using an iterator. "i ::= 1.upto!(5);" will loop 5 times assigning increasing values to i from 1 to 5. There are also many other itaertors defined. After it's finished, it breaks out of the loop automatically. You can have multiple interators within 1 loop as well, and well, the one that breaks first wins. :>

-eye

>Why a special? Sather, a very sympathic language (though by far not as useful as D), only has one looping construct. Exactly, it's an endless loop, called "loop". Then the only other thing you need is to break out

Ooh, I like that.

Ilya Minkov wrote:

> Juan C schrieb:
> 
>> [...] But maybe the
>> language should have a special "endless loop" construct?
> 
> Why a special? Sather, a very sympathic language (though by far not as useful as D), only has one looping construct. Exactly, it's an endless loop, called "loop". Then the only other thing you need is to break out of it. For example using an iterator. "i ::= 1.upto!(5);" will loop 5 times assigning increasing values to i from 1 to 5. There are also many other itaertors defined. After it's finished, it breaks out of the loop automatically. You can have multiple interators within 1 loop as well, and well, the one that breaks first wins. :>

Don't underestimate the complexity behind this. Sather loops/iterators are the most powerful loop concept of any language and allow lots of stuff, that simply is not even remotely possible in other languages.

Anyone who has ever used Sather and tried to return to some other language afterward will have experienced the problem of expressing their ideas without Sather iterators. Anyhow: I doubt that there is a chance to make someone, who has never actually used Sather understand the idea and the power of it.

The concept could certainly be added cleanly to D and it would definitely mean an unbelievable boost of the power of the language, but I see little chance to ever convince Walter to even think about it.

B.t.w: "Sather iterators" are something completely different from "C++ iterators". They cannot be simulated in C++ at all. There is some similarity to coroutines in Modula, but unlike some clumsy coroutine implementations in C++, Sather iterators are not based upon expensive frame switches, but work cleanly on one stack. I do not know whether the intermediate languages of the DM/gcc backend are powerful enough to support them, or whether you would have to go down to assembler language.

Conclusion: If Walter is willing to invest some time in looking into the concept of Sather iterators, I promise that he will find the absolute killer feature for D with extremely high addiction potential. Otherwise, I don't think there is much point in discussing the matter on this list.