[m-users.] Debugging with foreign types

Mark Brown mark at mercurylang.org
Sat May 23 13:51:57 AEST 2015


On Sat, May 23, 2015 at 2:15 AM, Zoltan Somogyi
<zoltan.somogyi at runbox.com> wrote:
> On Fri, 22 May 2015 12:26:44 +0100, matthias.guedemann at googlemail.com (Matthias Güdemann) wrote:
>> when using mdb on code that uses foreign types, the repective values are
>> always displayed as '<<foreign>>'.
>>
>> Is it possible to get a string representation for foreign types for
>> debugging?
>
> How would you expect to specify the conversion from the foreign type
> to string?

It would be sufficient to print the word as a hex value, as is done
with c_pointer.

Although it doesn't tell you the state of the foreign type, you have
its identity and you can observe all the Mercury values going into and
coming out of the foreign calls. So you should be able to tell whether
the bug is on the Mercury side or the foreign side.

>
> If the conversion is a simple matter of "this binary value should be represented
> by this string, that binary value should be represented by that string, ..." for
> an exhaustive list of values, that can already be done by foreign enums.
> For non-enum values, the bit pattern that Mercury moves about is typically
> a pointer to something, but Mercury isn't told anything about what that thing
> is, or even how big it is. If you want to keep the type foreign, i.e. you don't want
> to tell Mercury about its representation, then the only way you can convert
> a value of that type to a string is to call a function in the relevant foreign
> language.

Like c_pointers, Mercury already knows how to compare foreign values,
and allowing the hex representation to be observed doesn't give away
much more.

> In short, this is not a simple problem to solve, all the solutions we know of
> have significant drawbacks, and (in the absence of a compelling set of examples)
> we don't know where on the scale from "negligible" to "crippling" the practical effects of those drawbacks would end up.

Is it possible to pass variables to an interactive query? That way a
user could export any number of functions to display foreign types
from mdb.

Cheers,
Mark.



More information about the users mailing list