<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
.ms-cui-menu
{background-color:#ffffff;
border:1px rgb(171,171,171) solid;
font-family:'Segoe UI WPC','Segoe UI',Tahoma,'Microsoft Sans Serif',Verdana,sans-serif;
font-size:11pt;
color:rgb(51,51,51)}
.ms-cui-ctl
{vertical-align:text-top;
text-decoration:none;
color:rgb(51,51,51)}
.ms-cui-ctl-on
{background-color:rgb(229,235,236)}
.ms-cui-img-cont-float
{display:inline-block;
margin-top:2px}
.ms-cui-smenu-inner
{padding-top:0px}
.ms-owa-paste-option-icon
{margin:2px 4px 0px 4px;
vertical-align:sub;
padding-bottom:2px;
display:inline-block}
.ms-rtePasteFlyout-option
{padding:8px 4px 8px 4px;
outline:none}
.ms-cui-menusection
{float:left;
width:85px;
height:24px;
overflow:hidden}
.wf
{speak:none;
font-weight:normal;
font-variant:normal;
text-transform:none;
vertical-align:middle;
display:inline-block}
.wf-family-owa
{font-family:'o365Icons'}
@font-face
{font-family:'o365IconsIE8';
font-weight:normal;
font-style:normal}
@font-face
{font-family:'o365IconsMouse';
font-weight:normal;
font-style:normal}
.wf-family-owa
{font-family:'o365IconsMouse'}
.ie8 .wf-family-owa
{font-family:'o365IconsIE8'}
.ie8 .wf-owa-play-large
{color:#FFFFFF}
.notIE8 .wf-owa-play-large
{border-color:#FFFFFF;
width:1.4em;
height:1.4em;
border-width:.1em;
border-style:solid;
text-align:center;
padding:0.1em;
color:#FFFFFF}
.ie8 .wf-size-play-large
{width:40px;
height:40px;
font-size:30px}
.notIE8 .wf-size-play-large
{width:40px;
height:40px;
font-size:30px}
-->
</style><style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
</head>
<body ocsi="0" fpstyle="1" dir="ltr">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;"><font size="3">One of the things I'm finding difficult about this Phab stuff is that I get presented with lots of code without enough supporting text saying<br>
</font>
<ul>
<li><font size="3">What problem is this patch trying to solve?</font></li><li><font size="3">What is the user-visible design (for language features)?</font></li><li><font size="3">What are the main ideas in the implementation?</font></li></ul>
<p><font size="3">The place we usually put such design documents is on the GHC Trac Wiki. Email is ok for discussion, but the wiki is FAR better for stating clearly the current state of play. Philip, might you make such a page for this unique stuff?</font></p>
<p><br>
</p>
<p><font size="3">To answer some of you specific questions (please include the answers in the wiki page in some form):</font></p>
<ul>
<li><font size="3">Uniques are never put in .hi files (as far as I know). They do not survive a single invocation of GHC.</font></li><li><font size="3">However with ghc --make, or ghci, uniques do survive for the entire invocation of GHC. For example in ghc --make, uniques assigned when compiling module A should not clash with those for module B</font></li><li><font size="3">Yes, TyCons and DataCons must have separate uniques. We often form sets of Names, which contain both TyCons and DataCons. Let's not mess with this.<br>
</font></li><li><font size="3">Having unique-supply-splitting as a pure function is so deeply embedded in GHC that I could not hazard a guess as to how difficult it would be to IO-ify it. Moreover, I would regret doing so because it would force sequentiality where none
is needed.</font></li><li><font size="3">Template Haskell is a completely independent Haskell library. It does not import GHC. If uniques were in their own package, then TH and GHC could share them. Ditto Hoopl.</font></li><li><font size="3">You say that Uniques are serialised as Word32. I'm not sure why they are serialised at all!</font></li><li><font size="3">Enforcing determinacy everywhere is a heavy burden. Instead I suppose that you could run a pass at the end to give everything a more determinate name TidyPgm does this for the name strings, so it would probably be easy to do so for the uniques
too.<br>
</font></li></ul>
<p><font size="3">Simon</font><br>
</p>
<p><br>
</p>
<div style="font-family: Times New Roman; color: #000000; font-size: 16px">
<hr tabindex="-1">
<div style="direction: ltr;" id="divRpF598834"><font size="2" color="#000000" face="Tahoma"><b>From:</b> ghc-devs [ghc-devs-bounces@haskell.org] on behalf of p.k.f.holzenspies@utwente.nl [p.k.f.holzenspies@utwente.nl]<br>
<b>Sent:</b> 07 October 2014 22:03<br>
<b>To:</b> carter.schonwald@gmail.com<br>
<b>Cc:</b> ghc-devs@haskell.org<br>
<b>Subject:</b> RE: Again: Uniques in GHC<br>
</font><br>
</div>
<div></div>
<div>
<div style="font-size:12pt; color:#000000; background-color:#FFFFFF; font-family:Calibri,Arial,Helvetica,sans-serif">
<p>Dear Carter, Simon, et al,<br>
</p>
<p><br>
</p>
<p>(CC'd SPJ on this explicitly, because I *think* he'll be most knowledgeable on some of the constraints that need to be guaranteed for Uniques)<br>
</p>
<p><br>
</p>
<p>I agree, but to that end, a few parameters need to become clear. To this end, I've created a Phabricator-thing that we can discuss things off of:</p>
<p><br>
</p>
<p><a href="https://phabricator.haskell.org/D323" target="_blank">https://phabricator.haskell.org/D323</a><br>
</p>
<p><br>
<br>
</p>
<p>Here are my open issues:<br>
</p>
<p><br>
</p>
<p style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:16px">- There were ad hoc domains of Uniques being created everywhere in the compiler (i.e. characters chosen to classify the generated Uniques). I have gathered them all up and given them
names as constructors in Unique.UniqueDomain. Some of these names are arbitrary, because I don't know what they're for precisely. I generally went for the module name as a starting point. I did, however, make a point of having different invocations of mkSplitUniqSupply
et al all have different constructors (e.g. HscMainA through HscMainC). This is to prevent the high potential for conflicts (see comments in uniqueDomainChar). If there are people that are more knowledgeable about the use of Uniques in these modules (e.g.
HscMain, ByteCodeGen, etc.) can say that the uniques coming from these different invocations can never cause conflict, they maybe can reduce the number of UniqueDomains.<br>
</p>
<p style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:16px"><br>
</p>
<p style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:16px">- Some UniqueDomains only have a handful of instances and seem a bit wasteful.<br>
</p>
<p style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:16px"><br>
</p>
<p style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:16px">- Uniques were represented by a custom-boxed Int#, but serialised as Word32. Most modern machines see Int# as a 64-bit thing. Aren't we worried about the potential for undetected overlap/conflict there?<br>
</p>
<p style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:16px"><br>
</p>
<p style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:16px">- What is the scope in which a Unique must be Unique? I.e. what if independently compiled modules have overlapping Uniques (for different Ids) in their hi-files? Also, do TyCons and DataCons
really need to have guaranteed different Uniques? Shouldn't the parser/renamer figure out what goes where and raise errors on domain violations?<br>
</p>
<p style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:16px"><br>
</p>
<p style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:16px">- There seem to be related-but-different Unique implementations in Template Haskell and Hoopl. Why is this?<br>
</p>
<p style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:16px"><br>
</p>
<p style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:16px">- How critical is it to let mkUnique (and mkSplitUniqSupply) be pure functions? If they can be IO, we could greatly simplify the management of (un)generated Uniques in each UniqueDomain
and quite possibly make the move to a threaded GHC easier (for what that's worth). Also, this may help solve the non-determinism issues.<br>
</p>
<p style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:16px"><br>
</p>
<p style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:16px">- Missing haddocks, failing lints (lines too long) and a lot of cosmetics will be met when the above points have become a tad more clear. I'm more than happy to document a lot of the
answers to the above stuff in Unique and/or commentary.<br>
</p>
<p style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:16px"><br>
</p>
<p style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:16px">Regards,<br>
</p>
<p style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:16px">Philip<br>
</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<div style="color:rgb(40,40,40)">
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" color="#000000" face="Calibri, sans-serif"><b>From:</b> Carter Schonwald <carter.schonwald@gmail.com><br>
<b>Sent:</b> 07 October 2014 21:30<br>
<b>To:</b> Holzenspies, P.K.F. (EWI)<br>
<b>Cc:</b> Austin Seipp; ghc-devs@haskell.org<br>
<b>Subject:</b> Re: Again: Uniques in GHC</font>
<div> </div>
</div>
<div>
<div dir="ltr">in some respects, having fully deterministic builds is a very important goal: a lot of tooling for eg, caching builds of libraries works much much better if you have that property :) </div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Oct 7, 2014 at 12:45 PM, <span dir="ltr"><<a href="mailto:p.k.f.holzenspies@utwente.nl" target="_blank">p.k.f.holzenspies@utwente.nl</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
<span class=""><br>
________________________________________<br>
From: <a href="mailto:mad.one@gmail.com" target="_blank">mad.one@gmail.com</a> <<a href="mailto:mad.one@gmail.com" target="_blank">mad.one@gmail.com</a>> on behalf of Austin Seipp <<a href="mailto:austin@well-typed.com" target="_blank">austin@well-typed.com</a>><br>
<br>
</span><span class="">So I assume your change would mean 'ghc -j' would not work for 32bit.<br>
I still consider this a big limitation, one which is only due to an<br>
implementation detail. But we need to confirm this will actually fix<br>
any bottlenecks first though before getting to that point.<br>
<br>
<br>
<br>
<br>
</span>Yes, that's what I'm saying.<br>
<br>
Let me just add that what I'm proposing by no means prohibits or hinders making 32-bit GHC-versions be parallel later on, it just doesn't solve the problem. It depends to what extent the "fully deterministic behaviour" bug is considered a priority (there was
something about parts of the hi-files being non-deterministic across different executions of GHC; don't recall the details).<br>
<br>
Anyhow, the work I'm doing now exposes a few things about Uniques that confuse me a little and that could have been bugs (that maybe never acted up). Extended e-mail to follow later on.<br>
<br>
Ph.<br>
<div class="HOEnZb">
<div class="h5">_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>