[m-rev.] Xlib interface for extras

Ralph Becket rafe at cs.mu.OZ.AU
Fri Sep 24 10:01:09 AEST 2004

Ian MacLarty, Thursday, 23 September 2004:
> >
> >That would be a pain.  The xlib module is supposed to be as simple as
> >possible.
> >
> The extras are one of the first places a new Mercury user will look to 
> see how best to implement something, so I think we should be setting a 
> good example with the code we put in extras.  I don't think that making 
> things that do IO impure to hide the IO state threading is the best way 
> to do things.  Nor do I think it makes the code any more readable or 
> writable.  In fact threading IO state through calls requires less 
> typing that making an impure call.

The problem is in reporting failure.  I can't use IO states if I want a
predicate to simply fail in this case.  Alternatively I could export a
bunch of procedures for returning maybe(T) values, one for each T that I
need to be able to return.  Or I could call a polymorphic Mercury
predicate to do the job, but that gets complicated because then I have
to obtain the corresponding type_infos.

After considering all these options, I decided the simplest route was to
use impurity in xlib.m, but present a pure interface in easyx.m.

-- Ralph
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe

More information about the reviews mailing list