On 11/13/2013 11:37 PM, Jacob Carlborg wrote:
> On 2013-11-14 01:16, Walter Bright wrote:
>
>> Yes. But that's a good thing. I'd be pretty skeptical of the value of an
>> AST macro that took 3+4 and changed it so it did something other than
>> compute 7.
>
> You can still do stupid things like that with operator overloading. Not on
> built-in types, but on user defined types. Every language allows you to do
> stupid things, one way or another.

Sure, but the issue is that expression templates are not for "int+int", but for "T+int". My question is what value would there be in a rewrite of "int+int" to mean something different.

Am 14.11.2013 09:40, schrieb Jacob Carlborg:
> On 2013-11-14 08:54, dennis luehring wrote:
>
>> perfect for the DIP example section - more of these please :)
>
> Done: http://wiki.dlang.org/DIP50#C.2B.2B_Namespaces_.28issue_7961.29
>

it would be also nice to have (always) an (if possible) string mixin and/or expression-template variant of the example around to show the dirtyness, give can't-work information very fast

Am 14.11.2013 09:53, schrieb Walter Bright:
> On 11/13/2013 11:37 PM, Jacob Carlborg wrote:
>> On 2013-11-14 01:16, Walter Bright wrote:
>>
>>> Yes. But that's a good thing. I'd be pretty skeptical of the value of an
>>> AST macro that took 3+4 and changed it so it did something other than
>>> compute 7.
>>
>> You can still do stupid things like that with operator overloading. Not on
>> built-in types, but on user defined types. Every language allows you to do
>> stupid things, one way or another.
>
> Sure, but the issue is that expression templates are not for "int+int", but for
> "T+int". My question is what value would there be in a rewrite of "int+int" to
> mean something different.

"int + int" could be part of an PC<->GPU kombination that generates CUDA- and D-interchange code at compiletime

Am 14.11.2013 10:06, schrieb dennis luehring:
> Am 14.11.2013 09:53, schrieb Walter Bright:
>> On 11/13/2013 11:37 PM, Jacob Carlborg wrote:
>>> On 2013-11-14 01:16, Walter Bright wrote:
>>>
>>>> Yes. But that's a good thing. I'd be pretty skeptical of the value of an
>>>> AST macro that took 3+4 and changed it so it did something other than
>>>> compute 7.
>>>
>>> You can still do stupid things like that with operator overloading. Not on
>>> built-in types, but on user defined types. Every language allows you to do
>>> stupid things, one way or another.
>>
>> Sure, but the issue is that expression templates are not for "int+int", but for
>> "T+int". My question is what value would there be in a rewrite of "int+int" to
>> mean something different.
>
> "int + int" could be part of an PC<->GPU kombination that generates
> CUDA- and D-interchange code at compiletime

or like Don Blade Engine with string mixins

could produce "high performance x87 asm" code for normal D expressions

On 11/13/2013 5:56 PM, deadalnix wrote:
> I think the whole point of macro is to NOT add too much feature to the language.
>
> See for instance the example I gave before to create generator. This can be
> added with extra language support (C# async/await is an example). But with
> macro, the feature can be implemented as a library.
>
> It is NOT achievable with expression templates.
>
> I can say with certainty that the async/await mechanism is heavily used in some
> codebases and with great benefit. It is being added to all languages one after
> another.

I agree that async/await has to eventually be added to D. I'm not convinced it can or should be done with AST macros.


> The idea behind macros is that instead of adding new feature to the language,
> the language should propose a toolkit to build these features as library.

I do understand this. I've not only extensively used macro systems, I've designed two successful ones and implemented other peoples' designs.

I've also seen the sheer awfulness of what happens with these systems over the long term. The fascinating thing about this awfulness is people are well aware of it in everyone's macro libraries but their own.


> I don't think the time has come for macros in D. As discussed before, it seems
> like filling the gap in existing feature is more important than adding new ones.
> This should however be considered very seriously when the gaps has been filled.

On 11/13/2013 11:53 PM, Jacob Carlborg wrote:
> On 2013-11-13 20:19, Walter Bright wrote:
>
>> The reflection ability is not something specific to an AST, it could be
>> added so that any expression node can be reflected. We already do much
>> of that with __traits.
>
> Yes, I been thinking of ways to expand __traits. When there's enough of __traits
> it's not much left during it into real AST macros. Just the part that passes the
> AST instead of the evaluated result of the arguments to a function.
>
> BTW, is it complicated to return a more structured values, like a struct or a
> class, than just plain values like strings?


No, but then you're face with the issue of where those structs are defined.

Am 14.11.2013 10:12, schrieb Walter Bright:
> I've also seen the sheer awfulness of what happens with these systems over the
> long term. The fascinating thing about this awfulness is people are well aware
> of it in everyone's macro libraries but their own.

the same was said about templates AND string mixins before - but currently only the wise guys building good/great templates/mixins which are in use by everyone - no terror from the deep

>> I don't think the time has come for macros in D.

the DIP needs to grow by many examples and scenarios - some sort
of long term dicussion DIP

On 2013-11-14 10:13, Walter Bright wrote:

> No, but then you're face with the issue of where those structs are defined.

In druntime, just like MouldeInfo, TypeInfo and similar classes.

-- 
/Jacob Carlborg

On Thursday, 14 November 2013 at 09:12:38 UTC, Walter Bright wrote:
> I agree that async/await has to eventually be added to D. I'm not convinced it can or should be done with AST macros.

Out of curiousity, how would that be implemented without macros? I could see it being done with macros with a rewrite and using some of the standard library (like std.parallelism), maybe. But with a language feature, you couldn't use the standard library. It seems like some parallelism code would have to leak into the runtime to get it to work as people might expect.

I guess I would have thought the exact opposite from you... that this is precisely something that *should* be done with a library-defined macro.

On Thursday, 14 November 2013 at 10:07:31 UTC, Chris Cain wrote:
> On Thursday, 14 November 2013 at 09:12:38 UTC, Walter Bright wrote:
>> I agree that async/await has to eventually be added to D. I'm not convinced it can or should be done with AST macros.
>
> Out of curiousity, how would that be implemented without macros? I could see it being done with macros with a rewrite and using some of the standard library (like std.parallelism), maybe. But with a language feature, you couldn't use the standard library. It seems like some parallelism code would have to leak into the runtime to get it to work as people might expect.
>
> I guess I would have thought the exact opposite from you... that this is precisely something that *should* be done with a library-defined macro.

async await do not create parallelism.