[m-dev.] string streams and formatting

[Michael Day]

> 	p(X) :-
> 		write(text("hello")),
> 		write(X).
> 
> what happens?  And what happens if in another module which imports
> mytype I write:

Then you've imported two modules that define the same functor. The usual
module qualification rules apply here and I don't see how that is a
relevant issue. All predicate and functor names have the chance of
colliding; the module system arbitrates it nicely.

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

Similarly here, purely a module qualification issue.

> 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.

It is not. Say you want to write out *any* term in canonical form, right
aligned on an 80 character wide terminal.

write(right(80, text_term(T)))

where T is *any* term. It works. It's easy. It's extensible. I've changed
the name to `text_term' as you think `text' is a bit too generic.

> 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).

The name can be changed if it's felt to be necessary. What I'm really
looking for here is comments on the approach I've taken towards output,
replacing write and write_binary with a single write. It works for me.
Does it have any crippling flaws that other people can see? Is it too hard
to use? Is it unclear? Is it inflexible?

Michael

--------------------------------------------------------------------------
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
--------------------------------------------------------------------------