[m-dev.] .NET back-end test results

Peter Ross pro at missioncriticalit.com
Thu Nov 7 10:25:28 AEDT 2002

fjh wrote:
> On 06-Nov-2002, Peter Ross <pro at missioncriticalit.com> wrote:
> >
> > This is the start of my fix for the problem B3 (FAILED.UNDEFINED)
> > class by trying to expand out the equivalence types for the special
> > predicates when producing the special predicates.
> I was thinking of doing this expansion at a later stage of the
> shortly before code generation, rather than in make_hlds.m.
> > Anyone see problems with this approach or can think of another
> > approach?
> There may be problems with "non-transparent" equivalent types:
> those where a type parameter on the LHS does not occur on the RHS,
> e.g.
> :- type foo(T) == int.
> If you do the expansion before polymorphism, then the type_info for the
> type parameter T won't get inserted in the arguments, but it needs to be.
Are you sure that this is a problem.  Don't all occurences of foo(T) get
transformed by equiv_type while still at the parse tree representation?  So
the problem already exists.

> I think there will also be some issues with specialization and/or inlining
> unification procedures; the code there is probably assuming that the
> argument types of the procedure will unify with the argument types in
> the caller.
But aren't the argument types in the caller of the expanded out equivalence
type.  So before this change they didn't match but now they do.

I think I am unclear about when the expansion of equivalence types occurs.

mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au

More information about the developers mailing list