On Monday, 18 November 2013 at 09:25:22 UTC, Walter Bright wrote:
> On 11/17/2013 9:10 PM, deadalnix wrote:
>> On Monday, 18 November 2013 at 05:05:02 UTC, Walter Bright wrote:
>>> On 11/17/2013 7:14 PM, deadalnix wrote:
>>>> As I understand it, Timon choosed that syntax simply to demonstrate the
>>>> limitation of your proposal using a similar syntax. Not to propose a syntax.
>>>
>>> Ok, then I'm not seeing what AST macros do that lazy parameters / template
>>> overloading / mixin templates do not?
>>
>> 2 things. First, they can act on statement or declaration. Simply not with the
>> proposed syntax.
>
> If they can insert a statement or a declaration uplevel, then they are doing what I suggested with the return statement.
>
>> Second they can reflect what is passed as argument and act
>> accordingly, when the lazy expression solution cannot.
>
> Expression templates can.


*Expression* templates.

On Monday, 18 November 2013 at 16:03:54 UTC, IgorStepanov wrote:
>
> How macros implemented in C#?
> I know, that C# have linq which can translate lambda expression to SQL WHERE condition. For example s => s.Number > 2 && s.Number < 20 can be translated to ... WHERE s.Number > 2 AND s.Number < 20
>
> It is interesting function, because it allow to write hard code in preferred language (C#, D) instead of unpreferred (SQL). Also this code hides poorly standardized SQL for the well-standardized language.
>
> And С# still not sinking under tons of macro. May be C# has some limitations for ast macros. May be they allowed only for lambda?
>
> This is a general macro-feature which I had like to see in D.

C# doesn't have macros. Linq to Sql is implemented using expression trees. Essentially, it allows the compiler to generate an expression tree of the lambda expression which your library parses to do some work. It doesn't inject any code, and it's done at runtime. I could be wrong about the exact details, but essentially it comes down to the compiler passing in an expression tree into your method, and then your method parsing it at runtime and doing something with the results; it can't be used to generate new code.

On Monday, 18 November 2013 at 19:21:35 UTC, Kapps wrote:
> On Monday, 18 November 2013 at 16:03:54 UTC, IgorStepanov wrote:
>>
>> How macros implemented in C#?
>> I know, that C# have linq which can translate lambda expression to SQL WHERE condition. For example s => s.Number > 2 && s.Number < 20 can be translated to ... WHERE s.Number > 2 AND s.Number < 20
>>
>> It is interesting function, because it allow to write hard code in preferred language (C#, D) instead of unpreferred (SQL). Also this code hides poorly standardized SQL for the well-standardized language.
>>
>> And С# still not sinking under tons of macro. May be C# has some limitations for ast macros. May be they allowed only for lambda?
>>
>> This is a general macro-feature which I had like to see in D.
>
> C# doesn't have macros. Linq to Sql is implemented using expression trees. Essentially, it allows the compiler to generate an expression tree of the lambda expression which your library parses to do some work. It doesn't inject any code, and it's done at runtime. I could be wrong about the exact details, but essentially it comes down to the compiler passing in an expression tree into your method, and then your method parsing it at runtime and doing something with the results; it can't be used to generate new code.

May be this way is good for D? And CTFE allow to parse this tree
at compile-time.
Something like:

@property Collection where(alias cond, Collection)(Collection c)
{
     enum ast = cond.astof;
     static if(is(Collection : DBResultSet))
     {
        string where_cond = generateCondition!(ast, Collection);
        return c.doWhere(where_cond);
     }
     else
     {
        ...
     }
}

...

auto result = db.myItems.where!(x => x.Count > 10);

On 2013-11-18 16:59, Dicebot wrote:

> Anything that allows it routinely should be banned whenever macros are
> accepted or not. Modifying existing "normal" symbols = no way.

The whole point of macros is to modify symbols. Turning this:

auto p = Person.where(q => q.name == "John");

To an SQL query.

-- 
/Jacob Carlborg

On 2013-11-18 22:08, IgorStepanov wrote:

> May be this way is good for D? And CTFE allow to parse this tree
> at compile-time.
> Something like:
>
> @property Collection where(alias cond, Collection)(Collection c)
> {
>       enum ast = cond.astof;
>       static if(is(Collection : DBResultSet))
>       {
>          string where_cond = generateCondition!(ast, Collection);
>          return c.doWhere(where_cond);
>       }
>       else
>       {
>          ...
>       }
> }
>
> ...
>
> auto result = db.myItems.where!(x => x.Count > 10);

The idea is to have something more general. Linq is just one example of what can be implemented.

-- 
/Jacob Carlborg

On Sunday, 17 November 2013 at 10:41:46 UTC, Jacob Carlborg wrote:
> We already have templates and operator overloading. Perhaps we should remove those, we don't want to take the chance of people abusing them.
>
D templates have been designed with the past experience of C++ templates in mind, so the mistakes have been avoided. With macros, we don't have much experience; Lisp macros can't count as the language is too different.

>> Basically, people want to change the language, but without having to
>> discuss their own extensions in the newsgroups. It's sometimes handy,
>> but you'll end up with crappy features all over the place.
>
> No, people want a general solution that doesn't require the language to be extended each time they come up with a useful feature.

Sorry but I tend to value the feedback of people who have already put some serious effort in expression templates and mixins like Don.

> Case in point - again and again I see utterly wretched use of macros in C++ from the top level of C++ programmers who really ought to know better. Want to see a lovely example? Take a look at the C header files for openssl:
>
> https://github.com/D-Programming-Deimos/openssl/tree/master/C
>
> This is not unusual.
>
> I try to put my money where my mouth is. If you look at older parts of dmd, you'll see macro abuse that I cleverly wrote. The newer bits contain fewer and fewer use of any macros, and I've made an ongoing effort to try and eliminate all of it (yebblies has campaigned to get rid of it, too, even crap I tried to hang on to). This has been done this without compromise on performance and usability and readability of the code - and I hope you'll agree that it looks nice without the usual rat's nest of preprocessor abuse one sees in typical C++ code.

 Now, now Walter, that is C not C++. In C++ we would use Boost Preprocessor:)

 Also C macros are just crappy textural replacement, I would assume an AST macro would be along the lines of lisp, which doesn't have much of anything to do with the shitty macro system in C despite using the word "macro".

 Not that I care so whatevars!

On Monday, 18 November 2013 at 21:38:08 UTC, SomeDude wrote:
>> No, people want a general solution that doesn't require the language to be extended each time they come up with a useful feature.
>
> Sorry but I tend to value the feedback of people who have already put some serious effort in expression templates and mixins like Don.

The very first code I wrote in D used expression templates to do vector/matrices computation. I'm really well aware of they are and what they can do (and what error messages you get when you do something wrong).

On Monday, 18 November 2013 at 21:09:26 UTC, Jacob Carlborg wrote:
> On 2013-11-18 16:59, Dicebot wrote:
>
>> Anything that allows it routinely should be banned whenever macros are
>> accepted or not. Modifying existing "normal" symbols = no way.
>
> The whole point of macros is to modify symbols. Turning this:
>
> auto p = Person.where(q => q.name == "John");
>
> To an SQL query.

You don't need to modify actual input lambda for this to become SQL query. I fully support macros as convenient way for AST reflection and related code generation but not a single step further. Changing semantics of existing valid piece of code is never worth it.

On 11/18/2013 11:09 PM, Dicebot wrote:
> On Monday, 18 November 2013 at 21:09:26 UTC, Jacob Carlborg wrote:
>> On 2013-11-18 16:59, Dicebot wrote:
>>
>>> Anything that allows it routinely should be banned whenever macros are
>>> accepted or not. Modifying existing "normal" symbols = no way.
>>
>> The whole point of macros is to modify symbols. Turning this:
>>
>> auto p = Person.where(q => q.name == "John");
>>
>> To an SQL query.
>
> You don't need to modify actual input lambda for this to become SQL
> query. I fully support macros as convenient way for AST reflection and
> related code generation but not a single step further. Changing
> semantics of existing valid piece of code is never worth it.

So you oppose macro attributes?