[m-rev.] Xlib interface for extras

[Julien Fischer]

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.

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