Future of string lambda functions/string predicate functions

[H. S. Teoh]

On Tue, Aug 06, 2013 at 12:05:53PM +0200, Jakob Ovrum wrote:
> On Tuesday, 6 August 2013 at 09:51:07 UTC, bearophile wrote:
> >In this page:
> >http://dlang.org/phobos/std_algorithm.html
> >
> >There is written:
> >bool isSorted(alias less = "a < b", Range)(Range r);
> >
> >If you remove string lambdas, how is that signature?
> 
> bool isSorted(alias less = (a, b) => a < b, Range)(Range r);

In this case, I'll have to be honest and say that the string lambda is
much more readable.


> >My opinion is that lambdas are more clean, and I usually prefer
> >them, but in certain situations I prefer string lambdas.
> 
> I think those few situations should forego string lambdas in favour
> of reduced cognitive load and increased consistency.

I thought about this a bit this morning. Jonathan definitely has a point
about string lambdas being more readable, but OTOH, it does increase
cognitive load, and it suffers from incompleteness (can't reference
symbols not visible from std.functional -- how would anybody know that
if they don't know how Phobos is implemented??). The new syntax is
slightly more cumbersome, and perhaps a little harder to read due to
unfamiliarity.

But in the end, all things considered, I think I'll have to concede that
using lambda syntax is better. Here are my points of consideration
for/against using lambda syntax:

-1:	They are less readable than string lambdas.
-1:	They require the cognitive load of changing coding style for
	current D coders who are already used to string lambdas (though
	this isn't *that* big a minus, considering that string lambdas
	will still be supported in existing code, just no longer
	documented / encouraged).
+1:	They can reference any symbol visible in the local scope,
	instead of depending on implementational details like visibility
	in std.functional (which may change between releases!)
+1:	They explicitly declare their parameters, and are therefore
	easier for a total newbie to understand (the first time I saw a
	string lambda, I went, where on earth do those "a"s and "b"s
	come from?! is that a typo in the docs?!). They also let you use
	more self-documenting argument names, like (start,end) =>
	end-start, instead of the totally opaque "b-a". They also let
	you specify argument types for readability: (Config c, int val)
	=> c.add(val), instead of the mysterious "a.add(b)" in which the
	types of a and b are unclear.
+1:	They are more consistent with other places were lambdas are used
	(consider a newbie going, why doesn't `auto f = "a<b";` give me
	a lambda function, it worked when I pass that to std.algorithm?)
+1:	They avoid having Yet Another Thing newbies have to learn to be
	able to use D effectively. This will help D adoption, at
	basically no cost except a small inconvenience to a small number
	of long-time D veterans. D already is pushing the envelope on
	its sheer number of features; it's a good thing to keep the
	number of *variations* per feature to a minimum.

So in the end, I have to reluctantly conclude that deprecating string
lambdas is probably the best way to go.


T

-- 
EMACS = Extremely Massive And Cumbersome System