[mercury-users] socket support in io

[Juergen Stuber]

Fergus Henderson <fjh at cs.mu.OZ.AU> writes:
> > 
> > I think it would be a good idea to split std_util into separate
> > modules, one for each type, even if these get rather small.
> > Often I need only one of them, and it is easier to always use
> > the name of the type also for the module than to remember they
> > are in std_util.
> 
> For `unit' and `maybe_error', having a separate module containing only
> the type definition seems a bit like overkill to me.

I may seem as overkill to put unit in a separate module,
but as a user I think it is easier to write
:- import_module unit.
than to remember that unit is in std_util.  

> But I agree there
> is a good case for putting `univ', `pair' and `maybe' in separate modules.

Yes.  Most of the time it's pair or maybe that I need, and more than
once I have written
:- import_module pair.
before the compiler reminded me that this is wrong.

> (The maybe_error/0 and maybe_error/1 types could go in the `maybe' module.)

Yes, that sounds good.

> > Also I would like to see the builtin types `character', `int',
> > `float', and `string' treated like any other type; they should be
> > qualified by some module, preferably the corresponding module of the
> > standard library.  This would make things more consistent and allow
> > to reuse their names (say for unicode__character).
> 
> The original rationale for treating the builtin types specially was
> because the constants of those types are treated specially.  It would
> be somewhat inconsistent to allow the literals `42', `"foo"', to be
> used without importing any module, but not to allow their types to be
> used without importing any module.
> 
> But the builtin types do indeed have module qualifiers -- they can be
> referred to as `builtin__int', `builtin__float', `builtin__string', and
> `builtin__character'.  The only difference is that the module `builtin'
> is automatically imported into every module.  You can reuse the names,
> so long as you use module qualifiers to avoid ambiguity -- that is, you
> can define a `unicode__character' type, you just can't refer to it as
> `character'.

Aha.  When I tried that some time ago I got the impression it
wasn't possible to use a type named `character' at all.

> Perhaps you would like something analagous to Haskell's
> `import qualified Prelude', i.e. a way to prevent the automatic
> import of the module `builtin'?

That would be nice.

Jürgen

-- 
Jürgen Stuber <juergen at mpi-sb.mpg.de>
http://www.mpi-sb.mpg.de/~juergen/
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------