www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Future of string lambda functions/string predicate functions

reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
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
Aug 06 2013
next sibling parent "qznc" <qznc web.de> writes:
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.
Aug 06 2013
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Aug 06 2013
parent reply dennis luehring <dl.soluz gmx.net> writes:
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 :)
Aug 06 2013
parent dennis luehring <dl.soluz gmx.net> writes:
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
Aug 06 2013
prev sibling next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
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.
Aug 06 2013
prev sibling next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
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.
Aug 06 2013
prev sibling next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
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
Aug 06 2013
prev sibling next sibling parent "Wyatt" <wyatt.epp gmail.com> writes:
On Tuesday, 6 August 2013 at 09:51:07 UTC, bearophile wrote:
 So my vote is -0.

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
Aug 06 2013
prev sibling next sibling parent "Andre Artus" <andre.artus gmail.com> writes:
I would vote for marking it as  deprecated, and clearly 
indicating it as such in the docs.
Aug 06 2013
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Tuesday, 6 August 2013 at 10:52:06 UTC, dennis luehring wrote:
 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

More details from it being reopened: https://github.com/D-Programming-Language/phobos/pull/744
Aug 06 2013
prev sibling next sibling parent reply "Meta" <jared771 gmail.com> writes:
On Tuesday, 6 August 2013 at 09:05:57 UTC, Jakob Ovrum wrote:
  * 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.

Looks good except for the above point. UnaryFun and binaryFun still have valid use cases, and I'd argue that it's even worth making an nAryFun!(pred, arity). import std.functional; import std.stdio; alias less = (int a, int b) => a < b; //Error alias less = binaryFun!((a, b) => a < b); //Ok void main() { writeln(less(1, 2)); //True }
Aug 06 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/07/2013 06:18 AM, Jakob Ovrum wrote:
 On Tuesday, 6 August 2013 at 19:38:08 UTC, Meta wrote:
 Looks good except for the above point. UnaryFun and binaryFun still
 have valid use cases, and I'd argue that it's even worth making an
 nAryFun!(pred, arity).

 import std.functional;
 import std.stdio;

 alias less = (int a, int b) => a < b; //Error
 alias less = binaryFun!((a, b) => a < b); //Ok

 void main()
 {
     writeln(less(1, 2)); //True
 }

This is a good point. I also agree that a fully generic, n-ary wrapper is the way to go for these cases.

I think the way to go for these cases is to fix the parser.
 I don't like the name `nAryFun` though, hopefully there's a more generic
 name that doesn't dwell on the history that would be `unaryFun` and
 `binaryFun`.

Aug 07 2013
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Tuesday, 6 August 2013 at 09:05:57 UTC, Jakob Ovrum wrote:
 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.

Yes x 4. I think this is the perfect path to their semi-deprecation. Deprecating them completely, I think, would be unwise since there's a lot of code out there using them. Deprecation through obscurity while retaining backwards-compatibility is the right choice.
Aug 06 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 6 August 2013 at 20:28:59 UTC, Peter Alexander wrote:
 On Tuesday, 6 August 2013 at 09:05:57 UTC, Jakob Ovrum wrote:
 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.

Yes x 4. I think this is the perfect path to their semi-deprecation. Deprecating them completely, I think, would be unwise since there's a lot of code out there using them. Deprecation through obscurity while retaining backwards-compatibility is the right choice.

I agree this is the best decision.
Aug 06 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Jakob Ovrum:

 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.

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. Using default names as 'a' and 'b' for very simple lambdas is nice. And "(a, b) => a > b)" doesn't give more information than "q{a > b}". In functional-style code it's important to have means, when you desire it, to write compact code. So I'd like to keep the string lambdas. Bye, bearophile
Aug 06 2013
prev sibling next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Tuesday, 6 August 2013 at 19:38:08 UTC, Meta wrote:
 Looks good except for the above point. UnaryFun and binaryFun 
 still have valid use cases, and I'd argue that it's even worth 
 making an nAryFun!(pred, arity).

 import std.functional;
 import std.stdio;

 alias less = (int a, int b) => a < b; //Error
 alias less = binaryFun!((a, b) => a < b); //Ok

 void main()
 {
     writeln(less(1, 2)); //True
 }

This is a good point. I also agree that a fully generic, n-ary wrapper is the way to go for these cases. I don't like the name `nAryFun` though, hopefully there's a more generic name that doesn't dwell on the history that would be `unaryFun` and `binaryFun`.
Aug 06 2013
prev sibling next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
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.
Aug 06 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Tuesday, 6 August 2013 at 21:35:05 UTC, John Colvin wrote:
 On Tuesday, 6 August 2013 at 20:28:59 UTC, Peter Alexander 
 wrote:
 On Tuesday, 6 August 2013 at 09:05:57 UTC, Jakob Ovrum wrote:
 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.

Yes x 4. I think this is the perfect path to their semi-deprecation. Deprecating them completely, I think, would be unwise since there's a lot of code out there using them. Deprecation through obscurity while retaining backwards-compatibility is the right choice.

I agree this is the best decision.

