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
>

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.

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

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

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

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?

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

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

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
op!"<"
> 	less!(5)	// a < 5
op!"<"(5)

etc.

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
>>
> op!"<"
>
>>         less!(5)        // a < 5
>>
> op!"<"(5)
>
> etc.
>