__WhereRef/WhereVal peeling, #ifdef and related experiments

[Maurizio Cimadamore]

On 19/01/15 01:27, Thomas W wrote:
> I'm having difficulty Googling an exact definition for "meet rule" -- if
> you want to email a definition privately, I'd appreciate -- but apart from
> most-specific L-to-R order of precedence, no such rule would be needed.
What Brian means by 'meet rule' is, at its heart, a rule that prevents 
you from defining ambiguous specializations - think of the following 
case (using existing syntax):

class Pair<any X, any Y> {
     void someOperation() {
         __WhereRef(X) { /* ref X implementation */ }
         __WhereVal(Y) { /* val Y implementation */ }
         __WhereVal(X) __WhereRef(X) { /* val x, ref Y implementation */ }
     }
}

Now, let's say you have something like this:

Pair<String, int> psi = new Pair<String, int>();

How should the body of 'someOperation' be specialized? Should it match 
the first 'ref X' block, or the second 'val Y' block? We think this 
should be an hard compile-time error - in fact, the current compiler 
already gives you two kinds of errors when writing peeled methods:

* errors for ambiguous specializations (i.e. where two or more blocks 
match a given type-parameterization)
* errors for missing specializations (i.e. if a given parameterization 
has _no_ matching where blocks).

So, I hope you can appreciate that, despite this being essentially an 
hack, is also quite far from being a postprocessor-like feature; the 
compiler has full knowledge of such blocks and is able to reason about 
them in order to prove properties about the programs you are typing. Of 
course, eventually, all this will have to be leveraged in a more 
readable, Java-like way.

Maurizio