[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