Jacob Carlborg:

> AST macros are drawing so much attension. For some, it's like the holy grail.

That's a bad approach to technology design. You first need to create a good list of things that you want to do, then you have to try to do them without new features, and then if something important is not possible without the new feature (or it becomes too much ugly, too much long, too much bug-prone, etc), you have to see if the complexity of introducing the new feature is paid back. Macros are a significant feature, so they have a significant cost in code complexity, language dis-uniformity, ecc.

Bye,
bearophile

On Monday, 11 November 2013 at 14:13:31 UTC, Jacob Carlborg wrote:
> On 2013-11-11 14:36, Rikki Cattermole wrote:
>
>> Jacob mentioned originally he wanted to create a compiler error. Or at
>> least thats is how I took it. Hence pragma(error, "text");
>> We can already message out at both compile and runtime its simply does
>> the compiler recognise it as an error part.
>
> "error" would be just a single function that is available in the context parameter. There would be many others. From the DIP:
>
> * The arguments used when the compiler was invoked
>
> * Functions for emitting messages of various verbosity level, like error, warning and info
>
> * Functions for querying various types of settings/options, like which versions are defined, is "debug" or "release" defined and so on
>
> * In general providing as much as possible of what the compiler knows about the compile run
>
> * The context should have an associative array with references to all scoped variables at initiation point.

Is there anything specific for info that I should look at? or does pragma msg do everything for you?

On 2013-11-11 16:24, Rikki Cattermole wrote:

> Is there anything specific for info that I should look at? or does
> pragma msg do everything for you?

Sorry, I don't understand what you're meaning.

-- 
/Jacob Carlborg

On 11/11/2013 01:36 PM, Rikki Cattermole wrote:
>
> Yes outside of macros would be useful. For example code like this would
> become redundant:
> pragma(msg, "Support for x is not implemented on platform y");
> static assert(0);
>
> Becoming:
> pragma(error, "Support for x is not implemented on platform y");

static assert(0, "Support for x is not implemented on platform y");

On 11/11/2013 03:13 PM, Jacob Carlborg wrote:
>
> "error" would be just a single function that is available in the context
> parameter. There would be many others. From the DIP:

"error" should also be able to specify where the error occurred in the input, so that it is displayed at the call site.

On 11/11/2013 01:55 PM, Dicebot wrote:
> On Monday, 11 November 2013 at 01:49:45 UTC, Timothee Cour wrote:
>> People have shunned proposals to have @mixin functions because it
>> wouldn't
>> be obvious at call site that some statement is executed under a mixin
>> (which could access all variables in scope etc).
>>
>> The same will happen here; I think it should be clear at call site that a
>> macro is used.
>> How about:
>>
>> macro!myAssert(1 + 2 == 4);
>> instead of myAssert(1 + 2 == 4);
>
> If macros are supposed to access outer scope, I agree, this is a
> necessary restriction.

I don't agree. (The argument against implicit mixin features was a complete lack of hygiene, not the mere possibility of accessing the caller scope.)

On Monday, 11 November 2013 at 16:28:17 UTC, Timon Gehr wrote:
> I don't agree. (The argument against implicit mixin features was a complete lack of hygiene, not the mere possibility of accessing the caller scope.)

How would you expect it to be hygienic in any way if it has implicit outer scope access? Reasoning is pretty much the same as with mixins.

On 2013-11-11 17:28, Timon Gehr wrote:

> I don't agree. (The argument against implicit mixin features was a
> complete lack of hygiene, not the mere possibility of accessing the
> caller scope.)

The macros system need to provide both hygienic and non-hygienic macros.

-- 
/Jacob Carlborg

On 2013-11-11 17:23, Timon Gehr wrote:

> "error" should also be able to specify where the error occurred in the
> input, so that it is displayed at the call site.

That's a good point.

-- 
/Jacob Carlborg

On Monday, 11 November 2013 at 13:26:37 UTC, Dicebot wrote:
> On Sunday, 10 November 2013 at 21:20:34 UTC, Jacob Carlborg wrote:
>> I've been thinking quite long of how AST macros could look like in D. I've been posting my vision of AST macros here in the newsgroup a couple of times already. I've now been asked to create a DIP out of it, so here it is:
>>
>> http://wiki.dlang.org/DIP50
>
> I don't have time to investigate this in details but I'd like to mention that this is one of few possible new features where ROI is really worth it. It removes lot of burden from core language and allows to replace some very arcane template hacks with cleaner code. I'd say it is a bit too early to go for it (really, we need at least to figure out how to make releases without issues first :)) but it is a good future goal even in context of general feature freezing.

Can you stop reading my mind, please ?