[m-rev.] for discussion: undefined behaviours in int.m

[Zoltan Somogyi]

On Fri, 21 Oct 2016 15:21:51 +1100 (AEDT), Julien Fischer <jfischer at opturion.com> wrote:
> >>      - int8, int16, int32, int64
> >>      - uint8, uint16, uint32, uint64
> >>      - int, uint (i.e. word sized types)
> >>      - float32, float (float64)
> >
> > I don't think anyone has ever said that would be a bad thing to do.
> > All the objections have always consisted of reminders that that is
> > a *hard* thing to do.
> 
> I'll grant you that there's *a lot* to do, but I suspect the hard part
> may be simply working out where to do everything.  After all, it's been
> a very long time since a new builtin type was added.

That is part of the problem, but not all of it; after all, you can just
do a "grep -i float * */*, and you will get a close-enough superset
of those places.

I think a bigger part is due to the fact that each numeric type has
a very similar set of operations defined on it. Therefore when you use
those operations, you get ambiguity in the typechecker. If you use
N operations in a row, each of which could apply to any of M types,
the current typechecker would need to maintain M^N type assign sets,
and its performance falls through the floor. To maintain acceptable
compile times, you would therefore need to (a) implement something
like constraint based type checking, or (b) use a different set of names
for the operations on the different types. Option (a) is hard for us developers,
while option (b) makes things harder for *users* of the language.

Zoltan.