On 2013-11-17 21:52, Walter Bright wrote:

> 1. I don't believe we can decide on language features by analogy. D is
> complex enough that one can use analogy to justify anything.
>
> 2. You cannot do anything behind a function call - the 'return'
> discussed earlier, and async/await for another, i.e. operator
> overloading cannot introduce control flow, cannot introduce variables
> into the current scope, etc.

You can turn this:

BigInt(3) + 7;

Into something that is not 10.

You cannot do anything behind a macro. You cannot introduce new syntax.

-- 
/Jacob Carlborg

On 2013-11-17 22:15, Ellery Newcomer wrote:
> On 11/17/2013 11:41 AM, Simen Kjærås wrote:
>>
>> Source is attached. I hope God forgives me.
>>
>
> I suppose you'd have to do something like
>
> x.Where(OR( NOT(Args.thing = "thing"), Args.sing = "sing"))
>
> for nesting and negation and all that.
>
> I'd wait for walter to relax the restrictions on ==, &&, etc operator
> overloading. Then you probably could do
>
> x.Where(X => X.thing != "thing" || X.sing == "sing")
>
> let's see here. If X's type is QueryExp!Entity and the return type is
> SomeRange!Entity then querying looks doable.
>
> how about composing expressions? take the result of that lambda EXP,
> EXP = EXP && X.cling == 1; // should work fine?
>
> how about decomposing expressions?
> EXP = EXP.lhs; // should work fine?
>
> EXP.rhs.rhs.value // returns "sing" - should work fine? the lambda
> should create a closure, so we should be able to get out any value we
> put in
>
> you won't be able to do
>
> x.Where(X => upper(X.thing) == "THING")

That works with the Rails plugin Squeel. Although you need to prefix "upper" with "X.".

https://github.com/ernie/squeel

-- 
/Jacob Carlborg

On 2013-11-17 21:04, Philippe Sigaud wrote:

> alias staticToString(T...) = T.stringof;
>
> Which is both easier to understand and easier on the eyes.

Wouldn't that be enum instead:

enum staticToString(T...) = T.stringof;

-- 
/Jacob Carlborg

On 11/18/2013 09:22 AM, Jacob Carlborg wrote:
> On 2013-11-17 21:52, Walter Bright wrote:
>
>> 1. I don't believe we can decide on language features by analogy. D is
>> complex enough that one can use analogy to justify anything.
>>
>> 2. You cannot do anything behind a function call - the 'return'
>> discussed earlier, and async/await for another, i.e. operator
>> overloading cannot introduce control flow, cannot introduce variables
>> into the current scope, etc.
>
> You can turn this:
>
> BigInt(3) + 7;
>
> Into something that is not 10.
>
> You cannot do anything behind a macro. You cannot introduce new syntax.
>

Well, you could do:

@screwUp int foo(){ return 3+7; }

assert(foo()!=10);

On 2013-11-18 10:12, Timon Gehr wrote:

> Well, you could do:
>
> @screwUp int foo(){ return 3+7; }
>
> assert(foo()!=10);

Sure, what I'm saying is that you can do stupid things with other features than macros.

-- 
/Jacob Carlborg

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.

On 11/18/2013 12:22 AM, Jacob Carlborg wrote:
> On 2013-11-17 21:52, Walter Bright wrote:
>
>> 1. I don't believe we can decide on language features by analogy. D is
>> complex enough that one can use analogy to justify anything.
>>
>> 2. You cannot do anything behind a function call - the 'return'
>> discussed earlier, and async/await for another, i.e. operator
>> overloading cannot introduce control flow, cannot introduce variables
>> into the current scope, etc.
>
> You can turn this:
>
> BigInt(3) + 7;
>
> Into something that is not 10.

That is not at all what I was talking about. I was talking about:

   3+7

being transformed by AST manipulation into something that is not 10.

> You cannot do anything behind a macro. You cannot introduce new syntax.

On 11/18/2013 1:14 AM, Jacob Carlborg wrote:
> Sure, what I'm saying is that you can do stupid things with other features than
> macros.

Yes, you can write terrible code with all features.

My point is not that you can do stupid things with macros. It is that macros encourage this to a high degree, and in fact the flexibility that macros have over lazy parameters / expression templates / mixin templates are exactly those features that are abused to the point it is hard to see much good come from them. I am not making this up, this is what happens with macro systems again and again. I know this is a difficult position to argue from and convince people about.

D has a deliberate lack of capability in some areas because long experience shows that little good comes from them. Examples include lack of ability to overload && and ||, and lack of expression support for version statements. This is not because these features are hard - they're easy to implement. I've seen attempts to replace version statements with static if in order to get back the ugliness, and the result is ugly and unnecessary and damned hard to figure out what was actually intended and why it didn't work.

I fear that implementing these things with the idea that they'll somehow be used with restraint is a pipe dream and that D will degenerate into an ugly snarl that everyone hates, and then some D-Go will be invented that everyone will cheer because it won't allow such code to be written.

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.

On Monday, 18 November 2013 at 09:12:19 UTC, Timon Gehr wrote:
> Well, you could do:
>
> @screwUp int foo(){ return 3+7; }
>
> assert(foo()!=10);

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

On Monday, 18 November 2013 at 09:55:42 UTC, Walter Bright wrote:
> On 11/18/2013 1:14 AM, Jacob Carlborg wrote:
>> Sure, what I'm saying is that you can do stupid things with other features than
>> macros.
>
> Yes, you can write terrible code with all features.
>
> My point is not that you can do stupid things with macros. It is that macros encourage this to a high degree, and in fact the flexibility that macros have over lazy parameters / expression templates / mixin templates are exactly those features that are abused to the point it is hard to see much good come from them. I am not making this up, this is what happens with macro systems again and again. I know this is a difficult position to argue from and convince people about.
>
> D has a deliberate lack of capability in some areas because long experience shows that little good comes from them. Examples include lack of ability to overload && and ||, and lack of expression support for version statements. This is not because these features are hard - they're easy to implement. I've seen attempts to replace version statements with static if in order to get back the ugliness, and the result is ugly and unnecessary and damned hard to figure out what was actually intended and why it didn't work.
>
> I fear that implementing these things with the idea that they'll somehow be used with restraint is a pipe dream and that D will degenerate into an ugly snarl that everyone hates, and then some D-Go will be invented that everyone will cheer because it won't allow such code to be written.
>
> 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.

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.