ch-ch-changes

[Don]

grauzone wrote:
> Walter Bright wrote:
>> bearophile wrote:
>>> grauzone:
>>>> Why did you choose to do it like this? Because it is shorter, or
>>>> for performance (avoid delegate call)?
>>>
>>> I agree with the general points you have made. Alex has used aliases
>>> for performance.
>>>
>>> My dlibs (for D1) use closures, I like them. Extensive benchmarking
>>> of mine have shown me they are often fast enough. In the spots of the
>>> program where you need max performance I just don't use them, and I
>>> use normal D code. The good thing is that such critical spots are
>>> often 2-5-20% of the lines of the whole program, so for me improving
>>> safety and syntax was a win.
>>
>> It is hard to hit just the right tradeoff between performance and 
>> simplicity. One motivating issue, however, is we don't want to leave 
>> an excuse or desire to go back to C or C++ for performance reasons, 
>> even if those reasons are not reality.
> 
> But they can always roll their own versions of trivial functions like 
> map() and so on. Isn't the point of these standard libraries to provide 
> something simple and generic? Of course, you can't make everyone happy, 
> but why are the performance freaks the one we need to make happy?
> 
> If you need high performance code, you'll probably always write your 
> own, and won't trust the standard library. Just like you rewrite 
> critical parts of code in assembler, and you don't trust the compiler.
> 
>> On the other hand, I really like the string mixin approach, I think it 
>> works simply and elegantly for most predicates.
> 
> Consider you have this code:
> 
>  > map!("a*3")(a)
> 
> Now you see that you forgot something! For some reason, you actually 
> need to return absolute values! Uh-oh, let's fix that:
> 
>  > map!("fabs(a*3)")(a)
> 
> Oops, this doesn't work. fabs() isn't available, because the code is 
> compiled inside the standard library, and not the module, where the code 
> was written. This is confusing and non-intuitive. Even more, you don't 
> have _any_ way to access fabs() in this code (except if std.algorithm 
> imports std.math). You'll have to rewrite this line of code somehow. 
> Maybe turn it into a delegate. But then you lose the performance benefit 
> you had before. What to do now?

map!("((a>0)?a:-a)*3")(a);

It's a good point though. Actually, I think abs(), and possibly max() 
and min(), should be in std.object. They're just as fundamental as 
division. I think that would leave sqrt() as the only function which is 
fast enough that the delegate overhead would be significant.
And DMD should be able to inline simple delegates anyway.


  Looks like this simple issue caused more
> work than you thought! And all this even though the predicate is simple 
> and trivial!
> 
> I don't see how this is simple and elegant. Looks more like a hack. It 
> reminds me a bit of C++, where things first look simple, but actually... 
> they really aren't.
> 
> But I get Don's and Andrei's points. End of discussion, I guess.
> 
> By the way: thinking about this, it always comes to my mind that D 
> really needs AST macros!

Agreed.