I actual think this is a very bad situation. This puts them in the odd spot of "not deprecated, but sometimes supported". This puts the end coder who *wants* to use lambdas (after all they aren't deprecated), in a weird position of "which functions support it, which functions don't?" Since the end coder is not a D guru, he'll have no idea which functions do support string lambdas, and which don't, which will leave him in an eternal guessing game of "well, looks like *that* doesn't compile"... So, if we *do* choose that string lambdas should leave, then I believe they should clearly be marked as "deprecated". We can leave them in forever, but the end user *must* be told that string lambdas are *not* the way it is meant to be used anymore. -------- Related: My vote goes that they should stay. Sure, normal lambdas are more powerful, but string lambdas are very light weight. Do you really argue that this is better? sort!((a, b) => a > b)(1, 2, 3); vs sort!"a > b"(1, 2, 3); string lambdas look clearer to me. Also, and this is important (!): A lambda is *always unique*, whereas strings alias each other. This means that: sort!"a > b"(1, 2, 3); //Both generate the same template sort!"a > b"(1, 2, 3); // sort!((a, b) => a > b)(1, 2, 3); //Generates two different templates sort!((a, b) => a > b)(1, 2, 3); This is particularly relevant for *struct* that take preds. Imagine: Sorter!"a > b" sorter1; Sorter!"a > b" sorter2; static assert(typeof(sorter1) == typeof(sorter2)); //Passes But Sorter!((a, b) => a > b) sorter1; Sorter!((a, b) => a > b) sorter2; static assert(typeof(sorter1) == typeof(sorter2)); //Fails -------- So, my vote is that string lambdas should stay. Supporting them is easy: Just an extra alias at the top of the function. Getting rid of them buys us nothing. There are people who use them, and there are cases where they make more sense. I *AM* 100% perfectly fine with making the default pred a normal lambda though, and promote their use over string lambdas.
Aug 07 2013
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Wednesday, 7 August 2013 at 09:12:41 UTC, monarch_dodra wrote:
 Since the end coder is not a D guru, he'll have no idea which 
 functions do support string lambdas, and which don't, which 
 will leave him in an eternal guessing game of "well, looks like 
 *that* doesn't compile"...

String lambdas won't be documented anywhere, so any newcomer to D hopefully won't even know they exist, so this problem won't happen.
 So, if we *do* choose that string lambdas should leave, then I 
 believe they should clearly be marked as "deprecated". We can 
 leave them in forever, but the end user *must* be told that 
 string lambdas are *not* the way it is meant to be used anymore.

Deprecating them (eventually) breaks existing code, which is unacceptable IMO.
 So, my vote is that string lambdas should stay. Supporting them 
 is easy: Just an extra alias at the top of the function. 
 Getting rid of them buys us nothing.

It simplifies the standard library, and makes it easier to write higher-order functions and ranges.
Aug 07 2013
prev sibling next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Wednesday, 7 August 2013 at 09:12:41 UTC, monarch_dodra wrote:
 Also, and this is important (!): A lambda is *always unique*, 
 whereas strings alias each other. This means that:

 sort!"a > b"(1, 2, 3); //Both generate the same template
 sort!"a > b"(1, 2, 3); //

 sort!((a, b) => a > b)(1, 2, 3); //Generates two different 
 templates
 sort!((a, b) => a > b)(1, 2, 3);

 This is particularly relevant for *struct* that take preds.

 Imagine:
 Sorter!"a > b" sorter1;
 Sorter!"a > b" sorter2;
 static assert(typeof(sorter1) == typeof(sorter2)); //Passes

 But
 Sorter!((a, b) => a > b) sorter1;
 Sorter!((a, b) => a > b) sorter2;
 static assert(typeof(sorter1) == typeof(sorter2)); //Fails

Ew. I don't see this as a good argument. Code and strings are fundamentally different. All the following functionally equivalent string lambdas will produce different instantiations of Sorter: "a > b" "b < a" "a<b" " a < b" etc.
Aug 07 2013
prev sibling next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Wednesday, 7 August 2013 at 10:03:58 UTC, Jakob Ovrum wrote:
 All the following functionally equivalent string lambdas will 
 produce different instantiations of Sorter:

     "a > b"
     "b < a"
     "a<b"
     " a < b"

 etc.

Oops, accidentally reversed it there. Correction: "a > b" "b < a" "a>b" " a > b"
Aug 07 2013
prev sibling next sibling parent "Dejan Lekic" <dejan.lekic gmail.com> writes:
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?

 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

I could not agree more! Naturally the deprecation path should be done carefully, as many people already pointed out.
Aug 07 2013
prev sibling next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Wednesday, 7 August 2013 at 11:16:05 UTC, Timon Gehr wrote:
 I think the way to go for these cases is to fix the parser.

I'd be very happy with such a change, but to my understanding, it's not just a parser issue. Perhaps a DIP that describes exactly how alias should work and what it should accept is in order for such a change.
Aug 07 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
I kind of loved old string lambdas in std.algorithm and was 
against introduction of new shorter lambda syntax. Still not 
convinced by the change but keeping both does not make sense for 
sure. So, yes, string lambdas should be deprecated and normal 
ones patches to support all remaining use cases.
Aug 07 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, August 06, 2013 11:05:56 Jakob Ovrum wrote:
 What does everyone think?

I'm completely opposed to the removal of string lambdas. Obviously, they don't always work. More complicated functions definitely need to use the newer lambda syntax or function literals. But for simple lambdas, they're way better. I'd _much_ rather have func!"a != b"(args) than func!((a, b) => a != b)(args) or func!"a < b"(args) than func!((a, b) => a < b)(args). String lambdas are nice and short, and I think that they're plenty clear, and if they're not, they're trivial to explain. We already have string lambdas. Removing them would break code for little benefit IMHO. If you prefer to use the newer lambda syntax, then use that, but I think that it's a definite loss if we get rid of the string lambdas, as they're so much more concise when they do work. I also think that all new Phobos functions which take unary or binary predicates should support string lambdas. It's trivial for them to do so, and it creates needless inconsistencies if some functions support them and some don't. - Jonathan M Davis
Aug 06 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, August 06, 2013 12:09:25 Jakob Ovrum wrote:
 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.

So, don't use them with functions. Just use them with operators. They're fantastic for that and far less verbose than the newer lambda syntax is for the same code. - Jonathan M Davis
Aug 06 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 8/6/13, Jakob Ovrum <jakobovrum gmail.com> wrote:
   * Leave support for string lambdas in existing Phobos functions
 for the foreseeable future, for backwards-compatibility purposes.
   * New functions would not support string lambdas.

Yeah, I agree. There's a benefit of having less features that do the exact same thing, especially for people new to D. Btw, I don't buy Jonathan's "less is better" argument at all, especially knowing what std.datetime looks like. He's arguing that string lambdas are somehow smaller, yet he writes code with symbol names such as hasOverloadedOpBinaryWithSelf, hasOverloadedOpAssignWithDuration, tzDatabaseNameToWindowsTZName, and forces us to write code like so: cast(DateTime)SysTime(unixTimeToStdTime(_unixIntTime); or even: if (curTime.peek > cast(TickDuration)1.seconds) { } Where is the short syntax for these expressions? I have to write my own wrappers for these of course. And JMD also argues that "seconds" is somehow better then "secs". "secs" is simple and consistent with "nsecs", "usecs", "msecs", but he always shots it down like it's some kind of abomination because "standards and stuff" which nobody really cares about. I always end up writing "secs" and get back a compiler error, it's frustrating. I'd say keep the current string lambda parameters intact, but don't introduce any new ones to new functions.
Aug 06 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Aug 06 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Aug 06, 2013 at 11:05:56AM +0200, 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?
 
 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?

Seems this thread has quietened down. So, what is the conclusion? Seems like almost everyone concedes that silent deprecation is the way to go. We still support string lambdas in the background, but in public docs we promote the use of the new lambda syntax. Would that be a fair assessment of this discussion? What about new Phobos functions? Should we continue to support string lambdas in new code? T -- Life is unfair. Ask too much from it, and it may decide you don't deserve what you have now either.
Aug 08 2013
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, August 08, 2013 07:29:56 H. S. Teoh wrote:
 Seems this thread has quietened down. So, what is the conclusion? Seems
 like almost everyone concedes that silent deprecation is the way to go.
 We still support string lambdas in the background, but in public docs we
 promote the use of the new lambda syntax. Would that be a fair
 assessment of this discussion?

I find it interesting that very few Phobos devs have weighed in on the matter, but unfortunately, most of the posters who have weighed in do seem to be against keeping them.
 What about new Phobos functions? Should we continue to support string
 lambdas in new code?

Personally, I don't think that silent deprecation is ever a good idea. If we do that, we're going to end up with confusion over which functions accept strings and which don't, and it won't be clear that we're trying to get rid of them. I think that we need to clearly choose one path or the other: either 1. Choose to keep string lambdas around permanently and support them, even if they're used for a limited number of use cases (e.g. with simple lambdas which use operators but not function calls). or 2. Put them on the path to deprecation towards removal (in which case, they might actually stay marked as deprecated for quite some time to come but would clearly be unacceptable for new code and might be fully removed at some point in the future). - Jonathan M Davis
Aug 08 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/8/13 9:52 AM, Jonathan M Davis wrote:
 On Thursday, August 08, 2013 07:29:56 H. S. Teoh wrote:
 Seems this thread has quietened down. So, what is the conclusion? Seems
 like almost everyone concedes that silent deprecation is the way to go.
 We still support string lambdas in the background, but in public docs we
 promote the use of the new lambda syntax. Would that be a fair
 assessment of this discussion?

I find it interesting that very few Phobos devs have weighed in on the matter, but unfortunately, most of the posters who have weighed in do seem to be against keeping them.

There's a related issue that I think we must solve before deciding whether or not we should deprecate string lambdas. Consider: void main() { import std.range; SortedRange!(int[], "a > b") a; SortedRange!(int[], "a > b") b; b = a; SortedRange!(int[], (a, b) => a > b) c; SortedRange!(int[], (a, b) => a > b) d; d = c; } The last line fails to compile because D does not currently have a good notion of comparing lambdas for equality. In contrast, string comparison is well defined, and although string lambdas have clowny issues with e.g. "a>b" being different from "a > b", people have a good understanding of what to do to get code working. So I think we should come up with a good definition of what comparing two function aliases means. Andrei
Aug 11 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/11/2013 9:26 AM, Andrei Alexandrescu wrote:
 There's a related issue that I think we must solve before deciding whether or
 not we should deprecate string lambdas. Consider:

 void main() {
      import std.range;
      SortedRange!(int[], "a > b") a;
      SortedRange!(int[], "a > b") b;
      b = a;
      SortedRange!(int[], (a, b) => a > b) c;
      SortedRange!(int[], (a, b) => a > b) d;
      d = c;
 }

 The last line fails to compile because D does not currently have a good notion
 of comparing lambdas for equality.

Bugzilla?
Aug 11 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/11/13 11:46 AM, Walter Bright wrote:
 On 8/11/2013 9:26 AM, Andrei Alexandrescu wrote:
 There's a related issue that I think we must solve before deciding
 whether or
 not we should deprecate string lambdas. Consider:

 void main() {
      import std.range;
      SortedRange!(int[], "a > b") a;
      SortedRange!(int[], "a > b") b;
      b = a;
      SortedRange!(int[], (a, b) => a > b) c;
      SortedRange!(int[], (a, b) => a > b) d;
      d = c;
 }

 The last line fails to compile because D does not currently have a
 good notion
 of comparing lambdas for equality.

Bugzilla?

http://d.puremagic.com/issues/show_bug.cgi?id=10819 Andrei
Aug 13 2013
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Aug 08, 2013 at 09:52:05AM -0700, Jonathan M Davis wrote:
 On Thursday, August 08, 2013 07:29:56 H. S. Teoh wrote:
 Seems this thread has quietened down. So, what is the conclusion?
 Seems like almost everyone concedes that silent deprecation is the
 way to go.  We still support string lambdas in the background, but
 in public docs we promote the use of the new lambda syntax. Would
 that be a fair assessment of this discussion?

I find it interesting that very few Phobos devs have weighed in on the matter, but unfortunately, most of the posters who have weighed in do seem to be against keeping them.

Well, it would be nice of the rest of the Phobos devs speak up, otherwise they are giving the wrong impression about the state of things. T -- Many open minds should be closed for repairs. -- K5 user
Aug 08 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/8/2013 10:02 AM, H. S. Teoh wrote:
 Well, it would be nice of the rest of the Phobos devs speak up,
 otherwise they are giving the wrong impression about the state of
 things.

See Andrei's reply.
Aug 11 2013
prev sibling next sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Saturday, 10 August 2013 at 18:28:29 UTC, Jonathan M Davis 
wrote:
 I find it interesting that very few Phobos devs have weighed in 
 on the matter,
 but unfortunately, most of the posters who have weighed in do 
 seem to be
 against keeping them.

I am not actively participating in any NG discussions right now due to university work, but for the record, I am very much in favor of phasing out string lambdas as well (even if short-term removal is certainly not possible at this point). I am sure all the relevant arguments have been brought up already, so I am not going to repeat them all over again, but in my opinion, the increased cognitive load for the user (a new syntax to learn) and the fact that string lambdas can't work for any cases involving free functions (std.functional importing half of Phobos just in case a string lambda could need a certain function clearly isn't a scalable solution) are more than enough a reason to ditch them. String lambdas were a brilliant hack back then, but now that we have a proper solution, it's time to let them go. David
Aug 11 2013
prev sibling next sibling parent "Tyler Jameson Little" <beatgammit gmail.com> writes:
On Sunday, 11 August 2013 at 16:26:16 UTC, Andrei Alexandrescu 
wrote:
 On 8/8/13 9:52 AM, Jonathan M Davis wrote:
 On Thursday, August 08, 2013 07:29:56 H. S. Teoh wrote:
 Seems this thread has quietened down. So, what is the 
 conclusion? Seems
 like almost everyone concedes that silent deprecation is the 
 way to go.
 We still support string lambdas in the background, but in 
 public docs we
 promote the use of the new lambda syntax. Would that be a fair
 assessment of this discussion?

I find it interesting that very few Phobos devs have weighed in on the matter, but unfortunately, most of the posters who have weighed in do seem to be against keeping them.

There's a related issue that I think we must solve before deciding whether or not we should deprecate string lambdas. Consider: void main() { import std.range; SortedRange!(int[], "a > b") a; SortedRange!(int[], "a > b") b; b = a; SortedRange!(int[], (a, b) => a > b) c; SortedRange!(int[], (a, b) => a > b) d; d = c; } The last line fails to compile because D does not currently have a good notion of comparing lambdas for equality. In contrast, string comparison is well defined, and although string lambdas have clowny issues with e.g. "a>b" being different from "a > b", people have a good understanding of what to do to get code working. So I think we should come up with a good definition of what comparing two function aliases means. Andrei

Correct me if I'm wrong, but AFAICT the old behavior was an undocumented feature. I couldn't find string lambdas formally documented anywhere, but lambdas are. Comparing function aliases is an optimization, not a feature, so I don't feel it's a blocker to deprecating string lambdas. If the user needs the old behavior, he/she can do this today with an actual function: bool gt(int a, int b) { return a > b; } void main() { import std.range; SortedRange!(int[], "a > b") a; SortedRange!(int[], "a > b") b; b = a; SortedRange!(int[], gt) c; SortedRange!(int[], gt) d; d = c; } While not as concise, this is safer and does not rely on undocumented behavior. Another consideration, are the following equivalent? (a,b) => a > b (b,c) => b > c
Aug 11 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Aug 11, 2013 at 09:26:17AM -0700, Andrei Alexandrescu wrote:
 On 8/8/13 9:52 AM, Jonathan M Davis wrote:
On Thursday, August 08, 2013 07:29:56 H. S. Teoh wrote:
Seems this thread has quietened down. So, what is the conclusion?
Seems like almost everyone concedes that silent deprecation is the
way to go.  We still support string lambdas in the background, but
in public docs we promote the use of the new lambda syntax. Would
that be a fair assessment of this discussion?

I find it interesting that very few Phobos devs have weighed in on the matter, but unfortunately, most of the posters who have weighed in do seem to be against keeping them.

There's a related issue that I think we must solve before deciding whether or not we should deprecate string lambdas. Consider: void main() { import std.range; SortedRange!(int[], "a > b") a; SortedRange!(int[], "a > b") b; b = a; SortedRange!(int[], (a, b) => a > b) c; SortedRange!(int[], (a, b) => a > b) d; d = c; } The last line fails to compile because D does not currently have a good notion of comparing lambdas for equality. In contrast, string comparison is well defined, and although string lambdas have clowny issues with e.g. "a>b" being different from "a > b", people have a good understanding of what to do to get code working. So I think we should come up with a good definition of what comparing two function aliases means.

I'm not sure how the compiler handles delegates internally, but a first shot at it might be, any delegate with the same expression tree within the same scope should compare equally. I don't know if this is actually feasible to implement, though (I'm not familiar with DMD code). The reason it must be the same scope is because otherwise, the delegate might be closing over different variables, so it should not be treated the same way (otherwise two delegates that are textwise the same may have different runtime behaviours, leading to a wrong conflation of template instantiations). T -- Elegant or ugly code as well as fine or rude sentences have something in common: they don't depend on the language. -- Luca De Vitis
Aug 13 2013
prev sibling next sibling parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Sunday, 11 August 2013 at 18:30:02 UTC, Tyler Jameson Little 
wrote:
 Correct me if I'm wrong, but AFAICT the old behavior was an 
 undocumented feature. I couldn't find string lambdas formally 
 documented anywhere, but lambdas are.

They are documented in std.functional: http://dlang.org/phobos/std_functional.html#.binaryFun Namely because they are not a language feature but instead the power of D's other features.
 Comparing function aliases is an optimization, not a feature,

I don't really think it is an optimization either. What Andrei was requesting was a definition of what constitutes equality for equality for lambdas. However none of what I said should be taken to contradict your point that one can still use a named function to keep types equal.
 If the user needs the old behavior, he/she can do this today 
 with an actual function

This assumes you are not receiving a sorted range from a third party library and passing it to another third party.
Aug 13 2013
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
--089e01228a5a0bedf104e3dec966
Content-Type: text/plain; charset=UTF-8

On 6 August 2013 19:25, Jonathan M Davis <jmdavisProg gmx.com> wrote:

 On Tuesday, August 06, 2013 11:05:56 Jakob Ovrum wrote:
 What does everyone think?

I'm completely opposed to the removal of string lambdas. Obviously, they don't always work. More complicated functions definitely need to use the newer lambda syntax or function literals. But for simple lambdas, they're way better. I'd _much_ rather have func!"a != b"(args) than func!((a, b) => a != b)(args) or func!"a < b"(args) than func!((a, b) => a < b)(args). String lambdas are nice and short, and I think that they're plenty clear, and if they're not, they're trivial to explain.

Can you give an example where you've actually used a string lambda before where the predicate is more complex than a basic comparison? Surely the solution to this problem is to offer a bunch of templates that perform the most common predicates in place of unary/binaryFun? So rather than: func!((a, b) => a < b)(args) You use: func!binaryLess(args) Or something like that? The thing that annoys me about string vs proper lambda's, is that I never know which one I'm supposed to use. I need to refer to documentation every time. Also, the syntax highlighting fails. We already have string lambdas. Removing them would break code for little
 benefit IMHO. If you prefer to use the newer lambda syntax, then use that,
 but
 I think that it's a definite loss if we get rid of the string lambdas, as
 they're so much more concise when they do work.

 I also think that all new Phobos functions which take unary or binary
 predicates should support string lambdas. It's trivial for them to do so,
 and
 it creates needless inconsistencies if some functions support them and some
 don't.

 - Jonathan M Davis

--089e01228a5a0bedf104e3dec966 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On 6 August 2013 19:25, Jonathan M Davis <span dir=3D"ltr"=
&lt;<a href=3D"mailto:jmdavisProg gmx.com" target=3D"_blank">jmdavisProg g=

ail_quote"> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex">On Tuesday, August 06, 2013 11:05:56 Jakob Ovrum wrote:<br=

&gt; What does everyone think?<br> <br> I&#39;m completely opposed to the removal of string lambdas. Obviously, the= y don&#39;t<br> always work. More complicated functions definitely need to use the newer la= mbda<br> syntax or function literals. But for simple lambdas, they&#39;re way better= . I&#39;d<br> _much_ rather have func!&quot;a !=3D b&quot;(args) than func!((a, b) =3D&gt= ; a !=3D b)(args) or<br> func!&quot;a &lt; b&quot;(args) than func!((a, b) =3D&gt; a &lt; b)(args). = String lambdas are nice<br> and short, and I think that they&#39;re plenty clear, and if they&#39;re no= t, they&#39;re<br> trivial to explain.<br></blockquote><div><br></div><div>Can you give an exa= mple where you&#39;ve actually used a string lambda before where the predic= ate is more complex than a basic comparison?</div><div>Surely the solution = to this problem is to offer a bunch of templates that perform the most comm= on predicates in place of unary/binaryFun?<br> </div><div><br></div><div>So rather than: func!((a, b) =3D&gt; a &lt; b)(ar= gs)</div><div>You use: func!binaryLess(args)</div><div><br></div><div>Or so= mething like that?</div><div><br></div><div>The thing that annoys me about = string vs proper lambda&#39;s, is that I never know which one I&#39;m suppo= sed to use. I need to refer to documentation every time.</div> <div>Also, the syntax highlighting fails.</div><div><br></div><blockquote c= lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1p= x;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1= ex"> We already have string lambdas. Removing them would break code for little<b= r> benefit IMHO. If you prefer to use the newer lambda syntax, then use that, = but<br> I think that it&#39;s a definite loss if we get rid of the string lambdas, = as<br> they&#39;re so much more concise when they do work.<br> <br> I also think that all new Phobos functions which take unary or binary<br> predicates should support string lambdas. It&#39;s trivial for them to do s= o, and<br> it creates needless inconsistencies if some functions support them and some= <br> don&#39;t.<br> <span class=3D""><font color=3D"#888888"><br> - Jonathan M Davis<br> </font></span></blockquote></div><br></div></div> --089e01228a5a0bedf104e3dec966--
Aug 13 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/14/13 7:34 AM, H. S. Teoh wrote:
 On Wed, Aug 14, 2013 at 09:10:37AM +0200, Tyler Jameson Little wrote:
 On Wednesday, 14 August 2013 at 05:44:50 UTC, Brad Anderson wrote:
 On Wednesday, 14 August 2013 at 02:05:16 UTC, Manu wrote:
 Can you give an example where you've actually used a string lambda
 before where the predicate is more complex than a basic comparison?
 Surely the solution to this problem is to offer a bunch of templates
 that perform the most common predicates in place of unary/binaryFun?

 So rather than: func!((a, b) => a < b)(args)
 You use: func!binaryLess(args)

 Or something like that?

How about just "less"? It's what C++ STL uses (std::less, std::greater, std::negate, etc...). In C++, however, you have to do some truly ugly stuff to actually make use of the predefined function objects...bind1st...eww (the new C++11 bind is only marginally better but C++11 does have lambdas now at least).


 Or imitate bash:

 Binary:
 - gt: a > b
 - ge: a >= b
 - lt: a < b
 - le: a <= b
 - eq: a == b
 - ne: a != b

 Unary:
 - z: (zero) a == 0 (if range, a.empty?)
 - n: (non-zero) a != 0

 Perhaps this is *too* terse?

That's a bit too terse. What about this: less // a < b less!(5) // a < 5 lessEq // a <= b lessEq!(5) // a <= 5 more // a > b more!(5) // a > 5 moreEq // a >= b moreEq!(5) // a >= 5 equal // a == b equal!(5) // a == 5 notEqual // a != b notEqual!(5) // a != 5

At this point using "a < b" for a < b, "a < 5" for a < 5 etc. becomes awfully attractive. Andrei
Aug 14 2013
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
14-Aug-2013 20:37, H. S. Teoh пишет:
 On Wed, Aug 14, 2013 at 09:26:20AM -0700, Andrei Alexandrescu wrote:

 It just occurred to me, that perhaps what we really need here is an
 even more abbreviated form of lambda literals, like this:

 	sort!(a < b)(range);

 where 'a' and 'b' are undefined identifiers in the current scope, and
 the compiler would know to bind them to lambda parameters. Defined
 identifiers would, naturally, bind to whatever they refer to:

Make that sort!( _ < _)(range) and you have some Scala :)
 	int x = 5;
 	find!(a == x)(range);

 This would be equivalent to:

 	int x = 5;
 	find!((a) => a==x)(range);

 IOW, an expression that references undefined identifiers in a template
 parameter would be turned into a lambda that parametrize said
 identifiers.


 T

-- Dmitry Olshansky
Aug 14 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/14/13 10:15 AM, Dmitry Olshansky wrote:
 14-Aug-2013 20:37, H. S. Teoh пишет:
 On Wed, Aug 14, 2013 at 09:26:20AM -0700, Andrei Alexandrescu wrote:

 It just occurred to me, that perhaps what we really need here is an
 even more abbreviated form of lambda literals, like this:

     sort!(a < b)(range);

 where 'a' and 'b' are undefined identifiers in the current scope, and
 the compiler would know to bind them to lambda parameters. Defined
 identifiers would, naturally, bind to whatever they refer to:

Make that sort!( _ < _)(range) and you have some Scala :)

