__WhereRef/WhereVal peeling, #ifdef and related proposals

[Thomas W]

Hi Palo, people

My suggestion was really to avoid #ifdef and case(single Tvar) suggestions,
and move the discussion to encompass multi-dimensional space; ie more than
one Tvar. Logically at the highest level, however, I feel "portable code"
that specializes correctly across domains would be better still.

> it does not handle "optional" methods that should be available in just
some specializations

Good point. However, one fundamental I want to raise --

I don't feel that capabilities (questions/ or verbs) can correctly vary
between different specializations of the same class. To me, a _class_ as
written in one .java file should be the product of "logical algorithm" and
a "degree of type knowledge". Capabilities -- and abstractness -- should
logically be symmetrical between different specializations of such a class.

I see variance in methods, only as a technical issue -- to avoid signature
collisions & adapt APIs for optionality -- and I do not believe variance
should exist in logical capabilities. I discussed this with Brian and feel
the above paragraph to be loosely a proof.

> - (big one) - supporting manual specialization on the level of code
blocks within the function will make process of method specialization in
JVM much more complicated.

It's a tree walk & one matching rule.  Generally I'd prefer portable code
that specialized to all domains, over any "manual coding" approach;  that's
why I proposed EQ.  However if we really were going to manually specialize,
reuse of most code (with small type-switched blocks) would avoid repeating
structurally similar method bodies with only slight adaptations.

However, the sense I get is that this is all "just prototypical" to enable
us to proceed with experimentation.

Probably my hope & preference is, that we have *no* such manual code
specialization features -- maybe just method switching, to get around the
signature collisions. Here's what I'd actually want to see:
- portable code across specialization domains;  eg. equals, hashCode,
default, etc
- no manual specialization at all
- methods need some kind of switching/ annotation/ layering to avoid
collisions and adapt APIs for optionality.
- write your own class (BitList implements List<boolean>) if you want to
pack boolean into bits;   that's what we have classes for.

So at a conceptual level, not a syntax level, that's really my preferred
outcome. Just one ArrayList.java code body that specializes cleanly,
elegantly & correctly to any required domain.


Regards,
Thomas