[m-users.] Debugging with foreign types

[Matthias Güdemann]

Hi Zoltan,

thank you for your answer.

> How would you expect to specify the conversion from the foreign type
> to string?

My view on working with foreign type is surely quite limited at the
moment. I imagined having a type class for foreign types that exports a
few functions to turn a value into a string. A simple case could be
having two functions, one to get a condensed version, e.g., printing
only the root of the tree, and a second one to get the full
representation.

This certainly would not *solve* the problem, but could be helpful in
some cases.

> 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.)

I fully agree with you that this would be very complex, in particular
having a browsable representation.

How is debugging with foreign code usually done? What I did was simply
to add some printfs around the functions that were called.

Matthias