[m-dev.] [Mercury-Language/mercury] Segfault in only Mercury after solutions in a particular code path (#72)

Zoltan Somogyi zoltan.somogyi at runbox.com
Tue Nov 17 13:16:36 AEDT 2020


2020-11-17 12:51 GMT+11:00 "Peter Wang" <novalazy at gmail.com>:
>> No, it is not possible to construct such a closure. That is not the problem.
>> The problem is that it is possible to construct a closure in which one of
>> the *non*-captured arguments needs to be twinned. You cannot simultaneously
>> (a) twin the argument for correctness, and (b) have the same signature
>> in the target language as other closures with the same *Mercury* signature.
> 
> Ah okay.
> 
> I'm wondering though: which non-captured argument(s) needs twinning is
> based on the higher order inst. The construction of a closure and calls
> to that closure must(?) have the same higher order inst information,
> so it should be possible to twin the arguments both when constructing
> the closure and calling the closure in the same way.
> Where am I going wrong?

You aren't; I was. I simply hadn't thought that far ahead, because ...

> This is in no way important. Reporting "sorry, not implemented" would be
> fine for this rare case.

... I agree with this, and thus didn't think there was much point in
having the transformation modify higher order calls as well as
first order calls.

Overall, do you agree with my proposed course of action, as updated
with the results of this discussion?

Zoltan.


More information about the developers mailing list