Quoted print (was Re: Floating point print Incompatibility SWI 5.10.2 versus 6.6.2)

On 03/23/2014 11:22 PM, Richard A. O'Keefe wrote:
>
> On 21/03/2014, at 11:56 PM, Jan Wielemaker wrote:
>> All debugging is traditionally printed using print/1, which traditionally uses unquoted write + portray.
>
> I believe I've seen a Prolog system that had
> printq/1, which was the obvious hybrid between
> print/1 and writeq/1.

Yes. There is nothing wrong with that, except that most development and
debugging libraries use the message system, which uses format/3, often
with the ~p escape. This is bound to print/1.

> SWI Prolog already has the write_term/2 option
> portray_goal, something other Prologs would do
> well to pick up.
>
>>   I've proposed
>> a while ago to change this to be quoted write + portray.
>
> Why does print/1 exist?
>
> Because Chris Mellish was trying to debug a program
> computing semantics for English where each goal filled
> more than one screen if written in full.
>
> print/1 was introduced so that you could *abbreviate*
> the debugging output of your program heavily.  This
> idea of diligently protecting every little detail with
> quotation marks while simultaneously hiding >90% of
> everything didn't really make much sense.  The output
> was never intended to be valid Prolog syntax.

At least I didn't miss the historical motivation. However, most of the
data printed for debugging through print/1 or ~p is short. Having quotes
avoids confusions. Just last week someone here was looking at something
like this:

   [Millers, Bob, Mary]

Expecting a list of two things. Well, it was in fact the list

   ['Millers, Bob', 'Mary']

so nothing was wrong.  Similar things happen if an atom
holding a number is misinterpreted, so you get curious
results such as

	debug(weird, '~p', [Goal])

writing 5 == 5 instead of '5' == 5. Other common confusing output are
empty atoms, strings/atoms, non-space whites in atoms, etc. Quoted write
makes such things easier to understand and allows for copy paste as long
as there is no portray that generates invalid syntax ... yes at the cost
of a little more output.

> Most of the time when you are debugging, you'd like
> floating point numbers to be abbreviated heavily, to
> just a couple of digits.  Anything more would be
> clutter, getting in the way of seeing what you need to
> see.  But sometimes it is floating point code that you
> are debugging, and you need to see all the digits.

Fair enough. There is nothing wrong by adding a portray rule for that.
Despite the value being rounded heavily, copy/paste might still be
sensible for debugging.

> It might be interesting to find out what people are
> using print/1 for.  There might be conflicting use
> cases that would be better served by more/different
> options.

Yes.  Most likely there are people using it like this:

	print('Hello World\n')

Should that bother us enough to introduce printq/1 and find a new format
escape sequence? Most code I've seen from people not using format/3 use
write/1 in the above. I consider that bad style, but ISO defines what it
means. print/1 is not part of ISO and -as far as I can tell- not used
very often in normal application code, so we can consider other options.

I'm tempted to use the Prolog flag `debugger_print_options` that provides
a list of options for writing terms from the debugger. The current
default is

     [quoted(true), portray(true), max_depth(10), attributes(portray)]

At least that would make the role of print/1 explicit and allow for
compatibility with other systems.  Opinions?


	Cheers --- Jan