On 2013-11-11 10:07, Dejan Lekic wrote:

> I like it, Jacob. With or without <[ ]> it is a good proposal, and I see
> several places where I would use it.
>
> +1

Thank you.

-- 
/Jacob Carlborg

On Monday, 11 November 2013 at 09:24:31 UTC, Jacob Carlborg wrote:
> On 2013-11-11 09:31, Rikki Cattermole wrote:
>
>> Theres a few other things I think would need to be cleared up.
>> For example take this code:
>>
>> shader {
>>  program
>>  vertex {
>>   #version 150
>>   void main() {
>>   }
>>  }
>>  fragment {
>>   #version 150
>>   void main() {
>>   }
>>  }
>> }
>>
>> At this point the vertex / fragment segments would be treated as strings
>> instead of calling their macros. So perhaps a rule to identify macros
>> inside macros calls? It would save a lot of time for parsing reasons.
>
> They way I see that is the AST of the whole block would be passed to "shader". I have though a bit about macros inside macros, but I haven't come to a conclusion. The easiest way from a design point of view seems to be that "shader" to basically return the whole AST it receives plus any addition it needs to do. The the "vertex" and "fragment" macros are expanded recursively.
>
>> Also can you alias a macro?
>>
>> alias fragment = tostring;
>>
>> That would make things a lot simpler creating nice structures of them.
>
> I don't see why not.
>
>> Perhaps a condition on a macro like the if's we got for templates would
>> be useful in the sense of being able to say:
>>
>> if (lexer.compareLine(0, "[a-zA-Z]{1}[a-zA-Z_0-9]*") &&
>> lexer.isSymbol(1, SymbolTypes.Macro, vertex))
>
> I don't think I understand how this should be used.
>
>> This would require us to develop a lexer library. But if done right I
>> don't see why it wouldn't be usable for more than just D macro checks.
>> Preferably also for e.g. c/c++ wink wink for when D's front end is in D.

An example of this might be:

macro foo (Context context, Ast!(string) str)
if (lexer.isSymbol(0, SymbolTypes.Class))
{
    return str;
}

class Bar {
 int i;
}

foo {
 Bar(7);
}
The above code would succeed however the below code will give a compiler error stating that the given macro is not found.

struct Haz {
 int i;
}

foo {
 Haz(9);
}

The above code is based on the assumption of a D lexer in phobos.
This is simpler set of code which won't require a lexer.

macro foo (Context context, Ast!(string) str)
if (str == "working")
{
    return "";
}

foo {fails}
foo {working}
In these cases its a simple string test to determine if the text given is specified value.

In the original example I gave, I was using regex to make the point of validation for a given line passed to the macro.

On Monday, 11 November 2013 at 09:01:31 UTC, dennis luehring wrote:
>> One of our targets for AST macros should be the ability to
>> replicate roughly linq from c# / .net.
>>
>> An example syntax for use with AST could be:
>>
>> auto data = [5, 7, 9];
>> int[] data2;
>> query {
>>   from value in data
>>   where value >= 6
>>   add to data2
>> }
>>
>> Could be unwrapped to:
>>
>> auto data = [5, 7, 9];
>> int[] data2;
>> foreach(value; data) {
>>   if (value >= 6) data2 ~= value;
>> }
>
> could you add the example to the DIP wiki page

Adding use case section with Linq example.
Please remove / modify as required as is first time editing wiki.

On 2013-11-11 10:38, Rikki Cattermole wrote:

> An example of this might be:
>
> macro foo (Context context, Ast!(string) str)
> if (lexer.isSymbol(0, SymbolTypes.Class))
> {
>      return str;
> }
>
> class Bar {
>   int i;
> }
>
> foo {
>   Bar(7);
> }
> The above code would succeed however the below code will give a compiler
> error stating that the given macro is not found.
>
> struct Haz {
>   int i;
> }
>
> foo {
>   Haz(9);
> }
>
> The above code is based on the assumption of a D lexer in phobos.
> This is simpler set of code which won't require a lexer.
>
> macro foo (Context context, Ast!(string) str)
> if (str == "working")
> {
>      return "";
> }
>
> foo {fails}
> foo {working}
> In these cases its a simple string test to determine if the text given
> is specified value.
>
> In the original example I gave, I was using regex to make the point of
> validation for a given line passed to the macro.

My idea of handling errors in macros is more something like triggering a real compile error. That could be done via the context parameter, something like:

macro foo (Context context, Ast!(string) str)
{
    if (str.eval() == "bar")
        context.error("Illegal value 'bar'"); // this will trigger the compile error
}

-- 
/Jacob Carlborg

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.





On Mon, Nov 11, 2013 at 1:52 AM, Rikki Cattermole <alphaglosined@gmail.com>wrote:

