Reified Lambda Functions

[Howard Lovatt]

Hi Neal,

2010/1/17 Neal Gafter <neal at gafter.com>

> Howard-
>
> I still believe there are fatal errors in your approach.
>

It is not clear to me where you think the errors are, perhaps you
could elaborate.

We could continue to go around and around - counterexample followed by
> new specification again and again - without every having evidence that
> the result is sound.  A lack of counterexamples is not evidence that
> the approach is sound.


The examples you have provided have proved productive in expanding all the
corner cases (thanks), but the fundamentals have not changed. Effectively I
have just applied the same techniques to more situations; which is very
encouraging. If you have more examples that would be useful.


> I think what you need to do is provide a proof
> - or at least show how a proof can be constructed - that demonstrates
> that, using this approach, a variable of function type cannot be made
> to store a reference (or a reference that is the result of one of your
> cast functions) to a lambda that is incompatible with the variable's
> type.


The basic idea is that you can reify a lambda based on compiler knowledge of
what the type is (and there is a runtime check that the compiler is
correct). This doesn't seem to me to be an outrageous idea, the only way it
gets the types wrong are due to *existing* holes in the type system and then
these are caught by an extra runtime check. Were do you feel that an extra
type hole is introduced.


> If such a proof exists, then we can be sure that
> counterexamples don't exist.  If we cannot find such a proof, then the
> approach is probably not suitable for use in a language specification.
>

This seems to be a much higher level of assurance than required from other
proposals for lambdas (or indeed Java in general). Perhaps you have such a
proof for an erased version of lambdas, if so it would be useful if you
could make it public (I did search for a paper but found nothing).

Cheers,

 -- Howard.


>
> Cheers,
> Neal
>
> On Sat, Jan 16, 2010 at 3:02 PM, Howard Lovatt <howard.lovatt at iee.org>
> wrote:
> > Hi Neal,
> > Sorry for taking so long to reply, I was on holiday with limited
> > connectivity.
> > Yes there is a bug in the specification, I have updated section 2.1,
> 4.3.1,
> > 4.3.2, 5.2.2, and 5.3.2 and added sections 4.4 and 5.4 - thanks. (At the
> > same time, but unrelated, I have added section 1.1 and changed the
> > topographical convention used, swapping the roles of _ and $.)
> > With the updated specification the reified lambdas are little different
> than
> > any other example with generics. Contrast:
> >   static <T> List<T>[] makeArrayOfList(final int size) { return
> > (List<T>[])new List[size]; }
> >   static void makeArrayOfStringListTest() {
> >     final List<String>[] arrayOfList = makeArrayOfList(1);
> >     arrayOfList[0] = new ArrayList(1);
> >     arrayOfList[0].add("Hello from a List");
> >     System.out.println("ArrayOfStringList(0) = " +
> arrayOfList[0].get(0));
> >   }
> > With:
> >   static <T> #T()[] makeArrayOfLambda0(final int size) { return
> #T()[size];
> > }
> >   static void makeArrayOfStringLambda0Test() {
> >     final #String()[] arrayOfLambda0 =
> > Examples.<String>makeArrayOfLambda0(1); // I doubt the type inference
> will
> > cope, hence qualification
> >     arrayOfLambda0[0] = #String() ("Hello from a Lambda0");
> >     System.out.println("ArrayOfStringLambda0[0].call() = " +
> > arrayOfLambda0[0].call());
> >   }
> > Which is translated to:
> >   static <T> _Callable_0<? extends T>[] makeArrayOfLambda0(final int
> size) {
> > return (_Callable_0<? extends T>[])new _Callable_0[size]; }
> >   static void makeArrayOfStringLambda0Test() {
> >     final _Callable_String[] arrayOfLambda0 =
> >
> _Array_From_0_String__To_String.instance(Examples.<String>makeArrayOfLambda0(1));
> >     arrayOfLambda0[0] = new _Callable_String() {
> >       @Override public String call() { return "Hello from a Lambda0"; }
> >     };
> >     System.out.println("ArrayOfStringLambda0[0].call() = " +
> > arrayOfLambda0[0].call());
> >   }
> > Thanks again for pointing out the problem,
> >  -- Howard.
> >
> > 2010/1/8 Neal Gafter <neal at gafter.com>
> >>
> >> On Fri, Jan 8, 2010 at 2:19 PM, Howard Lovatt <howard.lovatt at iee.org>
> >> wrote:
> >> > I am not sure what you have in mind, do you have an example I could
> try
> >> > coding up.
> >>
> >> <T> #T()[] makeArray(int size) {
> >>  return new #T()[size];
> >> }
> >>
> >> and a client
> >>
> >> #String()[] array = makeArray(20);
> >>
> >> ______________________________________________________________________
> >> This email has been scanned by the MessageLabs Email Security System.
> >> For more information please visit http://www.messagelabs.com/email
> >> ______________________________________________________________________
> >
> >
> >
> > --
> >  -- Howard.
> >
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>



-- 
 -- Howard.