[m-rev.] Xlib interface for extras

[Ian MacLarty]

>
> On Fri, 24 Sep 2004, Ian MacLarty wrote:
>
>>
>> On 24 Sep 2004, at 10:01, Ralph Becket wrote:
>>
>>> 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.
>>>
>>
>> The majority of impure preds seem to be det, so making these pure
>> should be quite easy. From what I can see there are only 6 types 
>> output
>> from impure semidet preds (display_ptr, drawable, gc, color_ptr,
>> font_struct_ptr and event_ptr), so you'd only need to export 6
>> monomorphic procs to return the maybe types.
>>
>> I still think it'd be better to publish pure code where possible as an
>> example of best practice to anyone who may be looking at the code for
>> guidance on how to implement a pure interface to a foreign API.
>>
> Using impurity to write an interface to a foreign API seems
> a perfectly resonable thing to do; that's one of the things
> it was designed for after all.  I think this is a bit of a non-issue
> as users shouldn't be using the low level impure interface anyway.
>

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.

Ian.

--------------------------------------------------------------------------
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
--------------------------------------------------------------------------