On 2013-11-10 17:37, Martin Nowak wrote:

> Can you pour that into a DIP?

Done: http://forum.dlang.org/thread/l5otb1$1dhi$1@digitalmars.com

-- 
/Jacob Carlborg

On 11/10/13 12:38 PM, Timothee Cour wrote:
> On Sun, Nov 10, 2013 at 12:27 PM, Jacob Carlborg <doob@me.com
> <mailto:doob@me.com>> wrote:
>
>     On 2013-11-10 19:44, deadalnix wrote:
>
>         It is also a given that many feature could have been avoided in the
>         first place given that one.
>
>
>     I agree. It seems at least a couple of features could have been
>     implemented using AST macros instead.
>
>     --
>     /Jacob Carlborg
>
>
> I agree; eg, just to name 2 features that I proposed that could be
> simply implemented via AST macros as Jacob said:
> * [proposal: a new string litteral to embed variables in a string
> <http://forum.dlang.org/post/mailman.94.1383254681.9546.digitalmars-d@puremagic.com>
> http://forum.dlang.org/post/mailman.94.1383254681.9546.digitalmars-d@puremagic.com]
> * [Re: feature request: __ARGS__ for logging (cf __FILE__, __LINE__,
> __FUNC___ http://forum.dlang.org/post/kegmp0$30dn$1@digitalmars.com]
>
> It seems we could even get rid of __FILE__,__LINE__,__MODULE__ with AST
> macros.

This would be a very small advantage. The special variables hardly cause any trouble.

Andrei

On 11/10/13 1:17 PM, Jacob Carlborg wrote:
> On 2013-11-10 21:38, Timothee Cour wrote:
>
>> I agree; eg, just to name 2 features that I proposed that could be
>> simply implemented via AST macros as Jacob said:
>> * [proposal: a new string litteral to embed variables in a string
>> <http://forum.dlang.org/post/mailman.94.1383254681.9546.digitalmars-d@puremagic.com>
>>
>> http://forum.dlang.org/post/mailman.94.1383254681.9546.digitalmars-d@puremagic.com]
>>
>> * [Re: feature request: __ARGS__ for logging (cf __FILE__, __LINE__,
>> __FUNC___ http://forum.dlang.org/post/kegmp0$30dn$1@digitalmars.com]
>>
>> It seems we could even get rid of __FILE__,__LINE__,__MODULE__ with AST
>> macros.
>
> Let see, what else. These could, most likely, have been implemented
> using AST macros:
>
> * scope
> * foreach
> * for
> * inlining delegates. I think the current solution to pass a
> delegate/lambda as an alias parameter is a bit weird
>
> One of my favorites that is not already in the language is implementing
> database queries:
>
> Person.where(e => e.name == "John");
>
> Will be translate to the following SQL:
>
> select * from person where name = 'John'
>
> Another one is the property shortcut, see the example for attribute
> macros: http://wiki.dlang.org/DIP50#Attribute_macros

The way I see this is, these preexisting features (which shan't be thrown away) diminish the motivation for adding another feature.

Andrei

On 11/10/2013 11:43 PM, Andrei Alexandrescu wrote:
>>
>> It seems we could even get rid of __FILE__,__LINE__,__MODULE__ with AST
>> macros.
>
> This would be a very small advantage. The special variables hardly cause
> any trouble.
>
> Andrei

The trouble is that there are too few of them to (efficiently) reflect all the information about the calling context one may be interested in. I don't see the point in adding them one after another in an unprincipled ad-hoc fashion instead of actually thinking up a good API coupled with some more expressive power.

On 11/10/13 3:21 PM, Timon Gehr wrote:
> On 11/10/2013 11:43 PM, Andrei Alexandrescu wrote:
>>>
>>> It seems we could even get rid of __FILE__,__LINE__,__MODULE__ with AST
>>> macros.
>>
>> This would be a very small advantage. The special variables hardly cause
>> any trouble.
>>
>> Andrei
>
> The trouble is that there are too few of them to (efficiently) reflect
> all the information about the calling context one may be interested in.
> I don't see the point in adding them one after another in an
> unprincipled ad-hoc fashion instead of actually thinking up a good API
> coupled with some more expressive power.

But the API would add them in exactly the same rote manner. I really don't see an advantage here. An argument for macros would have to do a lot more than "we don't need __FILE__ etc. anymore".

Andrei

On Sun, Nov 10, 2013 at 3:37 PM, Andrei Alexandrescu < SeeWebsiteForEmail@erdani.org> wrote:

> On 11/10/13 3:21 PM, Timon Gehr wrote:
>
>> On 11/10/2013 11:43 PM, Andrei Alexandrescu wrote:
>>
>>>
>>>> It seems we could even get rid of __FILE__,__LINE__,__MODULE__ with AST macros.
>>>>
>>>
>>> This would be a very small advantage. The special variables hardly cause any trouble.
>>>
>>> Andrei
>>>
>>
>> The trouble is that there are too few of them to (efficiently) reflect all the information about the calling context one may be interested in. I don't see the point in adding them one after another in an unprincipled ad-hoc fashion instead of actually thinking up a good API coupled with some more expressive power.
>>
>
> But the API would add them in exactly the same rote manner. I really don't see an advantage here.


All else being equal, a library solution is always preferable; and it's easily extensible unlike what we have.


> An argument for macros would have to do a lot more than "we don't need __FILE__ etc. anymore".


More use cases have already been provided in this thread and previously. The fact that *one* language feature enables all of those is a very good indication there'll be more use cases. Furthermore, writing AST macros instead of mixins is cleaner in terms of introspection, refactoring tools, etc.



>
>
> Andrei
>
>

On 11/10/13 5:03 PM, Timothee Cour wrote:
> On Sun, Nov 10, 2013 at 3:37 PM, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org <mailto:SeeWebsiteForEmail@erdani.org>>
> wrote:
>
>     On 11/10/13 3:21 PM, Timon Gehr wrote:
>
>         On 11/10/2013 11:43 PM, Andrei Alexandrescu wrote:
>
>
>                 It seems we could even get rid of
>                 __FILE__,__LINE__,__MODULE__ with AST
>                 macros.
>
>
>             This would be a very small advantage. The special variables
>             hardly cause
>             any trouble.
>
>             Andrei
>
>
>         The trouble is that there are too few of them to (efficiently)
>         reflect
>         all the information about the calling context one may be
>         interested in.
>         I don't see the point in adding them one after another in an
>         unprincipled ad-hoc fashion instead of actually thinking up a
>         good API
>         coupled with some more expressive power.
>
>
>     But the API would add them in exactly the same rote manner. I really
>     don't see an advantage here.
>
>
> All else being equal, a library solution is always preferable; and it's
> easily extensible unlike what we have.

What do you have in mind? I find it difficult to grab e.g. the file and the line unless there's some plumbing in the language that allows you to.

>     An argument for macros would have to do a lot more than "we don't
>     need __FILE__ etc. anymore".
>
>
> More use cases have already been provided in this thread and previously.
> The fact that *one* language feature enables all of those is a very good
> indication there'll be more use cases. Furthermore, writing AST macros
> instead of mixins is cleaner in terms of introspection, refactoring
> tools, etc.

I am aware of the advantages. You, too, should be aware of the disadvantages.


Andrei

On 2013-11-10 23:49, Andrei Alexandrescu wrote:

> The way I see this is, these preexisting features (which shan't be
> thrown away) diminish the motivation for adding another feature.

I think the opposite. It shows how powerful macros are and that they will most likely be able to implement other new features that haven't been proposed yet.

Adding a bunch of new features to the language instead of taking a step back and thinking if something else can be added that implement these features and many more shows bad judgement.

-- 
/Jacob Carlborg

On 2013-11-11 00:37, Andrei Alexandrescu wrote:

> But the API would add them in exactly the same rote manner. I really
> don't see an advantage here. An argument for macros would have to do a
> lot more than "we don't need __FILE__ etc. anymore".

They do, and several examples have already been shown. I'll also add more as I come up with them.

-- 
/Jacob Carlborg

On 2013-11-11 02:54, Andrei Alexandrescu wrote:

> What do you have in mind? I find it difficult to grab e.g. the file and
> the line unless there's some plumbing in the language that allows you to.

The language just need to provide a way to introspect the AST. If we're talking about a specific API I can think of something like this:

macro foo (Context context, Ast!(string) str)
{
    auto line = context.caller.line;
    auto file = context.caller.file;
}

foo("asd");

-- 
/Jacob Carlborg