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

[Zoltan Somogyi]

On Fri, 21 Oct 2016 22:49:24 +1100, Mark Brown <mark at mercurylang.org> wrote:
> On Fri, Oct 21, 2016 at 7:24 PM, Zoltan Somogyi
> <zoltan.somogyi at runbox.com> wrote:
> > 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.
> 
> If that's true we'd see O(2^N) performance due to the ambiguity
> between int and float, but I haven't observed that.

The scanner separates int and float constants. Therefore an expression
such as 2 * X has no type ambiguity in the common case that the
typechecker already knows the type of X (e.g. because it is a parameter
of the current predicate).

However, if we supported multiple integer types with the same syntax
for literals, which would allow 2 to have as its type not just int,
but also uint, int32, uint32, etc, the ambiguities would pile up
pretty quickly.

This is a point against similar proposals in the past; if I understand
the current proposal correctly, it would not apply to it.

Zoltan.