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

doug.auclair at logicaltypes.com doug.auclair at logicaltypes.com
Wed Feb 7 01:09:20 AEDT 2007

Dear Jonathan, you wrote:

>I would have thought this should not be a problem, as the functions
>you refer to are marked `not_thread_safe'.  This should mean that, if
>the library is built in a parallel grade, access to these functions
>are guarded by a Mercury generated mutex, and thus are perfectly
>thread safe.

Okay, that's great, and I didn't know that.  Should my warning be
removed from the README?

>I also observe that you use the old C interface.  In general, this
>carries the caveat that support may be phased out for it in the

Yes, I read that in the docs, but, really, I see C support as something
so vital to any language that I find it hard to believe that the Mercury
team would phase out that support for the present (extending into
the long-term future where C still plays a role -- when C becomes
like COBOL, then I can see such support dropped).

> In this case, you also use `pragma import'.  A discussion on
>mercury-reviews when specifying `pragma foreign_export' came to the
>conclusion that `pragma import' was not used, and so the new foreign
>language interface is not likely to include support for this.

Okay, I don't subscribe to that list -- what should I use instead
of the import pragma to get what I need into Mercury?  In other words,
I interface with a lot of foreign (specifically, C) code, all the time; and that 
code is not to be changed (so, for example, I'm not going to embed it into
Mercury source code), is there something that is equivalent to 'pragma
import' in the new foreign interface?  If not, can it be retained in the new

Doug Auclair

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

More information about the users mailing list