[m-users.] Debugging with foreign types

[Zoltan Somogyi]

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?

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. The Mercury debugger mdb uses is written in C, so this would
require the foreign language function to be in C, though a C wrapper (possibly
automatically generated) around e.g. a Java method should also be possible.

Unfortunately, in many cases, the foreign value is something big, like a tree,
and at any point in time the user is interested in only selected parts of it.
This would require either (a) adding some parameters to the conversion function
to specify what is needed, or (b) converting the value to a huge string, converting that string to a Mercury term, and letting the user use the existing browser in the
debugger to explore that term. I think option (a) could become too complicated
to be managed easily, while (b) can easily be quite expensive, as it may require
converting multimegabyte data structures first to a string (or a list of strings,
to avoid the requirement to copy the old parts of a growing contiguous string)
and then to a term. A possible option (c) would be to let the foreign language
function generate a Mercury-readable structured term representation,
but I think that would be too error-prone, since any mistake in that function
would crash the debugger. (With option (b) the string-to-term conversion
could detect strings that don't follow the required rules *without* crashing.)

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.

Zoltan.