[m-rev.] Xlib interface for extras
Ralph Becket
rafe at cs.mu.OZ.AU
Fri Sep 24 14:59:32 AEST 2004
Ian MacLarty, Friday, 24 September 2004:
>
> Well looks like I'm out-voted, but I still think impurity is being
> abused here. At least for the det impure procs in xlib.m. For example
> I see no reason why xlib.flush should be impure. It seems silly to
> hide the IO state in xlib.flush, but then introduce it again in
> easyx.flush. It's confusing and inconsistent, especially for a newbie
> like me who's reading the code. It doesn't matter that I'm not going
> to use xlib directly - I might still be interested in how it was
> implemented.
What you are suggesting is that xlib.m should present a pure interface,
but to do so would require more complicated C code.
Instead I have chosen to handle the complexity at the Mercury level in
easyx.m.
I understand what you're saying, and arguments can be made either way,
but I would say that that in this case an impure xlib.m/pure easy.m
design is the simpler one.
-- 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