[mercury-users] Paper on Mercury from AI practitioner's standpoint

Ralph Becket rafe at cs.mu.OZ.AU
Fri Jan 14 09:54:43 AEDT 2005


Gregory D. Weber, Thursday, 13 January 2005:
> Hi, thanks for the comment.  I do not understand, though --
> what are "unsafe" I/O predicates?  I do not find any predicates
> in the io module that do not require a pair of io__state arguments.
> Which predicates are you referring to, and what is unsafe about
> them?

Many people write an "unsafe" module for just the situation you found
yourself in (see the attachment).

If I could offer some comments about your paper:

(1) I don't think the title matches the content.  The paper describes
your experiences implementing a non-trivial algorithm in a language with
which you are somewhat unfamiliar.  I didn't feel the paper was saying
much specifically about AI programming.

(2) Re: IO, there's nothing wrong with side effects per se, but you have
to ensure that the part of your program that reflects what's happening
in the outside world (i.e., the part that does IO) doesn't do anything
inconsistent with that relationship (e.g., backtrack over IO or copy the
IO state).  

(3) As Ian pointed out, the Mercury debugger probably does have just the
right functionality for your debugging needs.  I certainly agree that we
need a "Debugging Mercury for Beginners" document, but, in my
experience, you have to have a pretty strange problem to need to resort
to peppering your code with unsafe IO.

(4) I got the impression your experience was similar to mine when I was
porting a SPEC95 benchmark to Mercury.  It was very easy to write a
working Mercury program that ran slowly.  Profiling identified the
hotspots and the changes were (in my case) fairly simple.  For me, this
is one of the attractive features of Mercury.  I always found
post-profiling optimisation much harder work in imperative languages
(and, if we're honest, a great deal of Scheme code is imperative).

(5) Do you have an abstract specification of the algorithm you
implemented?  I'd be curious to have a go myself without seeing the C or
Scheme versions and see if I arrived at the same solution as yourself.

Cheers,
-- Ralph
-------------- next part --------------
%------------------------------------------------------------------------------%
% unsafe.m
% Ralph Becket <rafe at cs.mu.oz.au>
% Wed Jan 30 11:10:10 EST 2002
% vim: ft=mercury ff=unix ts=4 sw=4 et tw=0 wm=0
%
% Unsafe IO.
%
%------------------------------------------------------------------------------%

:- module unsafe.

:- interface.

:- import_module io, list, string.



    % Support arbitrary unsafe IO operations without the need to
    % thread the IO state in.  Intended largely for debugging only.
    %
:- pred io(pred(io, io)).
:- mode io(pred(di, uo) is det) is det.

    % Useful shortcuts for writing debugging messages.
    %
:- pred format(string, list(io__poly_type)).
:- mode format(in, in) is det.

:- pred format(output_stream, string, list(io__poly_type)).
:- mode format(in, in, in) is det.

:- pred print(T).
:- mode print(in) is det.

:- pred print(output_stream, T).
:- mode print(in, in) is det.

%------------------------------------------------------------------------------%
%------------------------------------------------------------------------------%

:- implementation.

%------------------------------------------------------------------------------%

io(P) :- P(unsafe_io_state, _).

%------------------------------------------------------------------------------%

format(Fmt, Args) :- io(io__format(Fmt, Args)).

format(Stream, Fmt, Args) :- io(io__format(Stream, Fmt, Args)).

%------------------------------------------------------------------------------%

print(T) :- io(io__print(T)).

print(Stream, T) :- io(io__print(Stream, T)).

%------------------------------------------------------------------------------%

:- func unsafe_io_state = io.
:- mode unsafe_io_state = uo is det.

:- pragma foreign_proc(
    "C",
    unsafe_io_state = (_IO::uo),
    [will_not_call_mercury, thread_safe, promise_pure],
    ""
).

%------------------------------------------------------------------------------%
%------------------------------------------------------------------------------%


More information about the users mailing list