We're getting off-topic for Jena, but anonymous classes and 'final' boxed
fields such as arrays are defacto closures. In fact, it is perfectively
possible to introduce true closures in Java if you had a way to extend its
syntax (see *). I once had some students do it as an exercise using a Java
DSL syntax extender (they had to use Smalltalk block-syntax though).
Therefore, I didn't think it was difficult to introduce the syntactic
lambas they seem to propose for Java 8. The reason it is a true closure is
that if you box a field, you push the actual value on the heap which
allows you to carry it around for the life-time of the closure object as
well as manipulate it from the outside. That is, btw, how closures are
implemented in several functional languages, i.e. you don't have to do
stack magic to achieve true closures. Now, if they want to maintain some
compatibility with anonymous classes, the syntactic trick I propose won't
be enough. In that case, they would need to rely on the compiler to decide
that a variable needs to be boxed if it is referenced inside an anonymous
class. Perhaps that is how they do it? As for call/cc, if they would use
the mechanism I am laying out here, they would have to capture *all*
scoped variables and box them. But the principle is the same
Definitely off-topic for dev@jena :-)
Simon
*) For the sake of the example:
final MyObject[] myVariable =...
MyClosureType myClosure = new MyClosure() {
public void doSomething() {
System.out.println(myVariable[0]);
}
}
myVariable[0] = ... ;
myClosure.doSomething();
Simon Helsen, Ph.D.
Advisory Software Engineer - Jazz Foundation Server
Phone: 1-519-931-7390 | Mobile: 1-226-973-8118 | Tie-Line: 23157390
E-mail: [email protected]
From:
Andy Seaborne <[email protected]>
To:
[email protected],
Date:
01/21/2013 11:11 AM
Subject:
Re: Java6 end of life
On 21/01/13 10:43, Rob Vesse wrote:
> As the notional representative for .Net developers on this list I kinda
> feel insulted that you wouldn't consider C# which has had lambdas in the
> core language for 5 years now to be a mainstream language! ;-)
>
> I don't think lambdas necessarily require a rethink of the API, often
they
> can be used to great effect to simplify code behind the scenes. Of
course
> it depends how Java goes about adding lambdas, if they do it anything
like
> .Net did then implementing certain interfaces automatically provides end
> users with the ability to apply lambdas with minimal effort on the part
of
> the API developer.
>
> Rob
AIUI Java lambdas do automatically work with "function interfaces" (i.e.
one method interfaces) and remove the bulk of anon inner class
declarations (yea!). I'm still trying to get to grips what effect
default methods will have on style and design.
But they are not closures/delegates are they? While you don't have to
write the word "final" on variables, it still works that way.
Java 9 has reification (not that one!), tail calls and continuations, +
Jigsaw(!!) ... all maybe and all way-off. Jam the day after tomorrow.
C# is still ahead.
(and I wanted generics reification recently to have Sink<Triple> and
Sink<Quad> on the same class ... :-()
Andy
>
>
> On 1/17/13 7:46 PM, "Simon Helsen" <[email protected]> wrote:
>
>> ah yes, lambdas. Never thought I would see the day where I would be
able
>> to use syntactic closures in a mainstream language. I am saying this as
a
>> former functional language developer. (I never considered Smalltalk a
>> mainstream language, but to be fair it used to have blocks). I agree
they
>> would be an opportunity to rethink the API
>>
>> Simon
>>
>>
>>
>>
>> From:
>> Damian Steer <[email protected]>
>> To:
>> [email protected],
>> Date:
>> 01/17/2013 02:37 PM
>> Subject:
>> Re: Java6 end of life
>>
>>
>>
>>
>> On 17 Jan 2013, at 09:37, Andy Seaborne <[email protected]>
>> wrote:
>>
>>> FYI
>>>
>>> Java 6 end-of-life is approaching.
>>>
>>> End of public updates is next month (Feb 2013).
>>> End of public updates for Java7 is currently July 2014.
>>> Java8 is scheduled for Sept 2013 (and feature complete this month)
>>>
>>> Jena 2.10 is the next release.
>>>
>>> Thoughts on migration?
>>
>> We obviously hope people deploy jena on vendor supported java stacks,
but
>> I don't see java 6 use falling rapidly.
>>
>> So are there other reasons to move? There are some reasonable useful
>> language changes, but nothing that compelling. For jena users I imagine
>> try with resources support would be great, and that (annoyingly) would
>> mean a change to 7 on our side (AutoCloseable is jdk 7+).
>>
>> Besides that the new nio stuff, particularly file paths, is great but
not
>> especially relevant to jena.
>>
>> Java 8, otoh, is more significant. Lambdas might provide an opportunity
>> to
>> rethink the API. As I understand it some lambda support might not
require
>> moving to java 8 -- simply accept single method interfaces and
functions
>> will work -- but there's plenty of JDK changes that we might like to
use.
>>
>> Damian
>>
>>
>
