[m-dev.] for review: add Mission Critical extensions

[Peter Ross]

On Sun, Jul 09, 2000 at 04:59:36PM +1000, Simon Taylor wrote:
>  
> > > > runtime/mercury_library_types.h:
> > > >     If MISCRIT_STREAMS is defined use the Mission Critical version of
> > > >     the type MercuryFile.  The new definition of MercuryFile makes it
> > > >     possible for Mercury to handle streams connected to sockets and
> > > >     pipes under WinNT.  The MercuryFile structure now contains pointers
> > > >     to functions to do the basic operations on streams, which allows
> > > >     them to be changed according to the type of stream.
> > > >     All this extra functionality is then hidden behind macros,
> > > >     allowing the original definition of MercuryFile to coexist.
> > > 
> > > Isn't this useful for users other than Mission Critical?
> > > 
> > However sockets and streams are read/write which means that input and
> > output streams need to be equivalent.  This is a change to the interface
> > of the io library, and may lead to less type safe code.
> 
> This was addressed in Fergus' review of Paul Massey's changes
> (the original review is in the mercury-developers archive for February 1998).
> The only problem with not exporting the equivalence of io__input_stream
> and io__output_stream was that we needed multiple identical versions
> of some predicates to convert between file descriptors and the
> various types of streams.
> 
Thanks for the pointer, Paul didn't tell me he had already had these
changes reviewed.

> Given that we already have `io__close_output', `io__close_input',
> `io__close_binary_input' and `io__close_binary_output' (all with
> the same implementation) I don't see what is the problem with doing
> the same for the `fd_to_stream' and `stream_to_fd' predicates.
> It's not ideal, but it's better than not having socket support.
> It's _much_ better than hacking in half of the support and
> leaving the other half only usable by one company.
> 
I agree with you.  I was waiting for Fergus opinion on these changes and
how much of them he wants integrated into the compiler.  The ideal
solution is all of them, but I have a feeling that it will not be that.
So I factored out as much code as possible.

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