Term representation and `any' insts - HAL

[Warwick Harvey]

Hi folks,

As many of you are aware, we are making heavy use of `any' insts for 
"solver" variables when compiling HAL to Mercury.  With the alias tracking 
code as of a month or so ago, it appears we can get Mercury to accept a 
variable's transition from `any' to `ground' (say) --- many thanks to those 
involved in the alias code.  This is mainly needed for situations where the 
HAL compiler knows more about a variable's instantiation than the Mercury 
compiler can --- it allows us to do instantiation coercions, for instance.

However, there is a further problem, for the situation where a variable goes 
from `any' to `bound(...)' (nothing to do with analysis this time).  This 
mainly relates to variables using the Herbrand solver, when we know the 
top-level functor has become bound.  The problem really stems from our 
representation of Herbrand variables --- we reserve a (primary) tag in the 
discriminated union, which means that the representation of a `free' 
variable is different (in the top-level word) from that of a bound variable. 
 This means a variable's representation can change when going from `any' to 
`bound(...)' or `ground'.  Unfortunately (for us), when it comes to code 
generation, Mercury seems to assume that `any' and `ground' are the same 
representation.  That is, if one passes a variable to a predicate which 
changes it from `any' to `bound(...)', Mercury assumes the representation 
hasn't changed, and continues to use the `any' copy of the variable 
(basically, it does not return the new representation from the predicate).

Now, we could work around this in our own code generation by introducing a 
new argument whenever the instantiation of a variable changes like this, but 
doing this seems annoying and error-prone.  :-)  So instead, I was wondering 
whether it might be better/easier to solve it at the Mercury end.

So basically, I'm looking for comments on any or all of the following:

- Is the assumption that the representation doesn't change for any -> bound 
a reasonable one?

- Would the change have too much negative impact for the cases where the 
representation didn't change?  (i.e. should I tailor the change so it only 
applies to Herbrand types?  --- I'm going to need to add explicit support 
for these to [the HAL version of] Mercury anyway, for certain polymorphic 
operations to work correctly.)

- Would it be a hard change to make (perhaps just in the HAL version of the 
compiler if not generally appropriate)?  It seems like it could be quite 
small, but I could be missing something (or a bucket load of things ;-).

- Are there other alternatives I should consider?

- Are we just completely suicidal for attempting to violate Mercury's 
assumptions that variables are either `free' or `ground'/`bound'?  :-)


On a somewhat related topic, it would be useful for us if there were an 
instantiation `bound/0', which basically means the top-level functor is 
bound, but its arguments are `any' (i.e. it tailors itself to the type 
similarly to `ground', but only applies to the top level of the type tree).  
Currently we just generate an instantiation for each type separately, but of 
course this doesn't work for polymorphic predicates.  That hasn't been a 
problem yet, but it could be in the future.  This seems like a much bigger 
change than the one above, and hence seems less likely that I will do 
anything about it, but I thought it might be worth at least thinking about 
while doing the above.

Thanks,
Warwick