Species-static members vs singletons

[Peter Levart]

Hi Brian,

I agree that "species" placement is a better, less verbose option. But 
how to solve the language problem of having "species" and "instance" 
members of the same "type-variable" type be assignable to one-another? 
For example:

class Foo<any T> {
     species T st;
     T it;

     void m() {
         it = st; // this can not be allowed
         st = it; // this can be allowed

         // maybe this could be allowed?
         @SuppressWarnings("unchecked")
         it = (T) st;
     }


Singleton abstraction has the same problem.

So while technically possible, it would be weird to have 'T' sometimes 
not be assignable to 'T'. Can we live with that?

Regards, Peter

On 05/19/2016 04:36 PM, Brian Goetz wrote:
> We discussed two primary means to surface species-specific members in 
> the language: a "species" placement (name TBD) as distinct from static 
> and instance, or a "singleton" abstraction (a la Scala's "object" 
> abstraction, as Peter L suggested).  We've done some experiments 
> comparing the two approaches.
>
> Separately, we discussed two strategies for handling this at the VM 
> level: having three separate placements (ACC_STATIC, ACC_SPECIES, and 
> instance) or retconning ACC_STATIC to mean "species" and using 
> compiler trickery to simulate traditional statics.  In recent 
> discussions with Oracle and IBM VM folks, they seemed happy enough 
> with having a new placement (and possibly new bytecodes, 
> {get,put,invoke}species, or overloading these onto *static with 
> ParamTypes in the owner field of the various XxxRef constants.)
>
>
> There are several places where the language itself can take advantage 
> of species members:
>
> 1.  Reifying type variables.  For an any-generic class Foo<T,U>, the 
> compiler can generate public static final reflection-thingie-valued 
> fields called "T" and "U", which means that "aFoo.T" (as an ordinary 
> field ref!) would evaluate to the reflective mirror for the reified T 
> -- if present, otherwise it would evaluate to the reflective mirror 
> for 'erased'.
>
> 2.  Representation of generic methods.  The current translation 
> strategy has us translating any-generic methods to classes; a static 
> method
>
>     static<any T> void foo(T t) { }
>
> translates to a class (plus an erased bridge):
>
>     bridge static foo(Object o) { ... invoke erased specialization ... }
>
>     static class Xxx$foo<any T> {
>         void foo(T t) { ... }
>     }
>
> This means that an instance of Xxx$foo is needed to invoke the method 
> -- but serves solely to carry the type variables -- which is 
> unfortunate.  If instead we translate as:
>
>     static class Xxx$foo<any T> {
> *species-static *void foo(T t) { ... }
>     }
>
> then we can invoke this method via invokespecies:
>
>     invokespecies ParamType[Xxx$foo, T_inf].foo(T_inf)
>
> where T_inf is the erasure-normalized type inferred for T (reified if 
> value, `erased` reference.)  No fake receiver required.
>
> The translation for generic instance methods is still somewhat messier 
> (will post separately), but still less messy than if we also had to 
> manage / cache a receiver.
>
>
> We also drafted some examples of how such a facility would be used, 
> writing them both with species-static and with singleton.  Examples 
> and notes below; the summary is that in all cases, the species-static 
> version is either better or about as good.
>
>
>
> 1.  The old favorite, caching an instantiated instance.
>
> Species
> 	Singleton
> class Collections {
>     private static class Holder<any T> {
>         private species List<T> empty = new EmptyList<T>();
>     }
>
>     static<any T> List<T> emptyList() { return Holder<T>.empty; }
> }
> 	class Collections {
>     private singleton Holder<any T> {
>         private empty = new EmptyList<T>();
>     }
>
>     static<any T> List<T> emptyList() { return Holder<T>.empty; }
> }
>
>
> Note that in this case, species by itself isn't enough -- we still 
> need a holder class, and its a bit ugly.  Arguably we could merge 
> Holder into EmptyList (if that's under our control) but because 
> Collections is an old-style "static bag" class (aka "sin bin"), we 
> would still need a holder class for state.  (Collections could share a 
> single holder for multiple things; empty list, empty set, etc.)
>
> Neither the left nor the right seems particularly better than the 
> other here.  (If we were putting this method on Collection, where it 
> would likely go in new code since now interfaces can have statics, the 
> species approach would win, since we'd not need the holder class any 
> more.)
>
>
> 2.  Instantiation tracking.
>
> Species
> 	Singleton
> class Foo<any T> {
>     private species int count;
>     private species List<Foo<T>> foos;
>
>     public Foo() {
>         ++count;
>         foos.add(this);
>     }
> }
> 	class Foo<any T> {
>     private singleton FooStuff<T> {
>         private int count;
>         private List<Foo<T>> foos;
>     }
>
>     public Foo() {
>         ++Foo<T>.count;
>         Foo<T>.foos.add(this);
>     }
> }
>
>
> Because the state is directly tied to the instantiation, the left 
> seems more attractive -- doesn't require an extra artifact, and the 
> constructor body seems more straightforward.
>
>
> 3.  Implicit-like associations.  Here, we're caching type 
> associations.  For example, suppose we have a Box<T>, and we want to 
> cache the associated class for List<T>.
>
>
> Species
> 	Singleton
> class Box<any T> {
>     private species Class<List<T>> listClass
>         = Class.forSpecialization(List, T.crass);
> }
> 	class Box<any T> {
>     private singleton ListBuddy<any T> {
>         Class<List<T>> clazz
>             = Class.forSpecialization(List, T.crass);
>     }
> }
>
>
> The extra singleton declaration feels like "noise" here, because again 
> the association is with the full set of type args for the class.
>
>
> 4.  Static factories.  Arguably, it makes sense to move factories to 
> the types they describe.
>
> Species
> 	Singleton
> interface List<any T> {
>     private species List<T> empty = new EmptyList<>();
>     species List<T> emptyList() { return empty; }
> }
> 	interface List<any T> {
>     private singleton Stuff<any T> {
>         List<T> empty = new EmptyList<>();
>     }
>     species List<T> emptyList() { return Stuff<T>.empty; }
> }
>
>
> In this model, you'd get an empty list with
>
>     List<T> aList = List<T>.empty()
> rather than
> List<T> aList = Collections.<T>empty();
>
> In the latter, the type witnesses can be omitted; in the former they 
> probably can be as well but that's something new.
>
>
> 5.  Typevar shredding.  Here, we have separate state for different 
> subsets of variables.  This should be the place where the singleton 
> approach shines.
>
>
> Species
> 	Singleton
> class HashMap<any K, any V> {
>     private static class Keys<any K> {
>         species Set<K> allKeys = ...
>     }
>
>     private static class Vals<any V> {
> species Set<V> allVals = ...
>     }
>
>     void put(K k, V v) {
>         Keys<K>.allKeys.add(k);
> Vals<V>.allVals.add(v);
>     }
> }
> 	class HashMap<any K, any V> {
>     private singleton Keys<any K> {
>         Set<K> allKeys = ...
>     }
>
>     private singleton Vals<any V> {
> Set<V> allVals = ...
>     }
>
>     void put(K k, V v) {
>         Keys<K>.allKeys.add(k);
> Vals<V>.allVals.add(v);
>     }
> }
>
>
>
> But, it doesn't really shine that much; the left is not really much 
> worse than the right, just a little more fussy.
>
> In cases where the singleton approach is more natural, the 
> corresponding "species in static class" idiom isn't so bad either.  
> But in cases where the species approach is more natural, there's 
> something unappealing about creating classes (both in source and 
> runtime footprint) in cases 2/3/4 when we don't need one. The only 
> place where the singleton approach seems to win big is when there are 
> multiple variables in the same scope bound by invariants -- here, the 
> singleton having a ctor is a big win -- but how often does this happen?
>
>
> So our conclusion is that the species-placement is as good or better 
> for the identified use cases -- and it also fits cleanly into the 
> existing model for member placement.