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.
