[m-dev.] compiler abort: coercing abstract type

Peter Wang novalazy at gmail.com
Tue Nov 4 10:21:37 AEDT 2025


On Mon, 03 Nov 2025 21:12:40 +1100 Julien Fischer <jfischer at opturion.com> wrote:
> On Mon, 3 Nov 2025 at 19:05, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
> 
> > The second way is to say that if the from-type and the to-type
> > share the same actual type_ctor (in this case cord/1) and not just
> > the same *base* type_ctor, then for the coerce to succeed, it is sufficient
> > for *its arguments* to be coercable between the from_type and the to_type,
> > and it does not matter whether the actual shared_type_ctor is du or abstract.
> > This would say that if a type_ctor's coerceability is not an issue because it is
> > the same in both the from-type and the to-type, then its definition need not
> > be visible.
> >
> > In this case, the shared type_ctor is a du type behind the abstraction barrier,
> > but I do not see any reason why the second way would not work even if
> > it is an equivalence type or even a foreign or solver type.

No, it would introduce unsoundness into the system, by bypassing the
type parameter invariance restriction.

For example, assume this type is abstract exported:

    :- type abs(T)
	--->	abs((func) = T).

If you could coerce a value of this type from abs(fruit) to abs(citrus),
you could call the function expecting it to return a 'citrus',
but it actually returns a 'fruit'.

Peter


More information about the developers mailing list