<div dir="ltr">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)<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 14, 2020 at 1:54 PM Sebastian Graf <<a href="mailto:sgraf1337@gmail.com" target="_blank">sgraf1337@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.</div><div>That's also the reason why <a href="https://gitlab.haskell.org/ghc/ghc/-/blob/0fc1cb54d1afc0f002deb4d080c9b824f423b647/compiler/GHC/CoreToStg.hs#L380-383" target="_blank">we lower `LitRubbish` (which we use for absent BoxedRep literals) as `()` when going to STG</a> -- We can't use NULL, so supply an arbitrary (untyped!) closure that we know can be followed by the GC.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Mi., 14. Okt. 2020 um 13:46 Uhr schrieb Spiwack, Arnaud <<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I may have misunderstood, but my understanding is the following:<br></div><div><br></div><div>- Since a is a boxed type, it can never be the null pointer</div><div>- So I can use a null pointer unambiguously</div><div><br></div><div>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.<br></div><div><br></div><div>/Arnaud<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 13, 2020 at 11:47 PM David Feuer <<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">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<div dir="auto"><br></div><div dir="auto"> newtype TMVar a = TMVar (TVar (Maybe a))</div><div dir="auto"><br></div><div dir="auto">We don't, however, actually use the fact that (Maybe a) is lifted. So we could represent this much more efficiently using something like</div><div dir="auto"><br></div><div dir="auto"><span style="font-family:sans-serif"> newtype TMVar a = TMVar (TVar a)</span><br></div><div dir="auto"><span style="font-family:sans-serif"><br></span></div><div dir="auto"><span style="font-family:sans-serif">where Nothing is represented by a distinguished "null" pointer.</span></div><div dir="auto"><span style="font-family:sans-serif"><br></span></div><div dir="auto"><font face="sans-serif">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.</font></div><div dir="auto"><font face="sans-serif"><br></font></div><div dir="auto"><font face="sans-serif">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.</font></div><div dir="auto"><font face="sans-serif"><br></font></div><div dir="auto"><font face="sans-serif">Anyone have thoughts on details for what the Levity constructor arguments might look like?</font></div></div>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>
</blockquote></div>