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

[Peter Ross]

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
compilation,
> 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
of
> 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
--------------------------------------------------------------------------