<div dir="ltr"><div><span style="font-size:12.8px"><font face="arial, helvetica, sans-serif">Note:</font></span></div><span style="font-size:12.8px"><font face="monospace, monospace"><div><span style="font-size:12.8px"><font face="monospace, monospace"><br></font></span></div>hWaitForInput stdin 4294968296</font></span><br><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">is using <font face="monospace, monospace">fromInteger</font>, not <font face="monospace, monospace">fromIntegral</font>.<font face="monospace, monospace"> </font></span><span style="font-size:12.8px"><font face="monospace, monospace">fromInteger</font> is the member of <font face="monospace, monospace">Num</font>. <font face="monospace, monospace">fromIntegral</font> is defined in terms of it and <font face="monospace, monospace">toInteger</font>.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Deprecating f<font face="monospace, monospace">romIntegral </font>would do nothing to the example you offered at all as it isn't being called.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Like it or not the existing numeric types in the Haskell ecosystem wrap, and changing this behavior would have non-trivial ramifications for almost all Haskell source code written to date.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">This isn't a small change you are proposing.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">If your goal is to address this micro-issue, i</span><span style="font-size:12.8px">t would be a much easier target to aim for <font face="monospace, monospace">hWaitForInput</font> taking an Integer rather than an Int, removing the issue at the source. There are already packages providing safer delays, e.g.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><a href="https://hackage.haskell.org/package/unbounded-delays">https://hackage.haskell.org/package/unbounded-delays</a></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">It has gradually become clear that using Int in delay and <font face="monospace, monospace">hWaitForInput</font> and <font face="monospace, monospace">delay</font> the like was a mistake. After all if you're going to set up to block anyways the overhead of allocating a single Integer constructor is trivial.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">For comparison, I have zero objection to going after the type signature of <font face="monospace, monospace">hWaitForInput</font>!</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Changing <font face="monospace, monospace">fromInteger</font> on the other hand is a Prelude affecting change that bubbles all the way down into Num. </span><span style="font-size:12.8px">I'm very much against breaking every single Num instance, and making every Haskell developer audit every application of a very common function to fix one overflow in one naively designed system call.</span></div><div><br></div><div><span style="font-size:12.8px">-Edward</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 21, 2017 at 1:26 PM, Niklas Hambüchen <span dir="ltr"><<a href="mailto:mail@nh2.me" target="_blank">mail@nh2.me</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey Edward,<br>
<br>
I'm not going after Num here.<br>
<br>
What I care about is that base provide conversion functions with clear<br>
names that indicate what they do, so that the intent of the author<br>
becomes obvious.<br>
<br>
Currently we cram all number conversion functionality into<br>
`fromIntegral`, and offer no standard way for talking about code that<br>
has no intent to wrap.<br>
<br>
This code:<br>
<br>
fdReady ... (fromIntegral msecs)<br>
<br>
does not look obviously incorrect, but this code would:<br>
<br>
fdReady ... (fromIntegralWrap msecs)<br>
<br>
Of course it would be great if a name change came along with a set of<br>
type classes that make it compile-time-impossible to do an unintended<br>
cast, but in absence of one agreed way to do that, more functions with<br>
better names and appropriate error behaviour would already go a long way<br>
for avoiding bugs like this.<br>
<br>
To throw out some concrete examples, there could be:<br>
<br>
* maybeFromInteger / maybeFromIntegral<br>
- that return Nothing when the input doesn't fit<br>
* runtimeCheckedFromInteger / runtimeCheckedFromIntegral<br>
- `error` on Nothing<br>
* fromIntegerWrap / fromIntegralWrap<br>
- what the current functions do<br>
* fromInteger / fromIntegral<br>
- unchanged semantics, but emitting a deprecation warning<br>
<br>
Deprecation seems the best method by which we can systematically<br>
highlight all use sites where a replacement with a function of a better<br>
name, or missing edge case handling, should be inserted, without<br>
breaking code.<br>
<span class="HOEnZb"><font color="#888888"><br>
Niklas<br>
</font></span></blockquote></div><br></div>