Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #7806

Re: new Java lambda syntax

From Steven Simpson <ss@domain.invalid>
Newsgroups comp.lang.java.programmer
Subject Re: new Java lambda syntax
Date 2011-09-11 17:18 +0100
Organization Aioe.org NNTP Server
Message-ID <9j3vj8-aqe.ln1@news.simpsonst.f2s.com> (permalink)
References <j4b80q$u30$1@dont-email.me> <alpine.DEB.2.00.1109101445260.18967@urchin.earth.li> <llbsj8-b59.ln1@news.simpsonst.f2s.com> <alpine.DEB.2.00.1109111255530.13018@urchin.earth.li>

Show all headers | View raw


On 11/09/11 13:06, Tom Anderson wrote:
> On Sat, 10 Sep 2011, Steven Simpson wrote:
>>   * 'effectively final' - A non-final local variable can be immutably
>>     captured by a lambda, so long as it's shown not to be assigned to
>>     subsequently.
>
> Seems sensible. I would have been happy with a requirement for 
> explicit finality, but i recognise that many people would have been 
> annoyed by it, and i don't think this introduces any danger. Any idea 
> how hard it is for the compiler to prove that the variable cannot be 
> modified?

Hmm, it's more strict than I thought (but easier to compile).  It seems 
you have to be able to add final to the variable declaration.  This 
compiles fine:

     void func() {
         int i = 0;

         Runnable action = () ->  { System.out.println(i); };
     }

...but any assignment to 'i', before or after creating 'action', 
prevents 'i' from being effectively final.

Hardly a disaster.  :-)

>>   * 'long this' - In the body of a lambda, 'this' has the same meaning
>>     as it would in the enclosing scope.  It does not refer to the
>>     object that ultimately fulfils the lambda.
>
> Also seems sensible. Are there any cases where you would want to refer 
> to the lambda object itself? I'm sure people will come up with them 
> once lambdas come into use. Will there be any way to get hold of such 
> a reference?

Some corner cases came up, along with some work-arounds.  They were 
probably recursive.  I think assignment rules were altered slightly so 
that a lambda body could refer to itself:

   Runnable x = () ->  { x.run(); };

It was deemed okay to allow this because you can be certain that x will 
be ready before it is run.

>>   * 'throws T' - A set of exceptions can be expressed as a generic
>>     type parameter, so they can be relayed from the lambda's signature
>>     to the signature of the method that calls it.
>
> Oh, cool.

Yes, except I'm not sure how useful it will be in practice with 
concurrent APIs.  With a serial contract, like a library version of the 
for-each loop, it's clearly useful:

   interface Block<E, throws T>  {
     void apply(E val) throws T;
   }
  
   static<E, throws T>  void forEach(Iterable<E>  coll, Block<E, T>  block) throws T {
     for (Iterator<E>  iter = coll.iterator(); iter.hasNext(); ) {
       E elem = iter.next();
       block.apply(elem);
     }
   }

Now the forEach method can generically throw the same set of exceptions 
T that the block itself can throw.

But if there is no serial guarantee on invoking the block, you have to 
choose whether you return arbitrarily just the first exception thrown, 
or pack them into some structure, or something else.  I've a feeling 
that, most of the time, such methods will require the SAM type to throw 
nothing, so <throws T> won't get used.

>> It could be argued that these restrictions seem to reduce lambdas to 
>> just a shorter syntax for certain anonymous inner classes.  However, 
>> I think there's an aspiration to implement them more cheaply than 
>> normal objects.
>
> I'd be happy with them actually being syntactic sugar for anonymous 
> classes (i am quite unsophisticated my tastes!). The VM boffins could 
> then focus on making anonymous classes cheaper in general.

I think they don't foresee such savings for anon classes generally, 
because they potentially have fields and multiple user-defined methods.  
When you're certain such complexities don't exist, which is the case for 
lambdas, certain optimizations become possible.

>> There are no automatically generated families of function types 
>> (yet), so you have to rely on SAM (single abstract method) types.  
>> Lambdas are just a syntactic construct until you've expressed or 
>> implied the SAM type, with an assignment, initialization or a cast.
>
> Oh, wait, what? Wow. There's no function type? So you can *only* use 
> lambdas as SAMs? Have i understood that correctly? That's kinky.

