[m-dev.] io streams

[Fergus Henderson]

On 23-Dec-1999, Michael Day <mcda at cat.cs.mu.OZ.AU> wrote:
> 
> > This is more like the Concurrent Clean model where the io__state is
> > split into several sub-states.  For this model to work, and be `det'
> > rather than `cc_multi', you may need to be careful to ensure that the
> > user can't open two output streams that both refer to the same file.
> 
> Is it a problem to be cc_multi? Would it complicate the usage or
> implementation or reduce optimisation? I ask only out of complete and
> total ignorance...

It wouldn't complicate the implementation, and nor would it have any
significant effect on optimization.  It would however complicate the
usage, in two ways:

	- the user would have to propagate the `cc_multi'-ness all the
	  way up to main, i.e. main and lots of predicates in between
	  would have to be declared `cc_multi'

	- writing correct programs would be harder; because the
	  compiler is allowed to reorder I/O to different streams,
	  the user would need to be careful to ensure that they
	  were not accidentally depending on the ordering of
	  output of two streams that happened to be aliased to the
	  same file being interleaved in some particular order.
	  (Note that with your proposed interface, even flushing the
	  streams at appropriate points would not help to ensure
	  that output was interleaved in any particular order.)

> Regarding opening the same file twice, it seems that this cannot be
> avoided at one level or another. For instance, programs that write to
> standard output and standard error. Both just get dumped to the terminal,
> but can be generally screwed with thanks to redirection and even aliased
> to each other. Is it worth checking for that, if such a check is possible?

Perhaps... but if they do turn out to be aliased, what will you do then?

You should find out how Concurrent Clean handles that issue.

At very least there needs to be a simple way for programmers
to enforce a particular order of interleaving of the output to stdout
and stderr.

> > then the compiler might decide to reorder the two calls to write_char,
> > so the eventual output might be `yx' rather than `xy'.
> > On a parallel implementation, it might differ from run to run.
> > Yet main is declared `det', not `cc_multi'.
> 
> So either the stream routines get sprinkled with cc_multi (see question
> above) or I'll try and work out a reasonably sane locking mechanism.

I think the latter is a better approach;
we may want to have "open_unlocked" versions that are cc_multi,
but they would be for more specialized uses, in most cases the
det versions will be the ones that programmers will want.

> > Even worse, the calls to `stream__write_char' are `det', and their
> > output arguments are unused, so the compiler could (and if you
> > use the `--no-fully-strict' option, will) optimize those calls
> > away!
> 
> Yes, sorry about that, you can't close the standard streams yet. All other
> streams I've been toying with have to be closed (joining the stream back
> to its parent io__state) and if you don't close a stream, it sounds
> reasonable for the compiler to optimise away all writes to it :)

Well, in many modern languages you don't have to close files at all;
the system handlers that automatically.  Having the compiler sometimes
optimize away some or all of your output is not a very nice feature.
If we're going to require that users close streams manually, it would
be nicer if we could detect at compile time if they fail to do so.

> > One thing that this interface does not mention is text vs. binary issues.
> > Is this interface intended only for text I/O?
> 
> I am attempting to handle those issues at a higher level, given that they
> seem confined to newline interpretation.

Well, you shouldn't assume that Mercury's `char' type is 8 bits.
We might well change Mercury's `char' type so that it corresponds
to C's `wchar_t' type or some other type for Unicode characters.
If this interface is intended for byte-level I/O, then you should
define a `byte' type and use that, rather than using `char'.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------