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

[Palo Marton]

Just a side note to Vitaly - what Ron proposed is not an union of long and
ref. Such union will need 65 bits of storage (ugly number for storage
size). It is union of 63 bit long and ref. So it is not a special case of
union, but different special purpose type.

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

> I know, I'm raising the stakes since if I saw such a thing I'd immediately
> ask why there's no general support for unions, which are more applicable
> than fixnum->bignum promotions :).  Can't you implement such a fixnum with
> having a value type containing both a long and ref? Yes you'd waste some
> space but personally I don't see the value add of supporting a custom
> builtin 2 member union but then not allowing a different 2 type union or N
> union.
>
> Just my $.02.
>
> sent from my phone
> On Apr 22, 2015 9:06 AM, "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
> >> >>
> >>
> >>
> >
>