<div dir="ltr"><div><div><div><div><div>I would like to throw something to the discussion. In UHC's build system a tool called Shuffle is used: <a href="http://foswiki.cs.uu.nl/foswiki/Ehc/ShuffleDocumentation">http://foswiki.cs.uu.nl/foswiki/Ehc/ShuffleDocumentation</a><br><br></div>It has three nice properties which I think could fit well with the problem:<br></div>- You can define variants of code with given numbers and names, and then ask the tool to produce the output file. Something a bit better than CPP itself.<br></div>- It understands some Haskell semantics. In particular, you can state functions imported or exported by each chunk (see <a href="http://foswiki.cs.uu.nl/foswiki/Ehc/ShuffleDocumentation#A_1.2_Output_specific_configuration">http://foswiki.cs.uu.nl/foswiki/Ehc/ShuffleDocumentation#A_1.2_Output_specific_configuration</a>) and the tool takes care of building up the module declaration on top of the file.<br></div>- It ships with a hook to integrate with Cabal (<a href="https://hackage.haskell.org/package/shuffle-0.1.3.3/docs/Distribution-Simple-Shuffle.html">https://hackage.haskell.org/package/shuffle-0.1.3.3/docs/Distribution-Simple-Shuffle.html</a>).<br><br></div>Just my two cents.<br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-10-09 3:31 GMT+02:00 Richard Eisenberg <span dir="ltr"><<a href="mailto:eir@cis.upenn.edu" target="_blank">eir@cis.upenn.edu</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On Oct 8, 2015, at 1:05 PM, Richard Eisenberg <<a href="mailto:eir@cis.upenn.edu">eir@cis.upenn.edu</a>> wrote:<br>
><br>
> My loose following of the interweaved threads has led me to this same conclusion. Have you paid close enough attention to list exactly what these changes should be? I have not. But I'd love to find a general solution to the migration problem so that we can continue to tinker with our beloved language without fear of flames burning down the house.<br>
<br>
</span>I should have been more explicit. I was more thinking of a multi-tiered warning system, where we decide, as a community, not to be embarrassed by warnings of severity less than X. When putting a DEPRECATED pragma on a definition, we could then give an indication of how soon we expect the definition to be gone.<br>
<br>
I was not thinking of the sort of "smart" behavior that Joachim wrote about. I want my programs to do exactly what I say -- compilers should only be so clever.<br>
<div class="HOEnZb"><div class="h5"><br>
Richard<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br></div>