<div dir="ltr">Having a requirement to manually install a newer Alex doesn&#39;t seem too onerous to me. That would be my recommendation.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Sep 10, 2013 at 11:53 AM, Simon Peyton-Jones <span dir="ltr">&lt;<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-GB" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">(Simon M: are you ok with updating Alex?  You were the one of those who argued strongly for using the old names for the new primops.)<u></u><u></u></span></p>


<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">The difficulty is this. 
<u></u><u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:Symbol;color:#1f497d"><span>·<span style="font:7.0pt &quot;Times New Roman&quot;">        
</span></span></span><u></u><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Alex generates Haskell code, by transforming Foo.x into Foo.hs<u></u><u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:Symbol;color:#1f497d"><span>·<span style="font:7.0pt &quot;Times New Roman&quot;">        
</span></span></span><u></u><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">The generated Foo.hs contains references to comparison primops, say (&gt;#) :: Int# -&gt; Int# -&gt; Bool<u></u><u></u></span></p>


<p><u></u><span style="font-size:11.0pt;font-family:Symbol;color:#1f497d"><span>·<span style="font:7.0pt &quot;Times New Roman&quot;">        
</span></span></span><u></u><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Therefore Foo.hs will not work with GHC 7.8 if we have changed the type of (&gt;#), which is what I think we have agreed to
 do.<u></u><u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:Symbol;color:#1f497d"><span>·<span style="font:7.0pt &quot;Times New Roman&quot;">        
</span></span></span><u></u><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">The solution is to make Alex generates a Foo.hs that is compilable either with GHC 7.8 or 7.6, by including enough CPP
 directives.  Alex already does this for compatibility with earlier GHCs<u></u><u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:Symbol;color:#1f497d"><span>·<span style="font:7.0pt &quot;Times New Roman&quot;">        
</span></span></span><u></u><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">However, until there is a new version of Alex, you simply won’t be able to bootstrap GHC 7.8 (or indeed the current HEAD).<u></u><u></u></span></p>


<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">That’s all there is to it.  It’s tiresome and trivial in a sense, but it’s a choice we have to make.<u></u><u></u></span></p>


<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">It might be perfectly reasonable to say
<u></u><u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:Symbol;color:#1f497d"><span>·<span style="font:7.0pt &quot;Times New Roman&quot;">        
</span></span></span><u></u><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">You can’t build GHC 7.8 from source with the Haskell Platform until a new HP comes out with the new Alex (which will be
 soon).<u></u><u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:Symbol;color:#1f497d"><span>·<span style="font:7.0pt &quot;Times New Roman&quot;">        
</span></span></span><u></u><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Unless you install the new Alex manually<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">This seems not too bad; people who build GHC from source are generally pretty savvy.  The choice between the two is what we seek
 your guidance on.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">(Incidentally, a very similar situation has arisen for Happy: see
<a href="http://ghc.haskell.org/trac/ghc/ticket/8022" target="_blank">http://ghc.haskell.org/trac/ghc/ticket/8022</a>.  But there the cost of perpetuating the status quo for another release cycle seems minimal.)<u></u><u></u></span></p>


<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Simon<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u> <u></u></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;"> <a href="mailto:michael.snoyman@gmail.com" target="_blank">michael.snoyman@gmail.com</a> [mailto:<a href="mailto:michael.snoyman@gmail.com" target="_blank">michael.snoyman@gmail.com</a>]
<b>On Behalf Of </b>Michael Snoyman<br>
<b>Sent:</b> 10 September 2013 05:28<br>
<b>To:</b> Simon Peyton-Jones<br>
<b>Cc:</b> <a href="mailto:core-libraries-committee@haskell.org" target="_blank">core-libraries-committee@haskell.org</a>; ghc-devs; Geoffrey Mainland; Jan Stolarek<br>
<b>Subject:</b> Re: [core libraries] RE: Alex and new Bool primops<u></u><u></u></span></p>
</div>
</div><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
I&#39;ll admit a fair amount of ignorance of the GHC build process. But wouldn&#39;t it be standard that any tool used in the GHC build process itself, and built by GHC itself, would need to have some conditional compilation in place to handle API changes? It seems
 like the questions here are whether we should ever allow breaking changes in the API, and in this case whether the changes are coming too late in the development cycle. It seems like we&#39;ve agreed on the first count that it&#39;s beneficial to allow breaking API
 changes. It could be that in this case we&#39;re too late in the dev cycle.<u></u><u></u></p>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
