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

Julien Fischer juliensf at csse.unimelb.edu.au
Wed Feb 7 01:40:00 AEDT 2007

On Tue, 6 Feb 2007 doug.auclair at logicaltypes.com 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?

The exact meaning of not_thread_safe is described in the
``Foreign code attributes'' section of the reference manual.

>> 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
>> future.
> 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).

We are not phasing out support for interfacing with C (in fact the language
reference requires that Mercury implementations have an interface to C).

We are phasing out support for one of the interfaces to C (we have two),
specifically the one described in section 14, ``C Interface'' of the
reference manual in favour of the one described in section 13, ``Foreign
language interface'').  One of the foreign languages in the context of
section 13 is C.  (The current plan is that support for all of the stuff in
section 14 will be removed after the 0.14 release.)

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

pragma foreign_proc.

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

In my view it's not sufficiently different from pragma foreign_proc to
warrant that.

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