On 01/14/2014 11:09 AM, Jacob Carlborg wrote:
> On 2014-01-14 09:36, Jakob Ovrum wrote:
>
>> You'll have to get used to the exclamation mark, otherwise you'll never
>> be able to fully appreciate D's generic programming. I quite like it - I
>> don't think there's anything objectively ugly about it.
>
> Or, in this case, fix the compiler to be able to inline delegates. Or is
> there any other advantage of using an alias parameter instead of a
> delegate?
>

1. It is likely to result in faster code when inlining fails. Eg. it will often not allocate when the delegate would, due to nested template instantiation simplifying escape analysis.

2. IFTI limitations. Eg. the following cannot work with the current language unless 'map' is specialized to ranges of int:

[1,2,3].map(x=>2*x)

On 01/14/2014 11:09 AM, Tobias Pankrath wrote:
> On Tuesday, 14 January 2014 at 09:55:42 UTC, bearophile wrote:
>> As D programs use more and more algorithm UFCS chains, D compilers
>> will need to optimize that kind of code better, adding specific
>> high-level and mid-level optimizations (rewrite rules, deforestations,
>> etc).
>
> You came up with deforestation several times now, so I digged up this
> paper from wikipedia
> http://homepages.inf.ed.ac.uk/wadler/papers/deforest/deforest.ps
>
> I skimmed it and it seems that the advantage is elimination of
> intermediate data structures (i.e. lists), which is std.algorithm
> achieves by design. Could you elaborate how deforestation might apply to
> std.algorithm?
>

I guess it would be about eliminating intermediate arrays.

On Tuesday, 14 January 2014 at 13:04:58 UTC, Timon Gehr wrote:
> On 01/14/2014 11:09 AM, Jacob Carlborg wrote:
>> On 2014-01-14 09:36, Jakob Ovrum wrote:
>>
>>> You'll have to get used to the exclamation mark, otherwise you'll never
>>> be able to fully appreciate D's generic programming. I quite like it - I
>>> don't think there's anything objectively ugly about it.
>>
>> Or, in this case, fix the compiler to be able to inline delegates. Or is
>> there any other advantage of using an alias parameter instead of a
>> delegate?
>>
>
> 1. It is likely to result in faster code when inlining fails. Eg. it will often not allocate when the delegate would, due to nested template instantiation simplifying escape analysis.
>
> 2. IFTI limitations. Eg. the following cannot work with the current language unless 'map' is specialized to ranges of int:
>
> [1,2,3].map(x=>2*x)

3. Lazy ranges don't have to carry around delegates.

4. Algorithms can specialize depending on the argument function. However, this is currently only possibly when string lambdas are used... (e.g. std.algorithm.startsWith does this)

5. Alias parameters receiving function templates have the benefit of being able to instantiate the function template argument multiple times with different template arguments. This is murky territory when it comes to function literals with inferred parameter types though - they are not guaranteed to be implemented in terms of function templates.

On Tuesday, 14 January 2014 at 12:55:45 UTC, Timon Gehr wrote:
> This is the binary usage of "!". It does not imply a boolean expression similarly to how a * b does not imply an expression on pointers.

Are you claiming that the C dereference-operator is a good usability design? If so we really have nothing to discuss! :)

On Tuesday, 14 January 2014 at 14:27:02 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 14 January 2014 at 12:55:45 UTC, Timon Gehr wrote:
>> This is the binary usage of "!". It does not imply a boolean expression similarly to how a * b does not imply an expression on pointers.
>
> Are you claiming that the C dereference-operator is a good usability design? If so we really have nothing to discuss! :)

I'm not sure if you're genuinely misunderstanding him or trying as hard as possible to intentionally misrepresent his point.

On Tuesday, 14 January 2014 at 14:38:18 UTC, Meta wrote:
> I'm not sure if you're genuinely misunderstanding him or trying as hard as possible to intentionally misrepresent his point.

I don't think unary/binary is a good enough distinction when the semantics are orthogonal.

On Tuesday, 14 January 2014 at 15:02:19 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 14 January 2014 at 14:38:18 UTC, Meta wrote:
>> I'm not sure if you're genuinely misunderstanding him or trying as hard as possible to intentionally misrepresent his point.
>
> I don't think unary/binary is a good enough distinction when the semantics are orthogonal.

I think it is. It would be far worse if the semantics were related.

On 14 January 2014 20:25, John Colvin <john.loughran.colvin@gmail.com>wrote:

> On Tuesday, 14 January 2014 at 09:07:43 UTC, Manu wrote:
>
>> Can anyone comment on the codegen when using these statements? Is it
>> identical to my reference 'if' statement?
>> Liberal use of loops like this will probably obliterate unoptimised
>> performance... :/
>>
>
> In my experience, unoptimised performance will suffer due to the various function calls and intermediate structs which will be generated naively as-written. Generic range programming in D depends heavily on optimisers to denest everything, which gdc and ldc do manage quite successfully.
>
> Am I correct in thinking that you want (near)playably fast debug builds? I
> think that will require some extra thought to achieve in idiomatic D
> compared to your usual C++ work. pragma(optimise) anyone?
>

Sorry, that was 2 separate points although it didn't look like it.
The first question was assuming full optimisation, is it equivalent to the
if statement I demonstrate with full optimisation in practise? (I'll do
some tests, but people must have already experimented in various
circumstances, and identified patterns?)

The second comment about non-optimised builds; you are correct, it's
important that debug builds remain useful/playable.
I have worked in codebases where debug builds run in the realm of 1-2 fps,
literally unplayable and entirely useless.. This is a MASSIVE productivity
hinderance.
By contrast, at krome, we took great pride in that our debug build ran at
around 10-15fps (actually playable, and quite a unique achievement which
did not go unappreciated), which meant we could actually debug complex bugs
while still being able to reproduce them.
This was almost entirely attributed to our (unpopular) insistence on
writing our engine in C instead of C++.
Sadly, I don't see D being any better than C++ in this case. It's likely
worse than C++, since it's more convenient, and therefore more compelling
to use these meta features.

I'd like to know if anybody can see any path towards inlined
lambda's/literal's/micro-functions in non-optimised builds?
I guess the first question is, is this a problem that is even worth
addressing? How many people are likely to object in principle?

On Tuesday, 14 January 2014 at 15:34:40 UTC, Dominikus Dittes Scherkl wrote:
> I think it is. It would be far worse if the semantics were related.

No. Array sub script and array initialization are both array-like, so no confusion. Same with "+" for concatenation (if you don't do implicit casting) and addition, they are both additive-like. The human mind categorize in a fuzzy fashion.

On Tuesday, 14 January 2014 at 15:37:21 UTC, Manu wrote:
> Sorry, that was 2 separate points although it didn't look like it.
> The first question was assuming full optimisation, is it equivalent to the
> if statement I demonstrate with full optimisation in practise? (I'll do
> some tests, but people must have already experimented in various
> circumstances, and identified patterns?)

Don't think so. LDC is best at doing such transformation per my observations but it still major are for improvements in general.

> I'd like to know if anybody can see any path towards inlined
> lambda's/literal's/micro-functions in non-optimised builds?
> I guess the first question is, is this a problem that is even worth
> addressing? How many people are likely to object in principle?

I'd object against it general. Important trait of such builds is resulting code gen that matches original source code as much as possible. Mass inlining will kill it. But I don't see why you use "debug" and "non-optimised" as synonyms here. For example, in DMD "-release" vs "-debug" are orthogonal to "-O". I see no problems with doing optimised debug build.