> On Monday, 11 November 2013 at 09:01:31 UTC, dennis luehring wrote:
>
>> One of our targets for AST macros should be the ability to
>>> replicate roughly linq from c# / .net.
>>>
>>> An example syntax for use with AST could be:
>>>
>>> auto data = [5, 7, 9];
>>> int[] data2;
>>> query {
>>>   from value in data
>>>   where value >= 6
>>>   add to data2
>>> }
>>>
>>> Could be unwrapped to:
>>>
>>> auto data = [5, 7, 9];
>>> int[] data2;
>>> foreach(value; data) {
>>>   if (value >= 6) data2 ~= value;
>>> }
>>>
>>
>> could you add the example to the DIP wiki page
>>
>
> Adding use case section with Linq example.
> Please remove / modify as required as is first time editing wiki.
>

On Monday, 11 November 2013 at 10:04:31 UTC, Jacob Carlborg wrote:
> On 2013-11-11 10:38, Rikki Cattermole wrote:
>
>> An example of this might be:
>>
>> macro foo (Context context, Ast!(string) str)
>> if (lexer.isSymbol(0, SymbolTypes.Class))
>> {
>>     return str;
>> }
>>
>> class Bar {
>>  int i;
>> }
>>
>> foo {
>>  Bar(7);
>> }
>> The above code would succeed however the below code will give a compiler
>> error stating that the given macro is not found.
>>
>> struct Haz {
>>  int i;
>> }
>>
>> foo {
>>  Haz(9);
>> }
>>
>> The above code is based on the assumption of a D lexer in phobos.
>> This is simpler set of code which won't require a lexer.
>>
>> macro foo (Context context, Ast!(string) str)
>> if (str == "working")
>> {
>>     return "";
>> }
>>
>> foo {fails}
>> foo {working}
>> In these cases its a simple string test to determine if the text given
>> is specified value.
>>
>> In the original example I gave, I was using regex to make the point of
>> validation for a given line passed to the macro.
>
> My idea of handling errors in macros is more something like triggering a real compile error. That could be done via the context parameter, something like:
>
> macro foo (Context context, Ast!(string) str)
> {
>     if (str.eval() == "bar")
>         context.error("Illegal value 'bar'"); // this will trigger the compile error
> }

For errors I was thinking a new pragma.
pragma(error, "You did x wrong");
This would fire an error and display the text given. Returning error code as expected. It is after all in the same league as msg.
It would also remove our current static asserts in our code.
So other words it could be replicated by:

pragma(msg, "You did x wrong");
static assert(0);

Just without the whole failed assert message.

Although what I was showing was the idea of overloading of macros like we have in templates.

On Monday, 11 November 2013 at 10:10:33 UTC, 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.
>
>
>
>
>
> On Mon, Nov 11, 2013 at 1:52 AM, Rikki Cattermole
> <alphaglosined@gmail.com>wrote:
>
>> On Monday, 11 November 2013 at 09:01:31 UTC, dennis luehring wrote:
>>
>>> One of our targets for AST macros should be the ability to
>>>> replicate roughly linq from c# / .net.
>>>>
>>>> An example syntax for use with AST could be:
>>>>
>>>> auto data = [5, 7, 9];
>>>> int[] data2;
>>>> query {
>>>>   from value in data
>>>>   where value >= 6
>>>>   add to data2
>>>> }
>>>>
>>>> Could be unwrapped to:
>>>>
>>>> auto data = [5, 7, 9];
>>>> int[] data2;
>>>> foreach(value; data) {
>>>>   if (value >= 6) data2 ~= value;
>>>> }
>>>>
>>>
>>> could you add the example to the DIP wiki page
>>>
>>
>> Adding use case section with Linq example.
>> Please remove / modify as required as is first time editing wiki.

Perhaps an alternative would be:

asserts {
    x < y
    z == z
}

Where the macro would do something like this once converted:

if (!(x < y)) writeln("x < y failed with x=", x, " y= ", y);
if (!(z == z)) writeln("z == z failed with z=", z);

This would also have the benefit of allowing for multiple assert statements for one block.

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

> For errors I was thinking a new pragma.
> pragma(error, "You did x wrong");
> This would fire an error and display the text given. Returning error
> code as expected. It is after all in the same league as msg.
> It would also remove our current static asserts in our code.
> So other words it could be replicated by:
>
> pragma(msg, "You did x wrong");
> static assert(0);
>
> Just without the whole failed assert message.

I like the context parameter better. I'm imagine the context parameter containing a lot of information and functionality to interact with the compiler. A pragma seems not be general enough.

> Although what I was showing was the idea of overloading of macros like
> we have in templates.

Ok, I see.

-- 
/Jacob Carlborg

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.

-- 
/Jacob Carlborg

On Monday, 11 November 2013 at 10:19:49 UTC, Jacob Carlborg wrote:
> On 2013-11-11 11:11, Rikki Cattermole wrote:
>
>> For errors I was thinking a new pragma.
>> pragma(error, "You did x wrong");
>> This would fire an error and display the text given. Returning error
>> code as expected. It is after all in the same league as msg.
>> It would also remove our current static asserts in our code.
>> So other words it could be replicated by:
>>
>> pragma(msg, "You did x wrong");
>> static assert(0);
>>
>> Just without the whole failed assert message.
>
> I like the context parameter better. I'm imagine the context parameter containing a lot of information and functionality to interact with the compiler. A pragma seems not be general enough.

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.