Really? How does Scala figure that _ < _ refers to two arguments and not one? Andrei
Aug 14 2013
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
14-Aug-2013 21:17, Andrei Alexandrescu пишет:
 On 8/14/13 10:15 AM, Dmitry Olshansky wrote:
 14-Aug-2013 20:37, H. S. Teoh пишет:
 On Wed, Aug 14, 2013 at 09:26:20AM -0700, Andrei Alexandrescu wrote:

 It just occurred to me, that perhaps what we really need here is an
 even more abbreviated form of lambda literals, like this:

     sort!(a < b)(range);

 where 'a' and 'b' are undefined identifiers in the current scope, and
 the compiler would know to bind them to lambda parameters. Defined
 identifiers would, naturally, bind to whatever they refer to:

Make that sort!( _ < _ )(range) and you have some Scala :)

Really? How does Scala figure that _ < _ refers to two arguments and not one?

Looking into "Programming in Scala, 2nd edition" again... Left to right, each underscore is a new parameter. Once you need the argument 2 times you are screwed and go back to the same syntax we have. Even more funny is that Scala can't bind templated parameters... val f = _ + _ Not going to fly since there is no context to infer argument types! Hence the crufty: val f = ( _ : Int) + ( _ : Int) In D: alias f = _ + _; Could work since with a bit of compiler magic (expression alias). Or even alias f = typeof(_ + _); with expression templates. Sounds like a solution but that would destroy the easy ordering of arguments...
 Andrei

