io__print/3

Fergus Henderson fjh at cs.mu.oz.au
Thu Dec 11 17:06:29 AEDT 1997


In mail to mercury-bugs at cs.mu.oz.au,
Mark Anthony BROWN <dougl at students.cs.mu.oz.au> wrote:

> The goal
> 
> 	io__print([univ(1), univ(2)], S0, S)
> 
> should print the list in human readable format.  It prints
> 
> 	[univ(1 : int), univ(2 : int)]

Seems reasonably human-readable to me.

> when I expected it to print
> 
> 	[1, 2]

The documentation for io__print says

	%       The argument is written in a format that is intended to
	%       be human-readable.
	%
	%       If the argument is just a single string or character, it
	%       will be printed out exactly as is (unquoted).
	%       If the argument is of type univ, then it will print out
	%       the value stored in the univ, but not the type.

In this case the argument is of type `list(univ)', not of type `univ'.

> What was io__print intended to do precisely?

The idea is that `io__print' will display the argument in a human-readable
format, with the outermost-level of "quotes" (either single quotes,
double quotes, or `univ(...)') removed.

It doesn't remove quotes or `univ(...)' in inner levels.
That's so that `io__print(["1.2", "foo bar", "x, y"])'
prints out as `["1.2", "foo bar", "x, y"]' rather than as
`[1.2, foo bar, x, y]'.  Printing out the latter
would look very strange, you couldn't even tell where
the list elements begin and end.

> The second case seems to be more useful, IMHO.

Perhaps.  But I'm not sure that this would generalize well.
If `io__print([univ(1),univ(2)])' wrote out `[1, 2]', what would
`io__print([univ("1"),univ("2")])' print out?
And what would

	:- type one_or_two ---> '1' ; '2'.
	main --> io__print([univ('1','2')]).

print out? 

How about the example below?

	:- func foo = bool.
	foo = no.

	:- func bar = maybe(int).
	foo = no.

	main -->
		io__print([univ(foo, bar)]).

As this example shows, it is necessary to print out the types to avoid
losing information.  `io__print' is supposed to display all the
information available (except for the case of `univ' at the top level,
which is a bit of a special case -- just as `char' and `string' at
the top level are special cases).

I'm not sure that the current design is optimal, but its not too bad,
and no better one leaps to mind.  If Mark or anyone else has any
further suggestions I'd be happy to listen to them.

Cheers,
	Fergus.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3         |     -- the last words of T. S. Garp.



More information about the developers mailing list