<div>I would personally would argue that solution 2 (content depends on compiler) is the least offensive solution. Just incorporate any Typeable and Data derivings behind CPP guards, and just set a flag in the cabal file that defaults to true, which adds the existing DeriveDataTypeable language feature. Its self-contained and exists precisely for this purpose, and doesn&#39;t require all of the power of Rank2Types or GeneralizedNewtypeDeriving.</div>

<div> </div>
<div>Admittedly with 2, you get different contents on different platforms, but the only content you are missing in a minimalist &quot;Haskell 98 + addenda + CPP&quot;-only environment is instances that probably can&#39;t exist on that platform anyways, since Data.Data.Data is full of Rank-2 types. </div>

<div> </div>
<div>One could argue that a hand-implemented rank 2 Data.Data.Data instance is more portable than a DeriveDataTypeable provided Data.Data.Data instance, but at that point I think maintainability becomes a factor, plus you can further counter-argue that you don&#39;t actually need Rank-2 types to define a Data.Data.Data instance, merely to define the class, and the arguments could go back and forth for days.</div>

<div> </div>
<div>Heck the existing containers library is so gauche about this as to just guard its definitions for Data behind an <span class="cpp">#if __GLASGOW_HASKELL__ block, so by comparison the DerivingDataTypeable approach is fairly compassionate to third party distributions and provides a clear path for them to belly up to the bar if they want the instances. =)</span></div>

<div><span class="cpp"></span> </div>
<div><span class="cpp">-Edward Kmett</span></div>
<div> </div>
<div class="gmail_quote">On Tue, Jun 2, 2009 at 1:42 PM, Ashley Yakeley <span dir="ltr">&lt;<a href="mailto:ashley@semantic.org">ashley@semantic.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="im">Ashley Yakeley wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Malcolm Wallace wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">OK, I object to the proposed change.  The time library is pretty core,<br>and should continue to be buildable by compilers and interpreters other<br>
than GHC.  This does not necessarily mean it must be strictly H&#39;98<br>compliant, but that would be a good approximation of the common<br>language.<br></blockquote><br>What is that &quot;good approximation&quot;?<br><br>
These are the options:<br></blockquote><br></div>I forgot, time already requires CPP...<br><br>1. time to require Haskell 98 + FFI + CPP + Rank2Types, include Data instances 
<div class="im"><br><br>2. time to require Haskell 98 + FFI + CPP, content depends on compiler<br><br></div>3. time to require Haskell 98 + FFI + CPP, a time-extras package with orphan Data instances 
<div>
<div></div>
<div class="h5"><br><br>-- <br>Ashley Yakeley<br>_______________________________________________<br>Libraries mailing list<br><a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br><a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br>