[m-dev.] io streams

[Michael Day]

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

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?

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

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

> 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. Formatting is currently achieved
by wrapping things in formatting types, for example:

:- type format__int_base
	--->	oct(int)
	;	hex(int)
	etc

	write(hex(32)),		% writes "20"

two of the types are designed to replace io__write and io__write_binary,
and simply wrap any other type:

	write(ascii(T)),
	write(binary(T)),

note, these are not in flux, which is why they're not posted yet. But
that's the general idea.

> P.S.  I hope this was brutal enough for you ;-) ;-)

Not at all, barely scratched the surface. For instance, is it appropriate
to be able to write an 8-bit character to *every* stream? What about a
stream which is actually a string(unicode__char), what does writing a
single character imply? If might not be possible for many implementations
of such a string, and padding the character out to be 16 or 32 bits would
make it impossible to actually write real unicode characters to the
string, a highly undesirable result. There is the non-blocking io that
Robert mentioned and the potential for duplex streams that can seek input
and output points independently. Come on, bring out the claws and teeth :)

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