On Mon, Nov 11, 2013 at 2:21 AM, Jacob Carlborg <doob@me.com> wrote:

> On 2013-11-11 11:10, Timothee Cour wrote:
>
>> I would really like to use AST macros for the following use case:
>>
>> myAssert( x < y);
>> //will print, on failure, a message, along with all values appearing
>> inside macro myAssert:
>> x<y failed: x=..., y=...
>>
>> myAssert( fun(x,y)==z1+z2)
>> //likewise, but nesting down to all individual variables appearing
>> inside the macro:
>> x=..., y=..., fun(x,y)=..., z1=..., z2=..., bar(z1+z2)=...
>>
>> This would advantageously replace the plethora of unittest helpers found
>> in other languages, eg: CHECK_EQ, CHECK_LEQ, etc.
>> Invaluable for debugging or informative unittests and logs.
>>
>
> Agree. That's the first example in the DIP. Although a very simplified version.


yes, I think your initial example becomes more interesting with this, as in its current form it can already be done in current D.

This would make error messages self-documenting:

myAssert(!file.exists );
// "!file. exists" failed: dump of AST:
file: string ="foobar.d"
|_file.exists: bool = false
  |_!file. exists: bool = false

In many cases, this would be so much more useful than an out of date / incomplete string error message, esp w a lot of variables involved.

On 2013-11-11 11:28, Rikki Cattermole wrote:

> I can understand wanting to have a high level version of it in context.
> I'm just considering a high reuse language feature that could back it.
> Really it should have been added a while ago given the static assert
> trick is used a bit.
> I do actually like the idea of having the ability to call it on context
> with a bunch of extra information given to it for you. e.g. line number
> of initiation ext.

I think we want to have as much as possible of this collected in the same place. I don't think pragmas are a good fit for this.

-- 
/Jacob Carlborg

On Monday, 11 November 2013 at 10:47:37 UTC, Jacob Carlborg wrote:
> On 2013-11-11 11:28, Rikki Cattermole wrote:
>
>> I can understand wanting to have a high level version of it in context.
>> I'm just considering a high reuse language feature that could back it.
>> Really it should have been added a while ago given the static assert
>> trick is used a bit.
>> I do actually like the idea of having the ability to call it on context
>> with a bunch of extra information given to it for you. e.g. line number
>> of initiation ext.
>
> I think we want to have as much as possible of this collected in the same place. I don't think pragmas are a good fit for this.

Yes I do agree with that. I'm just more worried about what backs it then pleasantries that we can give the developer.
Also if you're not looking towards pragma's to hook into stopping compilation what are your ideas and thoughts around this issue? Because at this point I only know of static assert to do it.

On 2013-11-11 11:39, Timothee Cour wrote:

> yes, I think your initial example becomes more interesting with this, as
> in its current form it can already be done in current D.

The current example prints out the exact expression what was passed to the assert macro. Not the result of evaluating the expression. I don't see how this can currently be done in D

> This would make error messages self-documenting:
>
> myAssert(!file.exists );
> // "!file. exists" failed: dump of AST:
> file: string ="foobar.d"
> |_file.exists: bool = false
>    |_!file. exists: bool = false
>
> In many cases, this would be so much more useful than an out of date /
> incomplete string error message, esp w a lot of variables involved.

I agree.

-- 
/Jacob Carlborg

On Monday, 11 November 2013 at 10:55:23 UTC, Jacob Carlborg wrote:
> The current example prints out the exact expression what was passed to the assert macro. Not the result of evaluating the expression. I don't see how this can currently be done in D

I made a suggestion regarding a macro able to get scoped variables from initiation point with Linq. And why that would be a good thing. This is another use case for it. Perhaps add it as a use case for having that feature on the DIP?

On 2013-11-11 11:51, Rikki Cattermole wrote:

> Yes I do agree with that. I'm just more worried about what backs it then
> pleasantries that we can give the developer.
> Also if you're not looking towards pragma's to hook into stopping
> compilation what are your ideas and thoughts around this issue? Because
> at this point I only know of static assert to do it.

A function call on the context parameter as I've already showed. This would just call "error" which is already implemented in the compiler. Although I don't know how to actually do the connection between the compiler internals the user code. I think this is one of the big challenges with this DIP. For this function I guess it could be done like an intrinsic (is that the correct word?).

-- 
/Jacob Carlborg

On 2013-11-11 11:58, Rikki Cattermole wrote:

> I made a suggestion regarding a macro able to get scoped variables from
> initiation point with Linq. And why that would be a good thing. This is
> another use case for it. Perhaps add it as a use case for having that
> feature on the DIP?

I already have an example with the assert (not among the use cases but at the top). Or were you referring to something else?

-- 
/Jacob Carlborg

On Monday, 11 November 2013 at 10:59:28 UTC, Jacob Carlborg wrote:
> A function call on the context parameter as I've already showed. This would just call "error" which is already implemented in the compiler. Although I don't know how to actually do the connection between the compiler internals the user code. I think this is one of the big challenges with this DIP. For this function I guess it could be done like an intrinsic (is that the correct word?).

Ok pragmas essentially call functions like error in the compiler [0].
What I am thinking error will do is instead of outputting like msg it'll call error[1]. This is exactly what you want.

[0] https://github.com/D-Programming-Language/dmd/blob/master/src/statement.c#L2862
[1] https://github.com/D-Programming-Language/dmd/blob/master/src/statement.c#L2957

On Mon, Nov 11, 2013 at 2:55 AM, Jacob Carlborg <doob@me.com> wrote:

> On 2013-11-11 11:39, Timothee Cour wrote:
>
>  yes, I think your initial example becomes more interesting with this, as
>> in its current form it can already be done in current D.
>>
>
> The current example prints out the exact expression what was passed to the assert macro. Not the result of evaluating the expression. I don't see how this can currently be done in D


I'm using a modified assert that uses the ugly import(file)[line] trick, so
that can be done (but is really ugly and has impact either runtime or
compile time). But we're essentially in agreement.


>
>
>  This would make error messages self-documenting:
>>
>> myAssert(!file.exists );
>> // "!file. exists" failed: dump of AST:
>> file: string ="foobar.d"
>> |_file.exists: bool = false
>>    |_!file. exists: bool = false
>>
>> In many cases, this would be so much more useful than an out of date / incomplete string error message, esp w a lot of variables involved.
>>
>
> I agree.
>
> --
> /Jacob Carlborg
>

On Monday, 11 November 2013 at 11:01:41 UTC, Jacob Carlborg wrote:
> I already have an example with the assert (not among the use cases but at the top). Or were you referring to something else?

I was referring to the use case as to why we should have the ability to get scoped variables from the initiation point.
Example:

void func(int i) {
    bool b;
    macr {}
}

macro foo (Context context, Ast!(string) str)
{
    writeln(context.scopeVariables!int("i"));
    writeln(context.scopeVariables!bool("b"));
    return "";
}