[mercury-users] announced: libtiff foreign interface (caveats)

[Ondrej Bojar]

Julien Fischer wrote:
>>> BTW, you really should make some of your predicates take I/O states and
>>> return error codes.
>>
>> Peter, as for using !IO, I understand the idiom well enough within
>> pure Mercury code I suppose, but I don't see an application here.
>> Moreover, if callers do not have the !IO handle locally, then it seems
>> to me to increase the burden on them (requiring them to pass
>> around an !IO just to access the protocol).
> 
> But they are doing I/O by calling them.

An additional comment from another Mercury user:

Yes, Doug, please *do* add io.state to predicates where the intended use 
is to perform io. I have written several interfaces to bi-pipe connected 
processes or to some strange file types. My first versions of the code 
always ignored io.state, as you're doing, but as soon as I started 
heavily using it (or Mercury made another leap in code compilation where 
purity is promised), the interface got broken. I ended up with all my 
interfaces rewritten and mentioning io where appropriate. And all 
modules depending on this had to be changed to get the io to them.

When IO is what you want to do, users should be forced to supply a world 
to perform the IO on. When IO is a necessary trick hidden well under the 
predicate's surface, I prefer hiding it to the user. An example I have 
is "memoization to disk":

:- pred call_or_load_from_cache(pred(T, S), T, S).
:- mode call_or_load_from_cache(pred(in, out), in, out) is det.

The cache is surely stored somewhere on the disk (hardwired in 
call_or_load_from_cache), but given the inner predicate is pure, knowing 
it's input we can just reuse an older output and never call the 
predicate again (saving some cycles).

(In fact, the implementation of this caching I have actually takes 
io.state and passes it to the predicate -- just to be a bit more general.)

I also do not mind hiding IO in cases where some information from IO is 
obtained (e.g. hostname), but the application never makes use of such 
information in flow control, only e.g. some output is annotated with 
such details. Hostname is just a special constant.

Thanks for publishing you libraries!

Ondrej.

> 
>> Would you edify me with
>> more detail as to what you mean?  What are the advantages of
>> requiring an io state for this protocol?
> 
> 
> You need to tell the compiler that these procedures have side effects.
> Otherwise, for one thing, it may decide that it can optimize them away
> (if for example it deduced that they are logically equivalent to true).
> 
> In Mercury there are two main ways of specifying that something has
> side effects, threading the I/O state through the calls or by using
> impurity annotations.
> 
> Julien.
> --------------------------------------------------------------------------
> mercury-users mailing list
> Post messages to:       mercury-users at csse.unimelb.edu.au
> Administrative Queries: owner-mercury-users at csse.unimelb.edu.au
> Subscriptions:          mercury-users-request at csse.unimelb.edu.au
> --------------------------------------------------------------------------
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users at csse.unimelb.edu.au
Administrative Queries: owner-mercury-users at csse.unimelb.edu.au
Subscriptions:          mercury-users-request at csse.unimelb.edu.au
--------------------------------------------------------------------------