[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