In this case, it sounds like including the compatibility module in Alex would be most expedient, but I&#39;d defer to those who understand the process better than me.<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:12.0pt;margin-left:0cm">
<u></u> <u></u></p>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
On Mon, Sep 9, 2013 at 5:38 PM, Simon Peyton-Jones &lt;<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>&gt; wrote:<u></u><u></u></p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
Dear Core Libraries Committee<br>
<br>
I think we need your advice.<br>
<br>
This thread (mostly on ghc-devs) shows that if the shim-package and boolean-primop decision goes as currently proposed, then we&#39;ll need a new release of Alex<br>
 * Either to generate an import of GHC.Exts.Compat<br>
   (ie depend on the shim package)<br>
 * Or to make its own local tiny shim module for the primops it uses<br>
 * Or maybe some other plan<br>
(Alex already has quite a bit of stuff designed to make it generate code that will be compilable with a variety of GHCs.)<br>
<br>
Moreover this new release of Alex will be necessary simply in order to allow 7.8 (or indeed 7.7) to be bootstrapped. So, for example, the current HP could not be used to build GHC.<br>
<br>
How would you like us to proceed?  Thanks!<u></u><u></u></p>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<br>
Simon<br>
<br>
| -----Original Message-----<br>
| From: ghc-devs [mailto:<a href="mailto:ghc-devs-bounces@haskell.org" target="_blank">ghc-devs-bounces@haskell.org</a>] On Behalf Of<br>
| Geoffrey Mainland<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
| Sent: 09 September 2013 16:14<br>
| To: Jan Stolarek<br>
| Cc: ghc-devs<br>
| Subject: Re: Alex and new Bool primops<br>
|<u></u><u></u></p>
</div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
| I say this only somewhat facetiously, but this is *exactly* the sort of<br>
| problem that the pro-backwards compatibility camp anticipates, and I<br>
| mean the &quot;pro-backwards compatibility camp&quot; in the most general possible<br>
| way :) The point is that you can never anticipate all the ways in which<br>
| breaking backwards compatibility breaks things. How much &quot;technical<br>
| debt&quot; is really accrued with backwards compatible primops? What is<br>
| preventing us from doing the so-called &quot;Right Thing&quot; *after* the 7.8<br>
| release?<br>
|<br>
| Anyway, the one solution I can think of off the top of my head is to<br>
| patch Alex&#39;s templates to use an #ifdef to pick primops based on the<br>
| version of GHC being used for compilation. That will need to be done<br>
| anyway.<br>
|<br>
| As an aside, I think any discussion that involves making decisions that<br>
| effect the community as a whole should have a public mail archive.<br>
|<br>
| Geoff<br>
|<br>
| On 09/09/2013 11:02 AM, Jan Stolarek wrote:<br>
| &gt; I think the there was a general agreement in the committee that we<br>
| should follow the best long-term solution, not the best short-term one.<br>
| Here are two arguments (Plan B = break backwards compatibility):<br>
| &gt;<br>
| &gt;   &gt; I&#39;d rather not hamstring GHC.* with a rats nest of backwards<br>
| compatibility decisions,<br>
| &gt;   &gt; which all come at accreted costs, the mortgage for which is to be<br>
| paid down forever<br>
| &gt;   &gt; by future development efforts.<br>
| &gt;<br>
| &gt;   &gt; I vote for plan B on the grounds that it&#39;s the Right Thing and the<br>
| &gt;   &gt; group that it breaks is both small and savvy.<br>
| &gt;<br>
| &gt;   &gt; [implementing backwards compatibility solution] only works once,<br>
| though. We&#39;re in exactly the same boat on all future primop redesigns.<br>
| &gt;<br>
| &gt; There was also a decision of providing a backwards compatibility<br>
| package that would make it easy for library authors to create packages<br>
| that are compatible both with 7.6 and 7.8 (summarized here:<br>
| <a href="http://www.haskell.org/haskellwiki/Compatibility_Modules" target="_blank">
http://www.haskell.org/haskellwiki/Compatibility_Modules</a>). Sadly,<br>
| there&#39;s no web archive for that list so I can&#39;t point you to the<br>
| discussion.<br>
| &gt;<br>
| &gt; Anyway, this is clearly something no one has anticipated and the<br>
| question is whether we have a good way to solve that problem?<br>
| &gt;<br>
| &gt; Janek<br>
| &gt;<br>
| &gt; ----- Oryginalna wiadomość -----<br>
| &gt; Od: &quot;Geoffrey Mainland&quot; &lt;<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a>&gt;<br>
| &gt; Do: &quot;Jan Stolarek&quot; &lt;<a href="mailto:jan.stolarek@p.lodz.pl" target="_blank">jan.stolarek@p.lodz.pl</a>&gt;<br>
| &gt; DW: &quot;ghc-devs&quot; &lt;<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>&gt;<br>
| &gt; Wysłane: poniedziałek, 9 wrzesień 2013 15:40:09<br>
| &gt; Temat: Re: Alex and new Bool primops<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
| &gt;<br>
| &gt; Perhaps the core libraries committee should reconsider their decision?<br>
| &gt; :) Backwards compatibility is good. If HEAD implements the backwards<br>
| &gt; compatibility plan that Simon PJ and I suggested and said plan is<br>
| &gt; working, there should be a compelling reason to break compatibility<br>
| and<br>
| &gt; have to go chasing down all the follow-on breakage (in, e.g., Alex) so<br>
| &gt; close to release.<br>
| &gt;<br>
| &gt; What was the committee&#39;s reasoning?<br>
| &gt;<br>
| &gt; Geoff<br>
| &gt;<br>
| &gt; On 09/09/2013 10:08 AM, Jan Stolarek wrote:<br>
| &gt;&gt; I am refactoring new Bool primops (#6135). There was a discussion on<br>
| core-libraries-commitee list and the decision was made that we should<br>
| keep names of primops we used so far and change their type signature<br>
| (right now HEAD has different names for new primops and reuses old names<br>
| for compatibility wrappers). I&#39;ve changed names of the primops and<br>
| removed the wrappers but I can&#39;t bootstrap GHC because old primops are<br>
| hardwired into Alex. I get this build error when attempting to build<br>
| stage 2 compiler:<br>
| &gt;&gt;<br>
| &gt;&gt; compiler/stage2/build/Lexer.hs:2348:34:<br>
| &gt;&gt;     Couldn&#39;t match expected type &#39;Bool&#39; with actual type &#39;Int#&#39;<br>
| &gt;&gt;     In the first argument of &#39;(&amp;&amp;)&#39;, namely &#39;(offset &gt;=# 0#)&#39;<br>
| &gt;&gt;     In the expression: (offset &gt;=# 0#) &amp;&amp; (check ==# ord_c)<br>
| &gt;&gt;     In the expression:<br>
| &gt;&gt;       if (offset &gt;=# 0#) &amp;&amp; (check ==# ord_c) then<br>
| &gt;&gt;           alexIndexInt16OffAddr alex_table offset<br>
| &gt;&gt;       else<br>
| &gt;&gt;           alexIndexInt16OffAddr alex_deflt s<br>
| &gt;&gt;<br>
| &gt;&gt; compiler/stage2/build/Lexer.hs:2348:53:<br>
| &gt;&gt;     Couldn&#39;t match expected type &#39;Bool&#39; with actual type &#39;Int#&#39;<br>
| &gt;&gt;     In the second argument of &#39;(&amp;&amp;)&#39;, namely &#39;(check ==# ord_c)&#39;<br>
| &gt;&gt;     In the expression: (offset &gt;=# 0#) &amp;&amp; (check ==# ord_c)<br>
| &gt;&gt;     In the expression:<br>
| &gt;&gt;       if (offset &gt;=# 0#) &amp;&amp; (check ==# ord_c) then<br>
| &gt;&gt;           alexIndexInt16OffAddr alex_table offset<br>
| &gt;&gt;       else<br>
| &gt;&gt;           alexIndexInt16OffAddr alex_deflt s<br>
| &gt;&gt;<br>
| &gt;&gt; And indeed, looking at Lexer.hs I see:<br>
| &gt;&gt;<br>
| &gt;&gt; alex_scan_tkn user orig_input len input s last_acc =<br>
| &gt;&gt;  (...) -- some irrelevant code here<br>
| &gt;&gt;                 (!(new_s)) = if (offset &gt;=# 0#) &amp;&amp; (check ==# ord_c)<br>
| &gt;&gt;                           then alexIndexInt16OffAddr alex_table<br>
| offset<br>
| &gt;&gt;                           else alexIndexInt16OffAddr alex_deflt s<br>
| &gt;&gt;<br>
| &gt;&gt; So to compile GHC, Alex would need to generate different code for GHC<br>
| 7.6.3 and below, and different for GHC 7.7 and above (or alternatively<br>
| it could generate #if pragmas), but this means we&#39;d need to update Alex.<br>
| I created compatibility module within GHC called ExtsCompat46 and tried<br>
| adding it to list of imported modules, but in generated Lexer.hs Alex<br>
| adds a bunch of other modules among which is GHC.Exts, which conflicts<br>
| with import of ExtsCompat46:<br>
| &gt;&gt;<br>
| &gt;&gt; compiler/stage1/build/Lexer.hs:2349:41:<br>
| &gt;&gt;     Ambiguous occurrence `&gt;=#&#39;<br>
| &gt;&gt;     It could refer to either `ExtsCompat46.&gt;=#&#39;,<br>
| &gt;&gt;                              imported from `ExtsCompat46&#39; at<br>
| compiler/parser/Lexer.x:79:1-19<br>
| &gt;&gt;                           or `GHC.Exts.&gt;=#&#39;,<br>
| &gt;&gt;                              imported from `GHC.Exts&#39; at<br>
| compiler/stage1/build/Lexer.hs:75:1-15<br>
| &gt;&gt;                              (and originally defined in `ghc-<br>
| prim:GHC.Prim&#39;)<br>
| &gt;&gt;<br>
| &gt;&gt; Again, we would need updated version of Alex to generate correct code<br>
| (also, this would break in the future after removing that compatibility<br>
| module). I don&#39;t see a way out of this. Help?<br>
| &gt;&gt;<br>
| &gt;&gt; Janek<br>
| &gt;&gt;<br>
| &gt;&gt; _______________________________________________<br>
| &gt;&gt; ghc-devs mailing list<br>
| &gt;&gt; <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
| &gt;&gt; <a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
| &gt;<br>
|<br>
|<br>
| _______________________________________________<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>
<br>
--<br>
You received this message because you are subscribed to the Google Groups &quot;haskell-core-libraries&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an email to
<a href="mailto:haskell-core-libraries%2Bunsubscribe@googlegroups.com" target="_blank">haskell-core-libraries+unsubscribe@googlegroups.com</a>.<br>
For more options, visit <a href="https://groups.google.com/groups/opt_out" target="_blank">
https://groups.google.com/groups/opt_out</a>.<u></u><u></u></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<u></u> <u></u></p>
</div>
</div></div></div>
</div>
</div>

</blockquote></div><br></div>