-- Dmitry Olshansky
Aug 14 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/14/2013 11:21 AM, Dicebot wrote:
 On Wednesday, 14 August 2013 at 18:18:32 UTC, Dmitry Olshansky wrote:
 Could work since with a bit of compiler magic (expression alias).
 Or even
 alias f = typeof(_ + _);
 with expression templates. Sounds like a solution but that would destroy the
 easy ordering of arguments...

And here one should probably stop for a while and ask: "is it worth it?"

+1 for common sense.
Aug 14 2013
prev sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
14-Aug-2013 22:21, Dicebot пишет:
 On Wednesday, 14 August 2013 at 18:18:32 UTC, Dmitry Olshansky wrote:
 Could work since with a bit of compiler magic (expression alias).
 Or even
 alias f = typeof(_ + _);
 with expression templates. Sounds like a solution but that would
 destroy the easy ordering of arguments...

And here one should probably stop for a while and ask: "is it worth it?"

As a library - of course, it's a great exercise at futility. C++ Boost lambda was full of it as they had less powerful language. -- Dmitry Olshansky
Aug 14 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-08-14 19:17, Andrei Alexandrescu wrote:

 Really? How does Scala figure that _ < _ refers to two arguments and not
 one?

In Scala _ is something like a wildcard. * It can be used in imports: "import foo.bar._". Means import everything in foo.bar * It can be use as a fallback in pattern matching, like the default in a switch * It can be used in lambdas, as described above -- /Jacob Carlborg
Aug 14 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 14 August 2013 at 02:05:16 UTC, Manu wrote:
 Can you give an example where you've actually used a string 
 lambda before
 where the predicate is more complex than a basic comparison?
 Surely the solution to this problem is to offer a bunch of 
 templates that
 perform the most common predicates in place of unary/binaryFun?

 So rather than: func!((a, b) => a < b)(args)
 You use: func!binaryLess(args)

 Or something like that?

