ch-ch-changes

Yigal Chripun yigal100 at gmail.com
Wed Jan 28 13:39:26 PST 2009


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.



More information about the Digitalmars-d mailing list