In Phobos pull request #1453 (Implement chunkBy.)[1], the topic of string lambda functions has again cropped up. I think we should clearly decide on some things regarding them. Questions such as; are they a worthwhile alternative in the present language? Should they be deprecated? Should they be supported in new additions to Phobos?

Some background: string lambda functions are a feature of std.functional/std.range/std.algorithm, where strings can be passed in lieu of functions as template alias arguments to various public functions in these modules. The string becomes the return expression of an anonymous function which implicitly has one or two arguments, named "a" and "b", like the string "a < 3" in the following example expression:

  arr.filter!"a < 3"

When this feature was developed, there were no lambda function literals in the language. There were anonymous functions, but their syntactical overhead means they fare poorly as a replacement for lambda functions:

  arr.filter!((a) { return a < 3; })

The effect is particularly jarring in bigger compositions:

  assert([ 1, 2, 3, 4, 5 ].filter!((a) { return a < 3; }).equal([1, 2]));

Since then, a first-class lambda syntax has been introduced, with significantly less syntactic overhead:

  arr.filter!(a => a < 3)

The issue is then: is the old string lambda syntax obsolete in the face of the new lambda literals?

----------

My opinion on the matter is that the *only* advantage of string lambdas is that they are (even) shorter than the new lambda syntax. However, I don't think that comes even close to making up for its many disadvantages; here are the ones I think are the biggest:

 * The number one reason string lambdas are shorter is because they implicitly introduce their parameters. However, this means that you're always stuck with the generic, uninformative parameter names "a" and "b".
 * To the uninitiated, they may not look like code. They certainly aren't highlighted as D code in your average code editor (the q{} literal deserves a mention, but then some of the succinctness advantage is lost and it's not just for D code), and the magically, implicitly introduced variables "a" and "b" is something you plain just have to know beforehand to understand.
 * Apart from "a" and "b", they can only access symbols that are visible in the scope of the std.functional module.

In light of the above points, I just find them excessively arcane - something new D programmers shouldn't have to learn and thus none of us should continue to use or promote. The symbols you can access in a string lambda are determined by the implementation details of std.functional and thus, may change at any time. It is then only reasonable to recommend that the programmer should not depend on any symbols except for "a" and "b", severely limiting the utility of string lambdas. Also, they only exist in unary and binary forms at present, which means new functions with different requirements cannot leverage them. And then comes the point about consistency; if the utility of string lambdas is so limited in the face of the general lambda literal syntax, foregoing string lambdas in favour of lambda literals helps code consistency.

I can also think of some relatively minor disadvantages of string lambdas, such as the compile-time performance cost they incur.

I think string lambdas were a valiant effort to fill a glaring hole in the language at the time, but are now superseded by an overall superior alternative. The cognitive and maintenance load on programmers is not worth their marginal utility. I think we should deprecate string lambdas altogether.

Specifically, I suggest the following deprecation path:

 * Add deprecation notes to std.functional's unaryFun and binaryFun so users are dissuaded from using them in new code. In time, we would remove their documentation.
 * Leave support for string lambdas in existing Phobos functions for the foreseeable future, for backwards-compatibility purposes.
 * Change all documentation so that it doesn't mention string lambdas, whether in prose or code. Phobos pull request #707 (Switch std.algorithm/.range to lambda syntax)[2] attempted this and was approved and merged, but subsequently reverted due to bugs.
 * New functions would not support string lambdas.

----------

To be honest, I thought this was a foregone conclusion, but comments on Github indicate otherwise, hence this thread.

What does everyone think?

 [1] https://github.com/D-Programming-Language/phobos/pull/1453
 [2] https://github.com/D-Programming-Language/phobos/pull/707

On Tuesday, 6 August 2013 at 09:05:57 UTC, Jakob Ovrum wrote:
> In Phobos pull request #1453 (Implement chunkBy.)[1], the topic of string lambda functions has again cropped up. I think we should clearly decide on some things regarding them. Questions such as; are they a worthwhile alternative in the present language? Should they be deprecated? Should they be supported in new additions to Phobos?
>
> What does everyone think?

I was certainly irritated, when I used the std.functional stuff the first time. Code generation through strings is kind of a last resort to me. It should be avoided if possible. Since it is possible now, I would vote for deprecating string functions.

Jakob Ovrum:

> What does everyone think?

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?


My opinion is that lambdas are more clean, and I usually prefer them, but in certain situations I prefer string lambdas.

So my vote is -0.

Bye,
bearophile

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);

> 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.

On Tuesday, 6 August 2013 at 10:05:54 UTC, Jakob Ovrum wrote:
> I think those few situations should forego string lambdas in favour of reduced cognitive load and increased consistency.

To clarify: those are the benefits we gain under the presumption that string lambdas are not inherently flawed.

I personally believe that they *are* - as long as string lambdas magically introduce symbols and are limited to an arbitrary selection of accessible symbols, I don't think it's reasonable to use them in *any* code.

Am 06.08.2013 12:09, schrieb Jakob Ovrum:
> On Tuesday, 6 August 2013 at 10:05:54 UTC, Jakob Ovrum wrote:
>> I think those few situations should forego string lambdas in
>> favour of reduced cognitive load and increased consistency.
>
> To clarify: those are the benefits we gain under the presumption
> that string lambdas are not inherently flawed.
>
> I personally believe that they *are* - as long as string lambdas
> magically introduce symbols and are limited to an arbitrary
> selection of accessible symbols, I don't think it's reasonable to
> use them in *any* code.
>

100% correct - string lambdas behave just not very generic, at all

but normal lambdas do, with the big disadvantage of a little bit more keyboard grinding :)

On Tuesday, 6 August 2013 at 10:22:53 UTC, dennis luehring wrote:
> but normal lambdas do, with the big disadvantage of a little bit more keyboard grinding :)

It's a "big disadvantage" only if you're following the Perl school of programming :P

Am 06.08.2013 12:49, schrieb Jakob Ovrum:
> On Tuesday, 6 August 2013 at 10:22:53 UTC, dennis luehring wrote:
>> but normal lambdas do, with the big disadvantage of a little
>> bit more keyboard grinding :)
>
> It's a "big disadvantage" only if you're following the Perl
> school of programming :P
>

according to

https://github.com/D-Programming-Language/phobos/pull/707

there where errors and everything was just reverted (without further analysis?) - any idea about the current state

On Tuesday, 6 August 2013 at 09:51:07 UTC, bearophile wrote:
>
> So my vote is -0.
>
Curse you, flush-to-zero denormal mode! ;)

@OP: To be honest, I didn't even know about string lambdas.  They don't seem to be a well-advertised, hot-button feature.  Just looking at the examples, I rather think they're hard for humans to parse, and wouldn't even notice if they were quietly dragged out back and exorcised.

-Wyatt

I would vote for marking it as  deprecated, and clearly indicating it as such in the docs.