On Thursday, 10 September 2015 at 20:10:49 UTC, Meta wrote:
> How can the compiler tell which $1 and $2 is which? What if one wants to access both the outer $1 and the inner $1 in localMax?

If there is a conflict you should use a regular lambda on the outer one?

On Thursday, 10 September 2015 at 20:51:18 UTC, Adam D. Ruppe wrote:
> The string lambdas Phobos supports basically does this:
>
> `b < a*b`
>
> would work in there. These are falling out of favor with the new syntax in the language, but they are still supported by most the library.

Isn't that a string mixin? Or?

On Thursday, 10 September 2015 at 20:56:58 UTC, Ola Fosheim Grøstad wrote:
> If there is a conflict you should use a regular lambda on the outer one?

You could, but then doesn't that defeat the point a bit? My example was off-the-cuff, but the point is that we already have a fairly concise lambda syntax, and adding a new type will mean that we have 4 different ways of expressing the same lambda function. It's just not really worth it.

On Thursday, 10 September 2015 at 21:03:12 UTC, Meta wrote:
> On Thursday, 10 September 2015 at 20:56:58 UTC, Ola Fosheim Grøstad wrote:
>> If there is a conflict you should use a regular lambda on the outer one?
>
> You could, but then doesn't that defeat the point a bit? My example was off-the-cuff, but the point is that we already have a fairly concise lambda syntax, and adding a new type will mean that we have 4 different ways of expressing the same lambda function. It's just not really worth it.

Yes, it is usually it is a bad idea to have many ways to do things. A numbered schema probably should only be used in an innermost scope as a single expression, so if you see "$1" you know the definition stops at the brackets.

Apropos one way of doing things:

http://www.ozonehouse.com/mark/periodic/

:D

On Thursday, 10 September 2015 at 21:03:12 UTC, Meta wrote:
> On Thursday, 10 September 2015 at 20:56:58 UTC, Ola Fosheim Grøstad wrote:
>> If there is a conflict you should use a regular lambda on the outer one?
>
> You could, but then doesn't that defeat the point a bit? My example was off-the-cuff, but the point is that we already have a fairly concise lambda syntax, and adding a new type will mean that we have 4 different ways of expressing the same lambda function. It's just not really worth it.

Clojure solved this by disallowing nesting lambdas-with-numbered-arguments:


Clojure 1.7.0
user=> (#(+ %1 %2) 1 2)
3
user=> (#(#(+ %1 %2) %2 %1) 1 2)
IllegalStateException Nested #()s are not allowed  clojure.lang.LispReader$FnReader.invoke (LispReader.java:703)
#object[clojure.core$_PLUS_ 0x10fde30a "clojure.core$_PLUS_@10fde30a"]
CompilerException java.lang.RuntimeException: Unable to resolve symbol: %1 in this context, compiling:(NO_SOURCE_PATH:0:0)
CompilerException java.lang.RuntimeException: Unable to resolve symbol: %2 in this context, compiling:(NO_SOURCE_PATH:0:0)
RuntimeException Unmatched delimiter: )  clojure.lang.Util.runtimeException (Util.java:221)
CompilerException java.lang.RuntimeException: Unable to resolve symbol: %2 in this context, compiling:(NO_SOURCE_PATH:0:0)
CompilerException java.lang.RuntimeException: Unable to resolve symbol: %1 in this context, compiling:(NO_SOURCE_PATH:0:0)
RuntimeException Unmatched delimiter: )  clojure.lang.Util.runtimeException (Util.java:221)
1
2
RuntimeException Unmatched delimiter: )  clojure.lang.Util.runtimeException (Util.java:221)


Than again, Clojure never was a big advocate of the one-way-of-doing-things approach...

At any rate, since string lambdas can usually be used in place of this syntax, and in the cases string lambdas can't be used(because you need something from the scope) it's not THAT hard to use proper lambdas - I see no reason to support it.

On Thu, 2015-09-10 at 20:51 +0000, Adam D. Ruppe via Digitalmars-d wrote:
> […]
> 
> The string lambdas Phobos supports basically does this:
> 
> `b < a*b`
> 
> would work in there. These are falling out of favor with the new syntax in the language, but they are still supported by most the library.

And until some bugs get fixed, you have to use string functions in some places, you cannot use proper function literals :-(

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Friday, 11 September 2015 at 08:02:21 UTC, Russel Winder wrote:
> On Thu, 2015-09-10 at 20:51 +0000, Adam D. Ruppe via Digitalmars-d wrote:
>> […]
>> 
>> The string lambdas Phobos supports basically does this:
>> 
>> `b < a*b`
>> 
>> would work in there. These are falling out of favor with the new syntax in the language, but they are still supported by most the library.
>
> And until some bugs get fixed, you have to use string functions in some places, you cannot use proper function literals :-(

Can you elaborate? Are those bugs logged somewhere?

On Fri, 2015-09-11 at 11:32 +0000, ZombineDev via Digitalmars-d wrote:
> On Friday, 11 September 2015 at 08:02:21 UTC, Russel Winder wrote:
> > On Thu, 2015-09-10 at 20:51 +0000, Adam D. Ruppe via Digitalmars-d wrote:
> > > […]
> > > 
> > > The string lambdas Phobos supports basically does this:
> > > 
> > > `b < a*b`
> > > 
> > > would work in there. These are falling out of favor with the new syntax in the language, but they are still supported by most the library.
> > 
> > And until some bugs get fixed, you have to use string functions in some places, you cannot use proper function literals :-(
> 
> Can you elaborate? Are those bugs logged somewhere?

For example https://issues.dlang.org/show_bug.cgi?id=5710

The affects a number of the std.parallelism functions :-(

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On 09/10/2015 08:23 PM, Jonathan M Davis wrote:
>
> That's one of the main reasons that I hate the idea of named arguments.
> It's more stuff that's part of the API, more public stuff that you have
> to name correctly and risk bikeshedding arguments over, and more stuff
> that can you can't change without breaking existing code.
>
> - Jonathan M Davis

Note that parameter names can already be determined by user code using reflection.

On Friday, 11 September 2015 at 11:44:13 UTC, Russel Winder wrote:
> For example https://issues.dlang.org/show_bug.cgi?id=5710

If C++ interop is still important, maybe it would be a good idea to adopt C++ style lambdas.