[mercury-users] foreign_decl vs. foreign_code

Fergus Henderson fjh at cs.mu.OZ.AU
Wed Feb 13 03:11:53 AEDT 2002


On 12-Feb-2002, Michael Day <mikeday at bigpond.net.au> wrote:
> 
> > I believe this piece of documentation is wrong, this is not true.
> > Entities declared in foreign_code might not be visible at all.
> 
> In that case, I'm very confused. Consider this:
> 
> typedef int myInt;
> 
> myInt g;
> 
> void foo() { g = 1; }
> 
> How would you encapsulate it in a Mercury module?

	:- pragma c_header_code("
		#ifndef TYPEDEF_myInt_DEFINED
		#define TYPEDEF_myInt_DEFINED
		  typedef int myInt;
		#endif
		extern myInt g;
	").

	:- pragma c_code("
		myInt g;
		void foo() { g = 1; }
	").

You may also want to provide a Mercury interface to this code, e.g.
by defining Mercury procedures (defined using `pragma c_code') to call
foo(), and to get/set `g'.

Note that at the moment I advise using the C interface rather than the
general foreign language interface (e.g. `pragma c_header_code' rather than
`pragma foreign_decl'), because the general foreign language interface is
still under development.  As it says at the start the "Foreign Language
Interface" chapter of the manual:

 | This chapter documents the new foreign language interface.  This
 | interface is not yet complete, and is not fully supported.  It is
 | documented here as an aid to the Mercury language developers.  See the
 | _C interface_ chapter for the existing, supported C interface for
 | Mercury.
 |
 | The syntax, documentation, behaviour and semantics of the constructs
 | described in this chapter are subject to change without notice.

> I originally assumed
> that the typedef and variable definition would belong in a foreign_decl
> and the foo as a foreign_proc. However this caused duplicate definitions
> of g when compiling in hlc.gc.

In general only *declarations*, not *definitions*, should go in
`foreign_decl' or `c_header_code'.

> So I placed the typedef in a foreign_decl
> and the variable in foreign_code, but this caused the variable to be
> invisible to the foreign_proc when compiling in asm_fast.gc. Should I have
> put something like "extern myInt g;" in the foreign_decl?

Yes.

The statement in the Mercury language reference manual about
variables defined in `foreign_code' declarations being visible to
procedures defined using `foreign_decl' is not true, and should be
changed.  At best, it only holds if there are `pragma no_inline'
declarations for those procedures.  Otherwise intermodule inlining
may inline the foreign_proc into a different module, where the
foreign_code is not visible.

> Would this be a
> problem if g was actually static, to avoid conflicts with other modules?

If g was static, you'd need the `pragma no_inline' declarations.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------



More information about the users mailing list