I was unsure about the solution we should adopt until I read that. This is what we need.
Aug 13 2013
prev sibling next sibling parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Wednesday, 14 August 2013 at 02:05:16 UTC, Manu wrote:
 So rather than: func!((a, b) => a < b)(args)
 You use: func!binaryLess(args)

 Or something like that?

I don't really like that solution, but I got a little closer: func!(opBinary!">")(args); The issue here are: func!"a.label < b.label"(args); and unaryFun: filter!"a > 0"(args); maybe: filter!(opUnary!">"(0))(args); Which is problematic: someFun!(opUnary!"++")(args); I find the string lambda to be perfect for the simple logic, and there isn't really a highlighting issue since there usually isn't anything to highlight anyway; and we have q{ tokens here }.
Aug 13 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, August 14, 2013 12:05:01 Manu wrote:
 Can you give an example where you've actually used a string lambda before
 where the predicate is more complex than a basic comparison?

You can use string lambdas with anything which std.functional imports, so std.algorithm std.conv std.exception std.math std.range std.string std.traits std.typecons std.typetuple And to show how broken string lambdas are, most of the imports are list like this // for making various functions visible in *naryFun import std.algorithm, std.conv, std.exception, std.math, std.range, std.string; All of those modules are imported specifically so that string lambdas can use their stuff. I'm sure that I've used std.conv.to and various string functions at minimum, since I generally prefer to use string lambdas when I can, but you generally have to just trying them and see what does and doesn't work if you want to use string lambdas for anything besides operators. Operators are where the major gain is though.
 Surely the solution to this problem is to offer a bunch of templates that
 perform the most common predicates in place of unary/binaryFun?
 
 So rather than: func!((a, b) => a < b)(args)
 You use: func!binaryLess(args)
 
 Or something like that?

