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

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.

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?

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

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.

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