<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head><body bgcolor="#FFFFFF" text="#000000">From a implementors
perspective my main questions would be:<br>
<br>
* How big is the benefit in practice? How many use cases are there?<br>
* How bad are the costs? (Runtime overhead, rts complexity, ...)<br>
<br>
The details of how this would be exposed to a user would are important.<br>
But if the costs are too high for the drawbacks then it becomes a moot
point.<br>
<br>
<span>David Feuer schrieb am 14.10.2020 um 22:21:</span><br>
<blockquote type="cite"
cite="mid:CAMgWh9sUsM1kMCUHJ+wAtzxqEKzHEEgmP7MFB27e7T_TVve_rg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<div dir="auto">Forwarded from Andrew Martin below. I think we want
more than just Maybe (more than one null), but the nesting I described
is certainly more convenience than necessity.</div>
<br>
<div class="gmail_quote"><div dir="ltr" class="gmail_attr">----------
Forwarded message ---------<br>From: <strong class="gmail_sendername"
dir="auto">Andrew Martin</strong> <span dir="auto"><<a
href="mailto:andrew.thaddeus@gmail.com" moz-do-not-send="true">andrew.thaddeus@gmail.com</a>></span><br>Date:
Wed, Oct 14, 2020, 4:14 PM<br>Subject: Re: Restricted sums in BoxedRep<br>To:
David Feuer <<a href="mailto:david.feuer@gmail.com"
moz-do-not-send="true">david.feuer@gmail.com</a>><br></div><br><br><div
dir="ltr"><div>You'll have to forward this to the ghc-devs list to
share it with others since I'm not currently subscribed to it, but I've
had this same thought before. It is discussed at <a
href="https://github.com/andrewthad/impure-containers/issues/12"
target="_blank" rel="noreferrer" moz-do-not-send="true">https://github.com/andrewthad/impure-containers/issues/12</a>.
Here's the relevant excerpt:</div><blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"><div><p>Relatedly, I was thinking the
other day that after finishing implementing <a
href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0203-pointer-rep.rst"
target="_blank" rel="noreferrer" moz-do-not-send="true">https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0203-pointer-rep.rst</a>,
I should really look at seeing if it's possible to add this
maybe-of-a-lifted value trick straight to GHC. I think that with:</p>
<pre><code>data RuntimpRep
= BoxedRep Levity
| MaybeBoxedRep Levity
| IntRep
| ...
data BuiltinMaybe :: forall (v :: Levity). TYPE v -> TYPE ('MaybeBoxedRep v)
</code></pre>
<p>This doesn't have the nesting issues because the kind system prevents
nesting. But anyway, back to the original question. I would recommend
not using <code>Maybe.Unsafe</code> and using <code>unpacked-maybe</code>
instead. The latter is definitely safe, and it only costs an extra
machine word of space in each data constructor it gets used in, and it
doesn't introduce more indirections.</p></div></blockquote></div><br><div
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 13,
2020 at 5:47 PM David Feuer <<a href="mailto:david.feuer@gmail.com"
target="_blank" rel="noreferrer" moz-do-not-send="true">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></blockquote></div><br
clear="all"><br>-- <br><div dir="ltr">-Andrew Thaddeus Martin</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
ghc-devs mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a>
<a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a>
</pre>
</blockquote>
<br>
</body></html>