[Haskell-cafe] Should there be a haskell template for inclusion polymorphism in Haskell?

[Miao ZhiCheng]

Not to mention the horror and hilarity of endless JS surprises:

```js
> "4"+2
'42'
> "4"-2
2
> +"4"+2
6
> "5"*true
5
> "5"+true
'5true'
> "5"/false
Infinity
// and so on and so on...
```

To end this thread, actually I finally found out that most of the
discussion we had so far could be summarized perfectly well in
* Cardelli, Luca, and Peter Wegner. "On understanding types, data
abstraction, and polymorphism." *

The question if Haskell should have inclusion polymorphism still does not
have a satisfying answer to me, but I found that
https://discourse.haskell.org/search?q=oop seem to have some good threads
to read more on.

Cheers everyone.



On Wed, Jun 1, 2022 at 10:01 PM Brandon Allbery <allbery.b at gmail.com> wrote:

> The first gcc example upcasts l to `double` before the addition, then
> casts the result of the addition down to `long` which loses
> information by truncation and possibly range (which can be triggered
> by either the `unsigned long` or the `double`; but neither one
> triggers that in this particular example). `long` and `unsigned long`
> are below both `float` and `double` in the hierarchy because the
> exponent can easily push a value out of their range.
>
> I'll also note that currently `fromIntegral` in Haskell doesn't verify
> range, so one can argue that a casting implementation has prior art to
> refer to.
>
> On Wed, Jun 1, 2022 at 2:52 PM Olaf Klinke <olf at aatal-apotheke.de> wrote:
> >
> > 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
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > To (un)subscribe, modify options or view archives go to:
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > Only members subscribed via the mailman list are allowed to post.
>
>
>
> --
> brandon s allbery kf8nh
> allbery.b at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20220606/a1289192/attachment.html>