A special, built-in value type: a 64-bit "fixnum"

[Brian Goetz]

I suspect Ron was trying to propose something that was simple enough that it might actually happen.  General solutions are pretty but often prohibitive; Ron is trying to find a sweet spot that is actually useful for something and yet simple enough that it might be possible.  

On Apr 22, 2015, at 3:04 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:

> Right ok.  At this point, why not support union types then, which could be more generally useful? Also dynamic languages that support fixnum to bignum overflow tend to do that in the language, not library I think - would this type then provide standard arithmetic operators? Or it's just a discriminated container and overflow detection is up to caller?
> 
> sent from my phone
> 
> On Apr 22, 2015 8:47 AM, "Brian Goetz" <brian.goetz at oracle.com> wrote:
> This would be the basis for an “Any”-like type.  Dynamic languages use the “primitive or reference” trick all the time.  If you have a number, if it’s small, you’d like to represent it as an int, but if it overflows, you need to overflow to an object.  Implementations tend to resort to having an array of primitives and an array of refs, and for each index, use one or the other (generally if the ref is null, use the primitive.)
> 
> On Apr 22, 2015, at 2:41 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> 
> > Can you provide a somewhat concrete example where this would be useful?
> >
> > sent from my phone
> > On Apr 22, 2015 7:12 AM, "Ron Pressler" <ron at paralleluniverse.co> wrote:
> >
> >> Hi.
> >> I'd like to propose that the Valhalla project include a single special,
> >> built-in value type: a 64-bit "fixnum". The value has a single bit
> >> discriminating between a reference or a 63-bit long. It will, of course, be
> >> treated correctly by the GC.
> >>
> >> For completeness, a couple of static helper functions may be introduced.
> >> One that takes a long and, preserving the sign, truncates it to 63 bits,
> >> throwing an exception in the case of an overflow, and the other taking a
> >> double and truncating down to 63 bits, truncating precision by one bit (and
> >> another for the reverse 63-bit double -> double operation).
> >>
> >> I believe this will be immensely useful for some applications that
> >> currently require two separate arrays to store a value of either a
> >> primitive or a reference, yet would require minimal work for GC support. Of
> >> course, this proposal can be extended to directly support any 63-bit (or
> >> smaller) value type, but even in its minimal form it is extremely useful.
> >>
> >> Ron
> >>
>