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

I tend to agree with Jan on this. A lot of the situations where 
this kind 'printing-via-hook' occurs are to do with debugging
or generally snooping around a program, and in these cases
we are usually interested in seeing the structure of terms,
and so it is important not to introduce the kind of ambiguity
demonstrated in Jan's examples below.

Another set of cases is where we want the program to present
information to the user at an application level of abstraction, not
an implementation level. Sometimes, write/1 or writeln/1 is good
enough for this, but, really, this is what format/3 is for: it enables
you to really take control of how a information will appear.

The portray/1 hook system is, I think, intended for the *former*
case, not the latter. If you know in your program that you want
to print something a certain way, for the user to read, then use 
format/3. By writing a portray/1 clause, you are in effect making a 
promise to the system: you are saying 'if you write this kind of term 
this way, I promise I will understand what you mean.' Of course this 
can sacrifice the ability to read back what has just been written, but
I think that's fine - there is another system for doing that.

Given these considerations, I think it makes sense for the portray/
print system to do proper quoting as Jan suggests.

One possible option that could
be added as a top-level flag, is to enable either print/portray with quoting
for general system output, debugging etc, or disable print/portray and
enable strictly quoted output that can be re-read via cut and past,
given the current operator definitions. (The ultra-strict alternative
would be to use canonical write, but that could be unbearable to look at, so
I think requiring the operator definitions currenty in force in, say, the
user module is a reasonable compromise.)

Samer

On 24 Mar 2014, at 10:49, Jan Wielemaker <[email protected]>
 wrote:

> 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
> 
> _______________________________________________
> SWI-Prolog mailing list
> [email protected]
> https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.iai.uni-bonn.de/pipermail/swi-prolog/attachments/20140324/4aaaafab/attachment.bin>