ch-ch-changes

[Yigal Chripun]

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.