Andrei Alexandrescu wrote:
[snipped where appropriate]
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.
that's a good point but I don't like string mixin to be used for that.
Actually, string mixins should be deprecated in favor of better tools.
IIRC, ada has expression generics, which in D would be like:
sort!(a.name < b.name)(vec) // instead of the above
the difference is that it's not a string but an expression in the
language itself.
I want to clarify one point here - the problem with this for IDEs
(compared to text editors) is not highlighting, this is merely a
symptom. Unlike a text editor, an IDE understands the code (it works on
the AST level) and therefore the type of the above is a string and is
treated as such - it's not treated as the AST representation of the
expression.
(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.)
you forget that Dee girl doesn't exist.
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
I too prefer this implementation and agree with all the reasons already
given, But I agree with the original poster from an interface POV.
I'd want ideally to have:
vec.sort(a.name < b.name);
instead of the above.
for this to happen we need several things:
1) a.foo(b, c, ...) == foo(a, b, c, ...)
2) instead of template syntax, use regular function syntax
3) to make it compile-time this needs to be an AST macro instead of a
template
4) AST macro's accept expressions of course. string mixins are obsolete.
5) struct interfaces
about aliases in D:
Ruby (and other languages) have a Symbol type. D aliases are similar
(but compile time only). I think D would benefit from having something
similar, this will be a more general way and less a special case in the
language. similar to this is also having Type type.
keep on the good work, and keep pushing Walter to fix those bugs you
mentioned.
