On Wednesday, 24 April 2013 at 17:38:34 UTC, Tove wrote:
> On Wednesday, 24 April 2013 at 02:18:07 UTC, Luís Marques wrote:
>> Consider:
>>
>>    sort!("a > b")(array);
>>
>
> how about?
> sort!(q{a > b})(array);
>
> http://dlang.org/lex.html#TokenString

Token strings solve all the problems the OP mentioned, but they do not solve the one problem he didn't mention - closures:

    int[] array = [3, 1, 5, 2, 7];
    int x = 4;
    writeln(array.filter!(a => a < x)()); // works as expected and prints "[3, 1, 2]"
    writeln(array.filter!q{a < x}()); // Error: undefined identifier x

On Wednesday, 24 April 2013 at 23:04:02 UTC, ixid wrote:
> Is changing the language the right approach to this or would smarter IDEs possibly be a better direction?

A smarter IDE always helps :-)

It might not be worth changing the language for this (or it might), but changing the language to have first-class support of constructs like this would allow tighter checking of the mixed-in code, which seems to me to be mainly the role of the compiler, and not of the IDE. For instance, by using token strings, as suggested by Tove, you can have a tighter grip on the mixed-in string, which should lead to smarter error messages (gramatical check), but not as good as first-class support (semantic checks, etc).

But I don't think this is only about error checking, it's about creating a better abstraction: I think template mixin are a less brittle abstraction than string mixins, but without the argument type modifiers they can't replace the string mixins. But don't take my opinion too seriously, I'm sure you guys know the language better than I do :-)

On Wednesday, 24 April 2013 at 23:42:57 UTC, Idan Arye wrote:
> Token strings solve all the problems the OP mentioned, but they do not solve the one problem he didn't mention - closures:
>
>     int[] array = [3, 1, 5, 2, 7];
>     int x = 4;
>     writeln(array.filter!(a => a < x)()); // works as expected and prints "[3, 1, 2]"
>     writeln(array.filter!q{a < x}()); // Error: undefined identifier x

Yeah, it was unfortunate that the problems I exemplified could be solved by the token strings, without fulling solving the problem, making the issue seem more superficial than it is. Your example is better.

Notice that my code worked for your example, if you changed it to match your scenario:

    // we have to move this outside of main,
    // because the mixin template cannot be there
    int[] array;
    int x = 4;

    mixin template Greater() {
        auto Greater = () => a < x;
    }
    (...)

This seems to work. So, as I said, the infrastructure is there, we are just lacking the convenience of template mixin literals. Without that we have this unwieldy code, which otherwise seems fine.

Are you really saying that 'sort!((a, b) => a > b)(array);' is too verbose??

I consider 'sort!("a > b")(array);' to be **too terse**: there is nothing here telling the reader what a and b are supposed to be.

BR,
renoX

On Friday, 26 April 2013 at 08:13:48 UTC, renoX wrote:
> I consider 'sort!("a > b")(array);' to be **too terse**: there is nothing here telling the reader what a and b are supposed to be.

Sure there is - it's called "convention". Since all the functions in `std.algorithm` that accept delegates also accept string literals for a mixin that use `a` and `b` as the arguments, the reader should know what `a` and `b` means, just like they know what `sort` means.