Restricted sums in BoxedRep
arnaud.spiwack at tweag.io
Wed Oct 14 11:58:57 UTC 2020
I don't imagine it would be hard for the GC to check that a pointer is null
before following it. The argument may be, though, that it's too high a
price to pay for the occasional use of a null pointer. (I must add that I
have no opinion, or idea really, on this)
On Wed, Oct 14, 2020 at 1:54 PM Sebastian Graf <sgraf1337 at gmail.com> wrote:
> I believe Simon told me once that NULL pointers in places we assume
> BoxedRep things are not an option, because the GC assumes it is free to
> follow that pointer. It won't check if it's NULL or not.
> That's also the reason why we lower `LitRubbish` (which we use for absent
> BoxedRep literals) as `()` when going to STG
> -- We can't use NULL, so supply an arbitrary (untyped!) closure that we
> know can be followed by the GC.
> Am Mi., 14. Okt. 2020 um 13:46 Uhr schrieb Spiwack, Arnaud <
> arnaud.spiwack at tweag.io>:
>> I may have misunderstood, but my understanding is the following:
>> - Since a is a boxed type, it can never be the null pointer
>> - So I can use a null pointer unambiguously
>> Let's call this null-pointer expanded type, `Nullable# a`, it is now a
>> different sort than `a`, since it can have the null pointer in it. Is that
>> still what you wish for? The risk being that combining such a `Nullable# a`
>> with another data structure may very well require an additional boxing,
>> which is what, I believe, you were trying to avoid.
>> On Tue, Oct 13, 2020 at 11:47 PM David Feuer <david.feuer at gmail.com>
>>> Null pointers are widely known to be a lousy language feature in
>>> general, but there are certain situations where they're *really* useful for
>>> compact representation. For example, we define
>>> newtype TMVar a = TMVar (TVar (Maybe a))
>>> We don't, however, actually use the fact that (Maybe a) is lifted. So we
>>> could represent this much more efficiently using something like
>>> newtype TMVar a = TMVar (TVar a)
>>> where Nothing is represented by a distinguished "null" pointer.
>>> While it's possible to implement this sort of thing in user code (with
>>> lots of fuss and care), it's not very nice at all. What I'd really like to
>>> be able to do is represent certain kinds of sums like this natively.
>>> Now that we're getting BoxedRep, I think we can probably make it happen.
>>> The trick is to add a special Levity constructor representing sums of
>>> particular shapes. Specifically, we can represent a type like this if it is
>>> a possibly-nested sum which, when flattened into a single sum, consists of
>>> some number of nullary tuples and at most one Lifted or Unlifted type.
>>> Then we can have (inline) primops to convert between the BoxedRep and the
>>> sum-of-sums representations.
>>> Anyone have thoughts on details for what the Levity constructor
>>> arguments might look like?
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>> ghc-devs mailing list
>> ghc-devs at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs