<div dir="ltr">On Thu, Mar 28, 2013 at 5:11 PM, Henning Thielemann <span dir="ltr"><<a href="mailto:lemming@henning-thielemann.de" target="_blank">lemming@henning-thielemann.de</a>></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>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If CTime is only for interfacing with C, then there should not be any arithmetic or bit manipulation<br>
class instances of it, only some conversion functions between CTime and Haskell time representations.<br>
<br>
...and implementing those should be as painful as possible?<br>
</blockquote>
<br></div>
Implementing these conversion functions means unpacking data from the CTime constructor and convert it to Haskell time representations or vice versa. I don't think it is possible to write conversion functions using Num and Bits that work on all architectures. If there is functionality that can be used on multiple architectures this should be provided as helper functions.<br>
</blockquote></div><br>Can't be done on all architectures, therefore we should ensure it can't be done at all. Which means CTime can never actually be used from Haskell, not even by converting it to a Haskell-friendly representation, but only as an opaque blob; that's really helpful when interfacing to e.g. POSIX functions.<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>