That would result in too many stray templates. Something like binaryOp!"<" would make more sense. Then we pretty much just need unaryOp and binaryOp rather than a template for every operator. Other than that, it's a good idea though, since it allows us to make the common case cleaner.
 The thing that annoys me about string vs proper lambda's, is that I never
 know which one I'm supposed to use. I need to refer to documentation every
 time.

Unless you happen to have memorized what std.functional imports, it's a guessing game, which is the major problem with string lambdas. It also has the unfortunate side effect of making it so that we can't change what std.functional imports.
 Also, the syntax highlighting fails.

I've never really viewed that as problem. I _like_ the fact that they're highlighted as a string and therefore clearly separate from the rest of the expression. Having syntax highlighting inside the lambda is generally a negative IMHO, though I can see why you'd want it. The only places where I might want it would be complicated enough to require regular lambdas anyway, in which case, it might even be cleaner to use a nested function. - Jonathan M Davis
Aug 13 2013
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Wednesday, 14 August 2013 at 02:05:16 UTC, Manu wrote:
 Can you give an example where you've actually used a string 
 lambda before
 where the predicate is more complex than a basic comparison?
 Surely the solution to this problem is to offer a bunch of 
 templates that
 perform the most common predicates in place of unary/binaryFun?

 So rather than: func!((a, b) => a < b)(args)
 You use: func!binaryLess(args)

 Or something like that?

How about just "less"? It's what C++ STL uses (std::less, std::greater, std::negate, etc...). In C++, however, you have to do some truly ugly stuff to actually make use of the predefined function objects...bind1st...eww (the new C++11 bind is only marginally better but C++11 does have lambdas now at least).
 The thing that annoys me about string vs proper lambda's, is 
 that I never
 know which one I'm supposed to use. I need to refer to 
 documentation every
 time.
 Also, the syntax highlighting fails.

Aug 13 2013
prev sibling next sibling parent "Tyler Jameson Little" <beatgammit gmail.com> writes:
On Wednesday, 14 August 2013 at 05:44:50 UTC, Brad Anderson wrote:
 On Wednesday, 14 August 2013 at 02:05:16 UTC, Manu wrote:
 Can you give an example where you've actually used a string 
 lambda before
 where the predicate is more complex than a basic comparison?
 Surely the solution to this problem is to offer a bunch of 
 templates that
 perform the most common predicates in place of unary/binaryFun?

 So rather than: func!((a, b) => a < b)(args)
 You use: func!binaryLess(args)

 Or something like that?

How about just "less"? It's what C++ STL uses (std::less, std::greater, std::negate, etc...). In C++, however, you have to do some truly ugly stuff to actually make use of the predefined function objects...bind1st...eww (the new C++11 bind is only marginally better but C++11 does have lambdas now at least).
 The thing that annoys me about string vs proper lambda's, is 
 that I never
 know which one I'm supposed to use. I need to refer to 
 documentation every
 time.
 Also, the syntax highlighting fails.


Or imitate bash: Binary: - gt: a > b - ge: a >= b - lt: a < b - le: a <= b - eq: a == b - ne: a != b Unary: - z: (zero) a == 0 (if range, a.empty?) - n: (non-zero) a != 0 Perhaps this is *too* terse?
Aug 14 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Aug 14, 2013 at 09:10:37AM +0200, Tyler Jameson Little wrote:
 On Wednesday, 14 August 2013 at 05:44:50 UTC, Brad Anderson wrote:
On Wednesday, 14 August 2013 at 02:05:16 UTC, Manu wrote:
Can you give an example where you've actually used a string lambda
before where the predicate is more complex than a basic comparison?
Surely the solution to this problem is to offer a bunch of templates
that perform the most common predicates in place of unary/binaryFun?

So rather than: func!((a, b) => a < b)(args)
You use: func!binaryLess(args)

Or something like that?

How about just "less"? It's what C++ STL uses (std::less, std::greater, std::negate, etc...). In C++, however, you have to do some truly ugly stuff to actually make use of the predefined function objects...bind1st...eww (the new C++11 bind is only marginally better but C++11 does have lambdas now at least).


 Or imitate bash:
 
 Binary:
 - gt: a > b
 - ge: a >= b
 - lt: a < b
 - le: a <= b
 - eq: a == b
 - ne: a != b
 
 Unary:
 - z: (zero) a == 0 (if range, a.empty?)
 - n: (non-zero) a != 0
 
 Perhaps this is *too* terse?

That's a bit too terse. What about this: less // a < b less!(5) // a < 5 lessEq // a <= b lessEq!(5) // a <= 5 more // a > b more!(5) // a > 5 moreEq // a >= b moreEq!(5) // a >= 5 equal // a == b equal!(5) // a == 5 notEqual // a != b notEqual!(5) // a != 5 T -- A computer doesn't mind if its programs are put to purposes that don't match their names. -- D. Knuth
Aug 14 2013
prev sibling next sibling parent "Wyatt" <wyatt.epp gmail.com> writes:
On Wednesday, 14 August 2013 at 14:36:25 UTC, H. S. Teoh wrote:
 	more		// a > b
 	more!(5)	// a > 5
 	moreEq		// a >= b
 	moreEq!(5)	// a >= 5

