[mercury-users] socket support in io

[Fergus Henderson]

On 03-Oct-1999, Michael Day <mikeday at corplink.com.au> wrote:
> 
> Right I've looked through that file a little actually as gcc 2.95.1
> collapses with an internal error when it tries to compile it. I had to
> comment out a small portion of the code that checks for a unix socket
> environment variable or similar, to be able to build it. (I'm assuming
> that's a gcc error, the code looks fine...)

We'd certainly appreciate bug reports for that kind of thing;
we can forward them to the gcc maintainers if appropriate,
and we can often include work-arounds in future releases of the
Mercury implementation, so that other Mercury users don't have to
deal with the same problem.

> > 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:
> 
> <nice features snipped>
> 
> Must admit I'm very interested in this next version, sounds like iostreams
> done properly with a language that doesn't get in the way.
> 
> > However, I don't think we have any plans to work on these in the near future.
> 
> Perhaps next year?

Yes, perhaps.  Currently we're working towards finishing off the
few things that we want to do before we can call it Mercury 1.0.
And we're also doing some work on developing a new back-end,
and improving the debugger, and adding existential types, and so on.
So we're just not ready to take on a major new task like incorporating
type classes into the standard library yet.

> The standard libraries appear to be something that
> Mercury users could have slightly more input in than language features.
> Seems like it wouldn't hurt to have a list of the proposed alterations to
> the standard libraries, so that users that need that functionality now
> could perhaps develop their own modules and contribute them at some point?

Well, here's the things I have on my list:

	- Move the library into sub-modules of a single module `std'

	- Make appropriate use of type-classes throughout the library

	- Move the RTTI stuff from std_util.m into a separate module

	- Add a hash table library (hash_map and perhaps also hash_set);
	  but this really requires getting nested unique modes to work first.

> Just a suggestion, don't know if you prefer development to be more
> controlled than that.

No, if anyone feels like starting work on version 2 of the standard
library now, that would be great as far as I'm concerned.  Just make sure
to let us know what you're doing via mercury-developers at cs.mu.oz.au;
that way, we can offer feedback, advice, code reviews, and so forth,
to ensure that the development proceeds in such a way that we'll all
be happy with the end result.

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