I also think proposed syntax does not give any advantage, not worth any language change. If there are any optimization issues with std.algorithm those must be fixed instead. Idiomatic D is all about ranges so such use case must be as efficient a possible.

On 14 January 2014 19:22, Dicebot <public@dicebot.lv> wrote:

> I also think proposed syntax does not give any advantage, not worth any language change. If there are any optimization issues with std.algorithm those must be fixed instead. Idiomatic D is all about ranges so such use case must be as efficient a possible.
>

Perhaps __forceinline in the future may create some opportunities to do these things without creating a crap load of superfluous function calls.

On Tuesday, 14 January 2014 at 09:06:23 UTC, Jakob Ovrum wrote:
> Regardless of whether binary ! is "ugly" or not, it's still better than introducing language features left and right to avoid templates, and it's still better than C++'s template instantiation syntax :)

C++'s templates are horrible for other reasons! D's metaprogramming is much more readable (except for template instantiation, of course ;^)

> LDC and GDC are capable of unravelling the (fairly thin) abstraction. All it requires is the ability to inline direct function calls to small functions - the aforementioned compilers always have this capability for templated functions.

But what happens when you chain multiple modifying functions? A high level optimizer can have heuristics to transform a complex expression into some kind of normal form which the lower level have heuristics to deal with.

> DMD is hit and miss, but I think there was a recent improvement to its inliner... luckily this is still the domain of micro-optimization.

Not really! I think you need high level optimization in order to have an efficient generic programming environment.

Like, if you want to encapsulate generators. (e.g. if you ask a factory for a filtered and sorted list, which returns a generator,  then you need more filters, then you send it to another function which is generic and applies sort again etc)

On Tuesday, 14 January 2014 at 09:21:59 UTC, Manu wrote:

> Personally, I generally like the '!' syntax, except when it's in
> conjunction with lambda's where it can kinda ruins the statements a bit.

I know what you mean, but I think it's more due to the extra parentheses than the exclamation mark, in which case UFCS really helps, e.g.

array.map!(...).filter!(...).copy(sink);

When this is not an option (due to passing more than one argument), splitting the expression into multiple lines still helps.

> I'm quite concerned about unoptimised performance too. I know that's
> unusual, but I'm often left wondering what to do about it.
>
> Imagine, iterating over an array, if I use .filter(lambda) or something,
> there's now an additional 2 function calls at least per iteration, as
> opposed to the original zero. If this is idiomatic (I'd like to think it
> should be since it's fairly tidy), then we commit to a serious performance
> problem in unoptimised code. Liberal use of .empty and things too is a
> problem in unoptimised code... :/

I think it is the price we pay for choosing function-based generic programming (that is, it's not a problem for mixin-based generics). Idiomatic C++ has the same compromise (except, of course, the mixin approach is only available as the less powerful text preprocessor).

On Tuesday, 14 January 2014 at 09:28:49 UTC, Manu wrote:
> Perhaps __forceinline in the future may create some opportunities to do
> these things without creating a crap load of superfluous function calls.

I don't think this is the case for __forceinline - it is a problem with generic optimizer logic if such trivial wrappers don't get inlined. Former is specialized power tool, latter benefits every single program out there.

Manu:

> So, the last few days, 2 things have been coming up constantly.
>
> foreach is like, the best thing about D. But I often get caught by 2 little
> details that result in my having to create a bunch more visual noise.

I am against the suggested changes, because they are too much not-orthogonal.

One of the few things that I'd like to change in foreach is support for anonymous loops:  foreach(;0..10)

I'd like an enumerate() in Phobos.

I think the current tuple unpacking in foreach is a very limited and partially broken feature that should be deprecated as soon as possible (and later replaced with something better and more general).

I think the ! for algorithms and ranges add noise, sometimes I forget them, and I'd like to not need them, but I think they are not going away. So what I'd like are more specific and more clean error messages when I forget them.

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).

Bye,
bearophile

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?

-- 
/Jacob Carlborg

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?

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?

On 01/14/2014 09:43 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> objectively ugly


> because "!" implies a boolean expression, but that is
> off-topic.

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.