Nitpick, but I'd personally prefer "greater" rather than "more". -Wyatt
Aug 14 2013
prev sibling next sibling parent "Mr. Anonymous" <mailnew4ster gmail.com> writes:
On Wednesday, 14 August 2013 at 14:36:25 UTC, H. S. Teoh wrote:
 A computer doesn't mind if its programs are put to purposes 
 that don't match their names. -- D. Knuth

Heh :) Sometimes I read your replies just for the signature. On the topic, I think the variant with the operators is more straightforward, e.g.:
 	less		// a < b

 	less!(5)	// a < 5

etc.
Aug 14 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--089e013cbebc0205eb04e3e9c207
Content-Type: text/plain; charset=UTF-8

I like the direction this thread is going :)


On 15 August 2013 00:50, Mr. Anonymous <mailnew4ster gmail.com> wrote:

 On Wednesday, 14 August 2013 at 14:36:25 UTC, H. S. Teoh wrote:

 A computer doesn't mind if its programs are put to purposes that don't
 match their names. -- D. Knuth

Heh :) Sometimes I read your replies just for the signature. On the topic, I think the variant with the operators is more straightforward, e.g.:
         less            // a < b

         less!(5)        // a < 5

etc.

--089e013cbebc0205eb04e3e9c207 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I like the direction this thread is going :)</div><div cla= ss=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On 15 August 2013 00:= 50, Mr. Anonymous <span dir=3D"ltr">&lt;<a href=3D"mailto:mailnew4ster gmai= l.com" target=3D"_blank">mailnew4ster gmail.com</a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"im">On Wednesday, 14 August 20= 13 at 14:36:25 UTC, H. S. Teoh wrote:<br> </div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0= 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> A computer doesn&#39;t mind if its programs are put to purposes that don&#3= 9;t match their names. -- D. Knuth<br> </blockquote> <br></div> Heh :)<br> Sometimes I read your replies just for the signature.<br> <br> On the topic, I think the variant with the operators is more straightforwar= d, e.g.:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> =C2=A0 =C2=A0 =C2=A0 =C2=A0 less =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/= / a &lt; b<br> </blockquote> op!&quot;&lt;&quot;<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> =C2=A0 =C2=A0 =C2=A0 =C2=A0 less!(5) =C2=A0 =C2=A0 =C2=A0 =C2=A0// a &lt; 5= <br> </blockquote> op!&quot;&lt;&quot;(5)<br> <br> etc.<br> </blockquote></div><br></div> --089e013cbebc0205eb04e3e9c207--
Aug 14 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Aug 14, 2013 at 09:26:20AM -0700, Andrei Alexandrescu wrote:
 On 8/14/13 7:34 AM, H. S. Teoh wrote:

That's a bit too terse. What about this:

	less		// a < b
	less!(5)	// a < 5
	lessEq		// a <= b
	lessEq!(5)	// a <= 5
	more		// a > b
	more!(5)	// a > 5
	moreEq		// a >= b
	moreEq!(5)	// a >= 5
	equal		// a == b
	equal!(5)	// a == 5
	notEqual	// a != b
	notEqual!(5)	// a != 5

At this point using "a < b" for a < b, "a < 5" for a < 5 etc. becomes awfully attractive.

It just occurred to me, that perhaps what we really need here is an even more abbreviated form of lambda literals, like this: sort!(a < b)(range); where 'a' and 'b' are undefined identifiers in the current scope, and the compiler would know to bind them to lambda parameters. Defined identifiers would, naturally, bind to whatever they refer to: int x = 5; find!(a == x)(range); This would be equivalent to: int x = 5; find!((a) => a==x)(range); IOW, an expression that references undefined identifiers in a template parameter would be turned into a lambda that parametrize said identifiers. T -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald Knuth
Aug 14 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Wednesday, 14 August 2013 at 16:38:57 UTC, H. S. Teoh wrote:
 On Wed, Aug 14, 2013 at 09:26:20AM -0700, Andrei Alexandrescu 
 wrote:
 On 8/14/13 7:34 AM, H. S. Teoh wrote:

That's a bit too terse. What about this:

	less		// a < b
	less!(5)	// a < 5
	lessEq		// a <= b
	lessEq!(5)	// a <= 5
	more		// a > b
	more!(5)	// a > 5
	moreEq		// a >= b
	moreEq!(5)	// a >= 5
	equal		// a == b
	equal!(5)	// a == 5
	notEqual	// a != b
	notEqual!(5)	// a != 5

At this point using "a < b" for a < b, "a < 5" for a < 5 etc. becomes awfully attractive.

It just occurred to me, that perhaps what we really need here is an even more abbreviated form of lambda literals, like this: sort!(a < b)(range); where 'a' and 'b' are undefined identifiers in the current scope, and the compiler would know to bind them to lambda parameters. Defined identifiers would, naturally, bind to whatever they refer to: int x = 5; find!(a == x)(range); This would be equivalent to: int x = 5; find!((a) => a==x)(range); IOW, an expression that references undefined identifiers in a template parameter would be turned into a lambda that parametrize said identifiers. T

That's a bit too fragile IMO. int b; //rename to 'a' // lots of intermediate code... int x = 5; r.blah!(a == x); Renaming of a seemingly unrelated variable would result in spooky action-at-a-distance behaviour.
Aug 14 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Aug 14, 2013 at 07:03:32PM +0200, John Colvin wrote:
 On Wednesday, 14 August 2013 at 16:38:57 UTC, H. S. Teoh wrote:
On Wed, Aug 14, 2013 at 09:26:20AM -0700, Andrei Alexandrescu
wrote:
On 8/14/13 7:34 AM, H. S. Teoh wrote:

That's a bit too terse. What about this:

	less		// a < b
	less!(5)	// a < 5
	lessEq		// a <= b
	lessEq!(5)	// a <= 5
	more		// a > b
	more!(5)	// a > 5
	moreEq		// a >= b
	moreEq!(5)	// a >= 5
	equal		// a == b
	equal!(5)	// a == 5
	notEqual	// a != b
	notEqual!(5)	// a != 5

At this point using "a < b" for a < b, "a < 5" for a < 5 etc. becomes awfully attractive.

It just occurred to me, that perhaps what we really need here is an even more abbreviated form of lambda literals, like this: sort!(a < b)(range); where 'a' and 'b' are undefined identifiers in the current scope, and the compiler would know to bind them to lambda parameters. Defined identifiers would, naturally, bind to whatever they refer to: int x = 5; find!(a == x)(range); This would be equivalent to: int x = 5; find!((a) => a==x)(range); IOW, an expression that references undefined identifiers in a template parameter would be turned into a lambda that parametrize said identifiers. T

