anonymous method call
Remi Forax
forax at univ-mlv.fr
Sun Jun 2 06:33:20 PDT 2013
On 06/02/2013 12:11 AM, Marc Petit-Huguenin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 06/01/2013 12:32 PM, Remi Forax wrote:
>> On 06/01/2013 08:10 PM, Marc Petit-Huguenin wrote: Thanks Brian and Rémi
>> for the response to my previous question.
>>
>> Now that we established my lack of knowledge about the lambda type
>> inference, I have another question, but please note that it is not a
>> suggestion for improvement, merely a question about the limits of what
>> would be possible.
>>
>> A functional interface has only one abstract method, so is there any reason
>> it would not be possible to use an anonymous call to this method?
>>
>> For example:
>>
>> IntUnaryOperator operator = f -> f + 1;
>>
>> and instead of
>>
>> int i = operator.applyAsInt(1);
>>
>> being able to do
>>
>> int i = operator(1);
>>
>>
>> Thanks.
>>
>>> It's possible to implement that but it exhibits a nasty property given
>>> the way Java scope works.
>>> In Java, the scope that contains local variables and the one that
>>> contains method calls are separated, when the compiler see
>>> int i = operator(1);
>>> it knowns that this is a method call, and it will not check if there is a
>>> local variable named 'operator'.
>>> So to support the new syntax and still be able to compile old code, the
>>> compiler has to first check if a method is available and then check if a
>>> local variable exist if no method was found.
>>> This rule is awful because it means that if you add a method in a class
>>> (or worst in a super class) you may broke an already existing code
>>> because you introduce a method that will be used instead of calling the
>>> lambda.
>>> so this syntax was rejected by the Expert Group :)
> It makes sense, thanks.
>
> FYI, I thought of this when trying to adapt the code in
> http://www.righto.com/2009/03/y-combinator-in-arc-and-java.html. The result
> is far simpler than the original code, but I was wondering if there was a way
> to make it even better:
>
> interface HigherOrder<T> extends Function<HigherOrder<T>, T> {}
>
> Function<UnaryOperator<IntUnaryOperator>, IntUnaryOperator> y = r ->
> ((HigherOrder<IntUnaryOperator>)(f -> f.apply(f))).apply(f -> r.apply(x ->
> f.apply(f).applyAsInt(x)));
> IntUnaryOperator factorial = y.apply(f -> n -> n == 0 ? 1 : n * f.applyAsInt(n
> - - 1));
> assert factorial.applyAsInt(10) == 3628800;
> IntUnaryOperator fibonacci = y.apply(f -> n -> n == 0 ? 0 : n == 1 ? 1 :
> f.applyAsInt(n - 1) + f.applyAsInt(n - 2));
> assert fibonacci.applyAsInt(30) == 832040;
Apart from adding a local variable for f -> f.apply(f) to avoid the cast
and make the code a little more readable, I don't think so but maybe I'm
wrong.
Function<UnaryOperator<IntUnaryOperator>, IntUnaryOperator> y = r -> {
HigherOrder<IntUnaryOperator> hop = f -> f.apply(f);
return hop.apply(f -> r.apply(x -> f.apply(f).applyAsInt(x)));
};
IntUnaryOperator factorial =
y.apply(f -> n -> n == 0 ? 1 : n * f.applyAsInt(n - 1));
System.out.println(factorial.applyAsInt(10)); // 3628800;
IntUnaryOperator fibonacci =
y.apply(f -> n -> n == 0 ? 0 : n == 1 ? 1 : f.applyAsInt(n - 1)
+ f.applyAsInt(n - 2));
System.out.println(fibonacci.applyAsInt(30)); // 832040;
cheers,
Rémi
>
> - --
> Marc Petit-Huguenin
> Email: marc at petit-huguenin.org
> Blog: http://blog.marc.petit-huguenin.org
> Profile: http://www.linkedin.com/in/petithug
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iQIcBAEBCAAGBQJRqnGNAAoJECnERZXWan7ELRMP/0/ogTbYxR2QvLOpJVGGruQe
> /vHnZXo6sVFJQ/tUvCrHua4QA9Mhb3CVHNx1180x3h/QLvi1GdwGBg95mUNnslej
> k+Kx8y4mTZEugZaYE2dLVUQqDXV7lEZNB/OHyEoGFf6PqjuKZ1WGrUK5WdgzCYnu
> ctQUeBFouU0zjHo/Im9Pjo2AXYsuc0SaMonGFQhWmbauxZdSG5c074CoEUxxjqCn
> H1uuy+epJuYBI/66Wc4s+DoCR2OhFz9+ilM1yM6CttDm7xxwtHHaQ2wFdfVisOtT
> DdI20dz+aF4ACHLy2IhM1jEUGUZdZyQLSZwPS+EPoFt86BafsDLPtgQwB2KE4wHP
> 4cnyL20PPkIrlnfaG8JHON5+vHxxTIrZ0UjgVXRdpr03scK1eP+OWbHD5J6Ymgp3
> TQXntgh7dagNgscadQUZZvfYPV9MvFR/hRCJS3/pCcUflLLiPUZVZq/uBbzYGjJt
> 9y6NQdaxOKyvrWPwYH6WktPDuNU8pvDQA+TJ5tt2bDW/5P69+2Aibj+YqrnFePyt
> jhHjJdmE3PhmOLXIcDRgCeyelL6MsXCIUspfCXaqeLp7FBBCp4E9aj8QiQjK0WEW
> LcR1xei9j35g6PxKzB7R1fgwm2/B83E4DGlukgXixdNW0i5IYjcdODgxaEIy8Ok1
> iPNnpdebLHZ/Py9Fa/e1
> =tXzk
> -----END PGP SIGNATURE-----
More information about the lambda-dev
mailing list