EG meeting, 2020-12-16

[John Rose]

On Dec 16, 2020, at 11:00 AM, Dan Smith <daniel.smith at oracle.com> wrote:
> 
> Rémi raised some questions about our story for int vs. Integer vs. legacy uses of 'new Integer'—how many implementation classes are there? (should we use species?); what does reflection look like? We agreed it still needs some polishing.

Here’s what I *hope* we can do, if/when we figure out how
to make an abstract class a super of *both* p-class and i-class.

And, then, if/when we figure out how to endow a class with
both p-class factories and i-class constructors.  (See discussion
about Enum, which has a similar problem.)

(Caveat:  I think these are technically feasible but they might
turn out to be too expensive to carry out, compared with other
technical goals.  We might back off to some less elegant solution
with sealed hierarchies and multiple types.  But I can hope.)

At that point we can give jl.Integer both kinds of constructors,
and allow it to instantiate both kinds of instances.  How could
that be possible?  Well, suppose specialization is not a purely
VM-level activity, but (as seems likely) defers partially to a
user-supplied bootstrap method, which decides what’s in any
given species of a class.  Next, suppose that the BSM is given
the choice (for a suitably declared specializable class) to make
species *of both kinds*.  Finally, declare Integer that way, and
make its BSM choose a legacy i-species along some paths, and
a new p-species along the preferred paths.  At least as a formal
possibility, this tactic suggests that the extra degrees of freedom
required could be confined into *one class* (Integer) and
managed using species distinctions.

Being able to do this is clearly not a primary goal of any
reasonable specialization story, but it could turn out to be
low-hanging fruit, if we are lucky.  Hence my hope.

— John