[m-dev.] generating boxed version of special pred

[Fergus Henderson]

On 29-Nov-2003, Peter Ross <pro at missioncriticalit.com> wrote:
> The attached code highlights a bug on the IL backend.
> 
> It should generate
> $ ./equality_pred_which_requires_boxing
> float (boxed): true
> float (unboxed): true
> foreign_type (boxed): true
> foreign_type (unboxed): true
> 
> but it generates 
> 
> $ ./equality_pred_which_requires_boxing
> float (boxed): false
> float (unboxed): true
> foreign_type (boxed): false
> foreign_type (unboxed): true

Yes, that's a bug.

> The problem is that when we are generating the RTTI for a value type
> (builtin or defined using a foreign_type) we generate the unification
> predicate using the unboxed types.
> 
> However when we call this unification predicate from the generic
> unification predicate the arguments are boxed and so we get the wrong
> behaviour.
> 
> What needs to happen is that we need to generate two versions of the
> special pred, one with the boxed arguments and one without.  The only
> problem is that I am not sure how and where to do this?  I looked at
> doing it in rtti_to_mlds.m but I found it really difficult to do, so I
> was hoping someone can give me some advice on the best way to do this.

I think rtti_to_mlds.m and ml_closure_gen.m is the right place to do it.
The same issue came up for higher-order calls, and for class method
calls.  There is code in ml_generate_closure_wrapper in ml_closure_gen.m,
which is called from rtti_to_mlds.m to handle the analagous problem
for higher-order calls and for class method calls.  You could add a
new alternative to the closure_kind type for unification and comparison
predicates, and then call ml_generate_closure_wrapper.  Of course you'd
need to modify the code for that procedure to handle this new alternative.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------