<div dir="ltr">On Thu, Mar 28, 2013 at 4:49 PM, Henning Thielemann <span dir="ltr">&lt;<a href="mailto:lemming@henning-thielemann.de" target="_blank">lemming@henning-thielemann.de</a>&gt;</span> wrote:<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Thu, 28 Mar 2013, Brandon Allbery wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Thu, Mar 28, 2013 at 6:32 AM, Jason Dusek &lt;<a href="mailto:jason.dusek@gmail.com" target="_blank">jason.dusek@gmail.com</a>&gt; wrote:<br>
      One way to think of it is, CTime is time and should follow the<br>
      rules of the time. Another way is, CTime is a C type and should<br>
      follow the rules of C types.  The latter perspective seems more<br>
      appropriate for Foreign.C.* (we are likely to seek out some<br>
      other module for modelling time).<br>
<br>
Phrasing this perhaps more clearly: the point of the FFI types is to reflect foreign types.<br>
</blockquote>
<br></div>
If CTime is only for interfacing with C, then there should not be any arithmetic or bit manipulation class instances of it, only some conversion functions between CTime and Haskell time representations.<br>
</blockquote></div><br>...and implementing those should be as painful as possible?<br clear="all"><div><br></div>-- <br><div dir="ltr"><div>brandon s allbery kf8nh                               sine nomine associates</div>
<div><a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a>                                  <a href="mailto:ballbery@sinenomine.net" target="_blank">ballbery@sinenomine.net</a></div><div>unix, openafs, kerberos, infrastructure, xmonad        <a href="http://sinenomine.net" target="_blank">http://sinenomine.net</a></div>
</div>
</div>