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

[Ron Pressler]

Exactly. I think this proposal packs a lot of bang for very little buck :)

Ron Pressler
paralleluniverse.co
@puniverseco <https://twitter.com/puniverseco> on Twitter

On Wed, Apr 22, 2015 at 4:06 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> 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
>> >>
>>
>>
>