That's a bit too fragile IMO. int b; //rename to 'a' // lots of intermediate code... int x = 5; r.blah!(a == x); Renaming of a seemingly unrelated variable would result in spooky action-at-a-distance behaviour.

Arguably, naming a variable as 'b' or 'a' is a bad idea, but, point taken. I guess we still have to fall back to full-fledged lambda literals, then. I'm still in favor of deprecating string lambdas, but as Andrei said, we need to address the problem of how to compare lambdas meaningfully. The question then becomes, what do we do *now*, for new additions to Phobos? Should new code still support string lambdas or not? T -- Right now I'm having amnesia and deja vu at the same time. I think I've forgotten this before.
Aug 14 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 14 August 2013 at 18:18:32 UTC, Dmitry Olshansky 
wrote:
 Could work since with a bit of compiler magic (expression 
 alias).
 Or even
 alias f = typeof(_ + _);
 with expression templates. Sounds like a solution but that 
 would destroy the easy ordering of arguments...

And here one should probably stop for a while and ask: "is it worth it?"
Aug 14 2013
prev sibling next sibling parent "w0rp" <devw0rp gmail.com> writes:
On Wednesday, 14 August 2013 at 18:18:32 UTC, Dmitry Olshansky 
wrote:
 In D:
 alias f = _ + _;

In addition to being a D fan, I am also a Scala fan, and I use the magic underscore syntax in Scala now and again. While it can sometimes be useful, I don't feel like it absolutely needs to exist in the language. I would like to argue in favour of gradually replacing the string lambdas which just lambdas. I don't personally see a huge problem in typing (x, y) => x < y. It very clearly expresses your intent, and this is very brief syntax. The underscore syntax only takes away from the expressiveness to reduce line length. As mentioned before, for very common lambdas that you don't want to type yourself, you could define those functions as generic functions with a given name, like a 'less' function.
Aug 14 2013
prev sibling next sibling parent "Brian Rogoff" <brogoff gmail.com> writes:
On Wednesday, 14 August 2013 at 19:24:43 UTC, w0rp wrote:
 As mentioned before, for very common lambdas that you don't 
 want to type yourself, you could define those functions as 
 generic functions with a given name, like a 'less' function.

Also as mentioned before, the issue is that (anonymous) lambda functions have some subtle issues in regards to templates, because lambda functions cannot be compared for equality (the problem in general is undecidable) while string lambdas can, even though they have the same problem as with some of the unwieldy attempts at comparison (AST comparison after normalization and renaming with De Bruijn indices, or whatever), namely that things that are obviously equal aren't seen as such. That's why you want to name functions, so that templates instantiated with the same function are interoperable. It seems to me that the easiest solution for D would be to deprecate string lambdas, and declare that anonymous lambdas always compare to false. Is the workaround of naming lambdas being used in in separate template instantiations that need to work together so bad?
Aug 14 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, August 14, 2013 09:26:20 Andrei Alexandrescu wrote:
 On 8/14/13 7:34 AM, H. S. Teoh wrote:
 That's a bit too terse. What about this:
 less // a < b
 less!(5) // a < 5
 lessEq // a <= b
 lessEq!(5) // a <= 5
 more // a > b
 more!(5) // a > 5
 moreEq // a >= b
 moreEq!(5) // a >= 5
 equal // a == b
 equal!(5) // a == 5
 notEqual // a != b
 notEqual!(5) // a != 5

At this point using "a < b" for a < b, "a < 5" for a < 5 etc. becomes awfully attractive.

I'd simply argue for doing something like binaryOp!"<" and unaryOp!"-". Creating different names for all of the various operators is not at all in line with how do things normally and definitely seems unattractive. In contrast, by creating specific templates for operators, we cover the main use cases where the string lambdas are more attractive than the newer lambda literals. It's also in line with how do operator overloading. - Jonathan M Davis
Aug 14 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 15 August 2013 at 02:30:50 UTC, Jonathan M Davis 
wrote:
 On Wednesday, August 14, 2013 09:26:20 Andrei Alexandrescu 
 wrote:
 On 8/14/13 7:34 AM, H. S. Teoh wrote:
 That's a bit too terse. What about this:
 less // a < b
 less!(5) // a < 5
 lessEq // a <= b
 lessEq!(5) // a <= 5
 more // a > b
 more!(5) // a > 5
 moreEq // a >= b
 moreEq!(5) // a >= 5
 equal // a == b
 equal!(5) // a == 5
 notEqual // a != b
 notEqual!(5) // a != 5

At this point using "a < b" for a < b, "a < 5" for a < 5 etc. becomes awfully attractive.

I'd simply argue for doing something like binaryOp!"<" and unaryOp!"-". Creating different names for all of the various operators is not at all in line with how do things normally and definitely seems unattractive. In contrast, by creating specific templates for operators, we cover the main use cases where the string lambdas are more attractive than the newer lambda literals. It's also in line with how do operator overloading. - Jonathan M Davis

Yes and avoid stupid template duplication like with "a>b" "a > b" or by not having equals delegate literals. This is clearly the best option for simple operations. Complex operation should be migrated to delegate literals.
Aug 14 2013
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Aug 15, 2013 at 07:13:18AM +0200, deadalnix wrote:
 On Thursday, 15 August 2013 at 02:30:50 UTC, Jonathan M Davis wrote:
On Wednesday, August 14, 2013 09:26:20 Andrei Alexandrescu wrote:
On 8/14/13 7:34 AM, H. S. Teoh wrote:
 That's a bit too terse. What about this:
 less // a < b
 less!(5) // a < 5
 lessEq // a <= b
 lessEq!(5) // a <= 5
 more // a > b
 more!(5) // a > 5
 moreEq // a >= b
 moreEq!(5) // a >= 5
 equal // a == b
 equal!(5) // a == 5
 notEqual // a != b
 notEqual!(5) // a != 5

At this point using "a < b" for a < b, "a < 5" for a < 5 etc. becomes awfully attractive.

I'd simply argue for doing something like binaryOp!"<" and unaryOp!"-". Creating different names for all of the various operators is not at all in line with how do things normally and definitely seems unattractive. In contrast, by creating specific templates for operators, we cover the main use cases where the string lambdas are more attractive than the newer lambda literals. It's also in line with how do operator overloading.


That's a good idea: unaryOp!"-" // -a binaryOp!"-" // a-b binaryOp!("-", 5) // a-5 binaryOp!"<" // a<b binaryOp!("<", 5) // a<5 [...]
 Yes and avoid stupid template duplication like with "a>b" "a > b" or
 by not having equals delegate literals.

+1
 This is clearly the best option for simple operations. Complex
 operation should be migrated to delegate literals.

+1. T -- "Hi." "'Lo."
Aug 15 2013