[m-dev.] string streams and formatting

[Peter Schachte]

> > >     1.  binary
> > >     2.  term
> > > 	a.  machine readable (output is guaranteed to be readable by the
> > > 	    appropriate read predicate)
> > > 	b.  human readable (may include type-specific output formats,
> > > 	    may be depth-limited, etc.)
> > > 	c.  formatted output (with field widths, radix setting,
> > > 	    paragraph filling, etc, all controlable for individual
> > > 	    components)
> > > 	d.  displayed (operators not respected, like display/1 in Prolog)
> > >     3.  graphical (text is printed with different fonts, bitmaps are
> > >         displayed, constructors are provided for laying out
> > > 	collections of these things, etc.)

> And to summarize the proposed stream formatting:
> 
> 	1.	write(binary(T))
> 	2.a.	write(text(T))
> 	2.b.	 - no proposal yet -
> 	2.c.	write(centre(.., write(right(.. and so forth
> 	2.d.	 - no proposal yet -
> 

I really think it's important to have a *separate* predicate or type
class method for each of these distinct output purposes.

Suppose I define

	:- mytype ---> ..., text(string), ....

and I import your writable type class.  If I write the goal

	p(X) :-
		write(text("hello")),
		write(X).

what happens?  And what happens if in another module which imports
mytype I write:

	q :- p(text("hello")).

what does q output?  And what if I also include my type in the
writable type class?

It seems to me that writing things in form 1, 2a, 2b, and 2d are
mostly straightforward operations that just emit any term they are
given, and require little formatting control (just a depth limit for
2b).  These should each have a single predicate the perform them,
using the names Fergus posted.  Form 2c and 3 require complex
formatting control.  1, 2a, 2b, and 2d should not be mixed with 2c and
3, because the need for flexible formatting control in the latter case
is likely to conflict with the need to be able to write *any* term in
the former.

> Not knowing `display' in Prolog I have not proposed it, if not respecting
> operators means it writes them out without applying them, I don't see how
> I can do that in Mercury.

It just means everyting is written in functor(argument,argument,...)
form.  Eg, display([x+y,f(z)]) prints out

       .(+(x, y), .(f(z), []))

It's occasionally useful, but not a high priority.

> Note: write is not a standard library predicate. It is a type class
> method. I've said this a few times now, but I get the feeling that it is
> thought I have some horrendous write predicate that somehow does
> *everything*... maybe I'm just being paranoid.

I just don't see how that matters.  If you import the module that
defines that type class, your version of write will seem more or less
like a predicate, and will conflict with io__write if that is also
imported (which is likely).

-- 
Peter Schachte                     The universe is full of magical things,
mailto:schachte at cs.mu.OZ.AU        patiently waiting for our wits to grow
http://www.cs.mu.oz.au/~schachte/  sharper.
PGP: finger schachte at 128.250.37.3      -- Eden Phillpotts 
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------