On Wed, 2022-06-01 at 02:54 +0300, Miao ZhiCheng wrote:
it also makes me think how the C language style of "implicit casting" is working under the hood.
Ooh, good question! I am not a C expert. Can anyone more experienced share some details, please? In Kernighan & Ritchie I found this wonderful sentence at the beginning of Section 2.7: "In general, the only conversions that happen automatically are those that make sense, ..." And further: "Implicit arithmetic conversions work much as expected. In general, if an operator like + or * which takes two operands (a 'binary operator') has operands of different types, the 'lower' type is promoted to the 'higher' type before the operation proceeds." This suggests that C, too, maintains a directed hierarchy [1] of (numeric) types in which implicit conversions are performed. Attempt to perform an explicit conversion not of this hierarchy (e.g. a struct) is a compile-time error. Except, the hierarchy is not really directed, because implicitly casting "down" or "across" the hierarchy is also allowed. The following is accepted by gcc 8.3.0. unsigned long l = 3000; double d = -3.4; long x = l + d; // which is higher: long or double? double y = l + d; K & R mention that implicit casting can lose information, e.g. by rounding. I suppose a sane implementation in Haskell would want to avoid that. Olaf [1] https://www.guru99.com/images/1/020819_0641_TypeCasting2.png