<div dir="ltr"><div>Not to mention the horror and hilarity of endless JS surprises:</div><div><br></div><div>```js</div><div>> "4"+2<br>'42'<br>> "4"-2<br>2<br>> +"4"+2<br>6<br>> "5"*true<br>5<br>> "5"+true<br>'5true'<br>> "5"/false<br>Infinity</div><div>// and so on and so on...<br></div><div>```</div><div><br></div><div>To end this thread, actually I finally found out that most of the discussion we had so far could be summarized perfectly well in<i> 
Cardelli, Luca, and Peter Wegner. "On understanding types, data abstraction, and polymorphism." <br></i></div><div><i><br></i></div><div>The question if Haskell should have inclusion polymorphism still does not have a satisfying answer to me, but I found that <a href="https://discourse.haskell.org/search?q=oop">https://discourse.haskell.org/search?q=oop</a> seem to have some good threads to read more on.</div><div><br></div><div>Cheers everyone.<br></div><div><br></div><div><i></i></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 1, 2022 at 10:01 PM Brandon Allbery <<a href="mailto:allbery.b@gmail.com">allbery.b@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The first gcc example upcasts l to `double` before the addition, then<br>
casts the result of the addition down to `long` which loses<br>
information by truncation and possibly range (which can be triggered<br>
by either the `unsigned long` or the `double`; but neither one<br>
triggers that in this particular example). `long` and `unsigned long`<br>
are below both `float` and `double` in the hierarchy because the<br>
exponent can easily push a value out of their range.<br>
<br>
I'll also note that currently `fromIntegral` in Haskell doesn't verify<br>
range, so one can argue that a casting implementation has prior art to<br>
refer to.<br>
<br>
On Wed, Jun 1, 2022 at 2:52 PM Olaf Klinke <<a href="mailto:olf@aatal-apotheke.de" target="_blank">olf@aatal-apotheke.de</a>> wrote:<br>
><br>
> On Wed, 2022-06-01 at 02:54 +0300, Miao ZhiCheng wrote:<br>
> >  it also makes me think how the C language style of<br>
> > "implicit casting" is working under the hood.<br>
><br>
> Ooh, good question! I am not a C expert. Can anyone more experienced<br>
> share some details, please? In Kernighan & Ritchie I found this<br>
> wonderful sentence at the beginning of Section 2.7:<br>
> "In general, the only conversions that happen automatically are those<br>
> that make sense, ..."<br>
> And further:<br>
><br>
> "Implicit arithmetic conversions work much as expected. In general, if<br>
> an operator like + or * which takes two operands (a 'binary operator')<br>
> has operands of different types, the 'lower' type is promoted to the<br>
> 'higher' type before the operation proceeds."<br>
><br>
> This suggests that C, too, maintains a directed hierarchy [1] of<br>
> (numeric) types in which implicit conversions are performed. Attempt to<br>
> perform an explicit conversion not of this hierarchy (e.g. a struct) is<br>
> a compile-time error.<br>
> Except, the hierarchy is not really directed, because implicitly<br>
> casting "down" or "across" the hierarchy is also allowed. The following<br>
> is accepted by gcc 8.3.0.<br>
>   unsigned long l = 3000;<br>
>   double d = -3.4;<br>
>   long   x = l + d; // which is higher: long or double?<br>
>   double y = l + d;<br>
> K & R mention that implicit casting can lose information, e.g. by<br>
> rounding. I suppose a sane implementation in Haskell would want to<br>
> avoid that.<br>
><br>
> Olaf<br>
><br>
> [1] <a href="https://www.guru99.com/images/1/020819_0641_TypeCasting2.png" rel="noreferrer" target="_blank">https://www.guru99.com/images/1/020819_0641_TypeCasting2.png</a><br>
><br>
> _______________________________________________<br>
> Haskell-Cafe mailing list<br>
> To (un)subscribe, modify options or view archives go to:<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>
> Only members subscribed via the mailman list are allowed to post.<br>
<br>
<br>
<br>
-- <br>
brandon s allbery kf8nh<br>
<a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a><br>
</blockquote></div>