You seem disturbingly excited by that!  :-)  Here are some arguments 
about it (not necessarily mine):

    * Function types would introduce a form of structural typing, which
      is a little alien to Java.  We saw a thread here just a few days
      ago ("simple method to simulate function pointers in java"), where
      someone was hand-crafting generic function types, and some of the
      advice was just to define interfaces per situation, partly because
      it documents better, and partly because it's more idiomatic for Java.
    * Function types could be added in such a way that they would be SAM
      types, so if you can get lambdas to work with SAM types (which
      you'd probably have to do anyway to take advantage of old APIs),
      they should automatically work with function types added later.
    * A limited number of generic SAM types are being defined to extend
      the Collections API.  They will probably serve as well as function
      types in the most common cases.
    * If a lambda is always typed as a SAM, how you invoke it is settled
      - it's the name of the SAM's method, of course.  I recall seeing
      proposals where you could write obj(args), or obj.(args), or
      obj.invoke(args), where obj was a function type.  Leave it as a
      SAM, and you don't have to make a decision about that.


> You say 'yet' - can we expect function types before it's finished?

IIRC, no plans for Java 8 - back burner, I think.  ISTR some 
difficulties arose, so maybe they decided they needed more time for 
something deemed not essential.

-- 
ss at comp dot lancs dot ac dot uk

Back to comp.lang.java.programmer | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

new Java lambda syntax markspace <-@.> - 2011-09-08 13:19 -0700
  Re: new Java lambda syntax Roedy Green <see_website@mindprod.com.invalid> - 2011-09-08 15:18 -0700
    Re: new Java lambda syntax Arne Vajhøj <arne@vajhoej.dk> - 2011-09-08 18:27 -0400
    Re: new Java lambda syntax BGB <cr88192@hotmail.com> - 2011-09-08 15:40 -0700
      Re: new Java lambda syntax Arne Vajhøj <arne@vajhoej.dk> - 2011-09-08 19:27 -0400
        Re: new Java lambda syntax BGB <cr88192@hotmail.com> - 2011-09-08 16:29 -0700
          Re: new Java lambda syntax Arne Vajhøj <arne@vajhoej.dk> - 2011-09-08 19:48 -0400
          Re: new Java lambda syntax Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-09-08 17:56 -0700
            Re: new Java lambda syntax BGB <cr88192@hotmail.com> - 2011-09-08 22:23 -0700
    Re: new Java lambda syntax "Nasser M. Abbasi" <nma@12000.org> - 2011-09-08 16:41 -0700
    Re: new Java lambda syntax Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-09-08 20:50 -0500
  Re: new Java lambda syntax bugbear <bugbear@trim_papermule.co.uk_trim> - 2011-09-09 09:33 +0100
  Re: new Java lambda syntax Tom Anderson <twic@urchin.earth.li> - 2011-09-10 14:48 +0100
    Re: new Java lambda syntax Steven Simpson <ss@domain.invalid> - 2011-09-10 16:17 +0100
      Re: new Java lambda syntax Tom Anderson <twic@urchin.earth.li> - 2011-09-11 13:06 +0100
        Re: new Java lambda syntax Steven Simpson <ss@domain.invalid> - 2011-09-11 17:18 +0100
          Re: new Java lambda syntax BGB <cr88192@hotmail.com> - 2011-09-11 11:08 -0700
            Re: new Java lambda syntax Steven Simpson <ss@domain.invalid> - 2011-09-11 20:14 +0100
              Re: new Java lambda syntax BGB <cr88192@hotmail.com> - 2011-09-11 14:08 -0700
              Re: new Java lambda syntax Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-09-11 17:07 -0500
                Re: new Java lambda syntax BGB <cr88192@hotmail.com> - 2011-09-11 16:18 -0700
                Re: new Java lambda syntax Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-09-13 02:00 +0200
                Re: new Java lambda syntax Arne Vajhøj <arne@vajhoej.dk> - 2011-09-12 20:59 -0400
                Re: new Java lambda syntax Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-09-12 21:24 -0500
                Re: new Java lambda syntax Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-09-13 21:04 +0200
                Re: new Java lambda syntax Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-09-13 15:22 -0500
                Re: new Java lambda syntax Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-09-13 23:25 +0200
                Re: new Java lambda syntax Tom Anderson <twic@urchin.earth.li> - 2011-09-13 21:29 +0100
                Re: new Java lambda syntax Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-09-13 23:26 +0200
                Re: new Java lambda syntax supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-09-13 20:25 -0400
                Re: new Java lambda syntax Tom Anderson <twic@urchin.earth.li> - 2011-09-15 21:58 +0100
                Re: new Java lambda syntax Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-09-13 21:36 -0500
                Re: new Java lambda syntax supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-09-13 22:49 -0400
                Re: new Java lambda syntax "supercalifragilisticexpialadiamaticonormalizeringelimatisticantations" <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-09-14 02:49 -0400
                Re: new Java lambda syntax supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-09-14 03:01 -0400
                Re: new Java lambda syntax "winkleMeister" <..00@00.00.00.1> - 2011-09-14 09:59 +0000
                Re: new Java lambda syntax supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-09-15 10:16 -0400
                Re: new Java lambda syntax supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-09-14 06:40 -0400
                Re: new Java lambda syntax supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-09-15 10:16 -0400
                Re: new Java lambda syntax lightworker <etts@0n.org.null> - 2011-09-16 01:57 +0000
                Re: new Java lambda syntax thoolen <th00len@th0lenbot.thorium> - 2011-09-15 22:41 -0400
                Re: new Java lambda syntax Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-09-14 06:29 -0300
                Re: new Java lambda syntax BGB <cr88192@hotmail.com> - 2011-09-14 07:40 -0700
                Re: new Java lambda syntax Lew <lewbloch@gmail.com> - 2011-09-14 08:01 -0700
                Re: new Java lambda syntax BGB <cr88192@hotmail.com> - 2011-09-14 14:50 -0700
                Re: new Java lambda syntax Lew <lewbloch@gmail.com> - 2011-09-14 18:02 -0700
                Re: new Java lambda syntax BGB <cr88192@hotmail.com> - 2011-09-14 21:08 -0700

csiph-web