caution: bleeding-edge ahead!

[Ali Ebrahimi]

Thanks Maurizio for your hard work.
Just one concern for your mentioned limitation (maybe for Now) when having
multiple any type vars.

One note I want mention here is that I see where clauses as conditional
block better and more flexible answer than layers for problems trying
answer.

Why we can not adapt C++'s #if, #elif, #else, and #endif Directives for
java with java-like syntax. You can see that in hotspot code the similar
problems (OS depends-code) perfectly to be solved by Directives.

So we can have support for multiple any type vars and nested layers, and
compiler can do flow analysis for nested layers (where clauses or what ever
you want).

class Foo<any A, any B>{

private A a,
private B b,
//
shared for val and refs
//
#if(A is val){ //A is val
      B[] getBArray(){
             return new B[]{};
       }

      #if(B is ref){//A is val and B is ref

       }#else{//A is val and B is val
              #if(A is int, B is int){ //A is int and B is int
                     int maxAB(){
                         return a > b? a: b;
                     }
              }
        }

}#else { //A is ref
      void some(){

            #if(B is ref){  //A is refand B is ref

             }#else{//A is ref and B is val

             }// #endif

       }
}

//
shared for val and refs
//
}

Consider that Foo<int,double> f = new F(); ,
f.maxAB() does not compile :Error undeclared maxAB member in Foo<int,double>

On Mon, Jan 12, 2015 at 7:47 PM, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Dear honorable warriors,
> I've just pushed a compiler/specializer patch that should add some basic
> support for peeled methods. This is totally experimental (as I mentioned to
> Peter last week), and the support is based on the clunky __WhereRef/Val
> keywords - i.e. it's not an implementation of the layering proposal as
> described in Brian's document, nor is it a serious proposal of how the
> syntax would work ... it's just a hack to move the experiments forward.
> Here's an example on how you might want to peel a method:
>
> class Test<any T> {
>     void peeledMethod() {
>         __WhereRef(T) {
>             //ref implemnetation goes here
>         }
>         __WhereVal(T) {
>             //val implementation goes here
>        }
>     }
> }
>
> The compiler will type-check the two bodies as if they were the 'only'
> body - meaning flow analysis should work as expected (i.e. you can have two
> return statements, one in each body, and the compiler will be happy with
> that). At specialization time, the whole method will be splitted in two
> parts - a real method (for the reference impl) and a 'template method' -
> the class will look like:
>
> class Test<any T> {
>     void peeledMethod() {
>         //ref implemnetation goes here
>     }
>     void template$peeledMethod() {
>         //val implementation goes here
>     }
> }
>
> The two methods will contain special Where bytecode attributes to let the
> specializer reconstruct the specialized classes with the right methods in
> them.
>
> One obvious limitation (I'm sure there are many other I haven't thought
> about) of this implemented, hacky route is that you cannot have a method
> that is part concrete, part abstract; but I think you can emulate that with
> the following idiom:
>
> class Test<any T> {
>     void partiallyAbstractMethod() {
>         __WhereRef(T) {
>             throw new AbstractMethodError();
>         }
>         __WhereVal(T) {
>             //val implementation goes here
>        }
>     }
> }
>
> One last note: the compiler will try to detect situations where multiple
> where blocks might apply on a given specialized class:
>
> class Test<any X, any Y> {
>     void ambiguiousPeeling() {
>         __WhereVal(Y) {
>             //impl1
>         }
>         __WhereRef(X) {
>             //impl2
>        }
>     }
> }
>
> This is flagged as 'ambiguous' - think of what happens if you have i.e. a
> Test<String, int> - both blocks will match - meaning that the specializer
> won't know which to pick. There's also a dual check that prevents a peeling
> method from having 'missing' blocks - i.e. a combination of ref/val
> instantiation which is not matched by any block in the peeled method.
>
> Good luck with the experiments - and please refrain from commenting on the
> specifics of the implemented syntax - we all know it's very, very ugly :-)
> :-) :-)
>
> Cheers
> Maurizio
>



-- 

Best Regards,
Ali Ebrahimi