Towards Minimal L World

[Maurizio Cimadamore]

This seems a very promising direction; as Dan points out, one of the 
sore points of previous 'minimal VT' effort was lack of compiler 
support; this guarantees more or less same features, but with some 
compiler support sprinkled on top.

While I think going down into a syntactic bikeshed right now would be 
way too premature, IMHO, one thing that the language has to figure out 
is how the construction model for value types is exposed to programmers. 
Withers are very good at the bytecode level, not so much at the source 
level. Whatever we can do to minimize the entry barrier there I think 
would be very welcome.

Maurizio


On 16/05/18 23:45, Brian Goetz wrote:
> Putting my project management hat on ….
>
> LWorld started out as a bold — and risky — experiment; could we throw away the information of what is a value and what is not from our type signatures, and reconstruct it sufficiently to not pollute performance?  And it seems the results are quite promising — so we would like to get more experience with it beyond writing toy examples and micro benchmarks.  So its probably getting to be time to publish (as an EA) some sort of “Minimal L World”.
>
> This list has been full of claims of the from “we don’t need X”, “we must have Y”, “we should have Z”.  I claim that all of these claims are type errors — because they are missing the temporal clause that qualifies _when_ we might or might not need them.  Let’s put some temporal structure on this, so we can rectify these transgressions.
>
> Let’s start with three milestones.
>
> LW1.  This is the most minimal L-world implementation we could credibly publish.  I would like to suggest we make this really minimal (more on this below), so we can get something into the hands of those that provide us useful feedback.  Even a truly minimal version might be useful for machine learning (lots of data, mostly in arrays, no migration, no generics), algorithm design (such as squeezing indirections out of HAMT-based data structures), etc.
>
> I’ll leave some room between this and ...
>
> LW10.  This would be the least we could actually ship as a product.  This would need to support, for example, erased generics over values, but wouldn’t have specialized generics, yet.
>
> And more room between this and …
>
> LW100.  This is having achieved, well, Valhalla.  Full optimization, specialized generics, migration support, you name it.
>
>
> OK, so how minimal is LW1?  Well, I say really minimal:
>   - User-definable value classes in javac, with a crappy ad-hoc syntax
>   - Reasonable flattening and scalarization of values
>   - No support for migration of VBCs to VCs
>   - No support for any interaction between values and generics _whatsoever_ (I said minimal!)
>
> Even with these restrictions, I think we can call this good enough to be LW1, because it is still useful to the folks who are going to put it through its paces and give us feedback.  Sure, broad users will not be interested, but that’s fine.
>
> We can then proceed to identify what are the sensible candidates for LWn (n < 10), and in what order.
>
>