Future of string lambda functions/string predicate functions

[Jakob Ovrum]

On Wednesday, 7 August 2013 at 00:54:10 UTC, bearophile wrote:
> In Scala they sometimes use lambdas where arguments are 
> underscores 
> (http://stackoverflow.com/questions/7673545/usage-of-in-scala-lambda-functions 
> ).
>
> It's not good to give names to lambda arguments every time. In 
> a program it's useful to give names to variables to make them 
> more readable, but if you look at Haskell code you see several 
> variable names like "a", "b", etc. They use such variable names 
> not because they are lazy people, but because you are writing a 
> very generic function, and very short names are good to remind 
> you they are not important for their semantics, but for other 
> things, like their position.

I recognize the existence of code where symbol names like "a" and 
"b" are perfectly justifiable. However, I think they are in the 
minority and should not be encouraged for the average case, 
whether by language or library. I also think that names like "a" 
and "b" probably appear more in library code than application 
code, particularly libraries with wide utility such as Phobos, 
which further leads me to believe that they should not be 
implicitly encouraged.

> Using default names as 'a' and 'b' for very simple lambdas is 
> nice.

I strongly disagree; in functional compositions in user code, I 
think "a" and "b" are most commonly justified when doing numeric 
operations, which is only a subset of what the generic algorithms 
in Phobos aim to facilitate. In the general case, more specific 
identifier names are desirable.

> And "(a, b) => a > b)" doesn't give more information than "q{a 
> > b}".

I'm not so sure. The lambda literal syntax is a universally 
applicable language construct that most D programmers will come 
to know; I don't know if I can say the same about string lambdas. 
q{}-style string literals are not just for D source code, so 
syntax highlighting may or may not treat it as such.

With the lambda literal syntax, the names "a" and "b" are not 
part of any implicit context and have no exceptional meaning - 
with a few notable exceptions such as the implicit `this` 
parameter, explicitly introduced symbols are the norm in D.

In some languages, such as Go, one can see a reminiscent style of 
OOP where even the `this` parameter is explicit. I'm not familiar 
with the full reasoning behind this so it may be a complete red 
herring, but I think it's interesting to note.

> In functional-style code it's important to have means, when you 
> desire it, to write compact code.

I completely agree, but I argue that string lambdas enable you to 
compact your code by means of obscurity, which is 
counter-productive, assuming the goal is to write more readable 
code.