[m-dev.] string streams and formatting

[Peter Schachte]

On Fri, Jan 14, 2000 at 10:13:16PM +1100, Michael Day wrote:
> >     1)  I wouldn't call this "write."  I think write should either write
> > 	terms (cf Prolog) or raw data (cf C).
> 
> Given that this is neither Prolog nor C, I felt at liberty to attempt to
> make it capable of both, and more. To be precise, write is a type class
> method belonging to types that satisfy the writable type class and how
> they choose to represent themselves is entirely their own business.

I don't think this is enough.  I can see a need for all of the
following kinds of output:

    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 no doubt more.  I think each of these really needs to have a
different predicate (or type class method) name.  Fergus wrote up a
document describing most of these a few years back.  I assume the
predicate/method you're proposing is meant to cover 2c.  I think
"write" is the right name for 2a, and "print" is good for 2b, and
"display" for 2d, so you shouldn't use any of those names.  "format,"
which would have been the obvious choice, is already used in the
standard library so seems like a bad idea.  That's why I suggested
"output," though I don't like it very much.

> It is not actually a change at all to the current library, it is rather an
> addition.

Unless this new predicate/method is pretty much a backward compatible
reimplementation, I don't think you should use the same name.

> I chose read and write over
> input and output because of their simplicity and because readable and
> writable don't rip the flesh from my bones in the same way that inputable
> and outputable do.

Granted, "inputable" and "outputable" are horrible, but I don't think
those are actually the right concepts.  I think what you're talking
about here are formats, so the class should probably be called
"format" or something similar.  The distinction is between 2b and 2c
above.  Eg, when I execute

	write(hex(13))

does it output

	a

or

	hex(13)

I'll want each (and several others) in different circumstances.

> >     3)  Most importantly:  for several reasons, I think the best way to
> >         handle this is using a format type class

> Hmm perhaps I should have extended the preface to the code I posted
> earlier, this is more or less what I've done.

Cool.

-- 
Peter Schachte                     Many men stumble across the truth, but
mailto:schachte at cs.mu.OZ.AU        most manage to pick themselves up and
http://www.cs.mu.oz.au/~schachte/  continue as if nothing had happened.
PGP: finger schachte at 128.250.37.3      -- Winston Churchill 
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------