grauzone wrote:
One thing about std.algorithm: you really seem to like using
compile-time strings as literals. However, this makes the use of
delegates harder. For example, to use a delegate, you need to do this
(quoted from your docs):
> int[] a = ...;
> static bool greater(int a, int b)
> {
> return a > b;
> }
> sort!(greater)(a); // predicate as alias
In my opinion, doing something like
> sort(a, (int a, int b) { return a > b; });
would be simpler and more intuitive than passing a delegate name as
template parameter. (The delegate literal syntax still could be
improved, though.)
Don and Max addressed many of these points, so allow me just to add a
couple of comments.
The use above is valid but at the time I first implemented std.algorithm
and wrote the documentation, bugs in the compiler prevented your syntax
from happening. Certain bugs still disallow your syntax for certain
cases; I submitted those bugs as well.
Does std.algorithm work with closures at all? I see that the greater()
function in your example is marked as static. (Sorry, I didn't test it
myself.)
Yes, it does.
Using string mixins messes up syntax highlighting and the code is more
obfuscated. If you make an error in your predicate, random funny things
internal to the library implementation could happen, and the compiler
will spurt out indecipherable error messages for random modules (I guess
in this case, std.algorithm or std.functional). How will runtime
debugging work? Will the debugger be smart enough to point me to the
correct source code location, if there happens a segfault in my
predicate? I'm sure it could, if you used delegates instead.
String mixins are meant to be used for short functions, which at least
in my code there are plenty of. You can e.g. sort by a field by writing
sort!("a.name < b.name")(vec) without so much as thinking about it. If
you want syntax highlighting, sort!(q{a.name < b.name})(vec) may do (it
does in my editor). But then again: almost by definition, if you feel
like needing syntax highlighting in a string mixin, that string has
outgrown its charter. Use a delegate.
Why did you make this so complex? What's your position on this? Do you
agree that there are problems, or are you happy with how it is?
>
Why did you choose to do it like this? Because it is shorter, or for
performance (avoid delegate call)? Does it enable some weird use cases,
which wouldn't be possible when using delegates?
(If "this" is std.algorithm, I have no idea how to make it simpler.) The
thing is, passing by alias allows you a host of options:
* string for short functions
* function name
* delegate literal
* delegate object (there's a bug in the compiler related to that, that
Walter knows how to fix)
* some struct object that implements opCall()
Really, you have *all* options and *no* disadvantage. It would have been
silly to not put that straight in the standard library. I've looked at
the way other languages do higher-order functions and inevitably they
leave something on the table. Either you don't have enough flexibility,
or the speed kills you, or the syntax kills you. Solutions that are
genuinely superior are few and far apart. Going with aliases really puts
D ahead of all other languages.
The way D instantiates templates locally is a killer and a funny tidbit
of information is that Walter put that great idea in almost by mistake,
not really knowing what the consequences might be. At some point I
figured how awesome that is and really pushed it through. I recall there
was a discussion here - Dee Girl figured that out, too, there was a long
thread about it. (Where's Dee? Where's Janice? We seem to treat our
women badly.)
Regarding performance: I don't think performance justifies all these
problems. Standard library functions should be as fast as possible, but
this goal should come second after robustness and simplicity.
I hope I can change your mind that the problem does not exist.
Another problem is, that using string mixins seems to be quite
problematic, because they are mixed in in a different scope. If I'm not
mistaken, you can't do this:
> int foo(...) {...}
> sort!("foo(a, b);");
You might think that "sort!("a>b", a);" is elegant and short, but this
probably only works out in toy-examples.
You can call sort!(foo)(...). I completely disagree about the toy
examples assessment. In my daily work I use probably 70-80% of
std.algorithm. A large percentage of time I use string mixins no problem
to solve rather real problems.
And macros, which are supposed to magically cure all those problems,
were postponed to D3.0.
I'm also worried about compile times. You use nested templates with
string mixins, which only can be slower to compile than using e.g. the
builtin .sort. I don't know if this a problem, but in my opinion,
compile times are already high enough. Times will add up!
For one, I'm sure that this will generate an additional gazillion of
nearly useless linker symbols with very long names.
I haven't perceived that as a problem yet, but indeed it's a good thing
to keep one's eye on. Probably the solution I'd suggest would be
improved compiler technology (a trend that Walter has relentlessly
demonstrated for a good while now).
Andrei
