[mercury-users] socket support in io

[Fergus Henderson]

On 02-Oct-1999, Michael Day <mikeday at corplink.com.au> wrote:
> 
> has anyone done any socket programming in Mercury before?

In addition to Mission Critical's work in this area,
the Mercury debugger includes a socket-based interface for
external debugger front-ends.  This is used by Opium-M,
a programmable trace analyzer developed at IRISA in France,
and is also being used by Greg Denehy at Monash, who I think
is developing a GUI front-end to the Mercury debugger.

However, this is really an example of socket programming
in a combination of C and Mercury, rather than in Mercury.
The code for the external debugger interface is included in the
Mercury source distribution, in the file trace/mercury_trace_external.c.
The function MR_trace_init_external() contains the C code to initialize
the sockets, and to create Mercury streams for them.
It then calls some Mercury code defined in browser/debugger_interface.m
to do the parsing of requests received on the socket.  The Mercury code
uses the `io__read' predicate from the `io' module in the standard library
to do the parsing.

> There do not
> appear to be any socket functions in the io module; would it make sense
> for an application to define its own in such a way as to allow use of the
> io routines for acting on binary streams?

Yes.

> However, from what I can see the io module does not appear to have
> inherent support for non-blocking io either. Is it worth an application
> attempting to extend the io module at all, or just carve out its own? Are
> there any significant changes waiting in the future for the io module?

Well, for version 2 of the standard library, we plan to make appropriate
use of typeclasses throughout the library.  In the case of the `io' module,
it would be very useful to define typeclasses for the I/O stream operations.
In particular:

	- we'd be able to define string stream types so that we could
	  treat a string as an input stream or perform I/O to an output
	  stream and capture the result in a string;

	- we'd be able to decouple the counting of line numbers (and in
	  future also column numbers and perhaps page numbers) from the
	  standard io stream types and instead define
	  counted_in_stream/counted_out_stream types for that;
	  this would mean that code which did not require such counting
	  would not have to pay the overheads for that.

	- we'd be able to handle bidirectional streams more elegantly

However, I don't think we have any plans to work on these in the near future.

> thank you for any assistance, we (the WorldForge project,
> www.worldforge.org) are attempting to make use of Mercury in order to
> develop our distributed server ideas. For now I guess I'll dredge through
> what I can find of MCORBA to see if it uses sockets :)

Off-hand, I think MCORBA does not use sockets directly;
it is layered on top of a C++ CORBA implementation, and somewhere
in the guts of that, the C++ CORBA implementation probably uses
sockets, but that isn't going to be of much use to you.

Cheers,
	Fergus.

-- 
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-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------