[m-dev.] for discussion: pragma foreign_import

[Fergus Henderson]

On 03-Dec-2001, Peter Ross <peter.ross at miscrit.be> wrote:
> Following fjh's previous suggestion here is what the syntax will look
> like for the IL backend.
> 
> :- func cos(float) = float.
> :- pragma foreign_import(il, cos(in) = out,
> 		".method public static float64 Cos(float64)"

Shouldn't this use the IL syntax for class method references (e.g.
for `call' or `ldftn' instrunctions), rather than the IL syntax for
method definitions?

i.e. something more like

	:- pragma foreign_import(il, cos(in) = out,
		"static float64 [mscorlib]System.Math.Cos(float64)"
	).

>
> The only problem that I see with this syntax is that nowhere do we mention
> the assembly which Cos() is contained in.  This information is not needed
> to generate a call to the Cos method,

??  Yes it is, isn't it??

> but is needed so that we make sure
> that we generate a .assembly directive in the IL file.
> 
> Any suggestions about how we avoid that problem?
> 
> My initial plan was to place that information in the il term, but fjh doesn't
> like that idea.
> 
> Anyway thoughts welcome.
> 
> diff -u reference_manual.texi reference_manual.texi
> --- reference_manual.texi
> +++ reference_manual.texi
> @@ -4843,10 +4843,107 @@
>  code using @samp{pragma foreign_proc}.
>  
>  @menu
> +* pragma foreign_import::       Importing foreign functions.

s/function/procedure/

>  * pragma foreign_proc::         Defining Mercury procedures using foreign code.
>  * Foreign code attributes::   	Describing properties of foreign
>  				functions or code.
>  @end menu
> +
> + at node pragma foreign_import
> + at subsection pragma foreign_import
> +
> + at example
> +:- pragma foreign_import(@var{Lang},
> +		@var{Pred}(@var{Mode1}, @var{Mode2}, @dots{}),
> +                @var{Attributes}, "@var{Name}").
> + at end example
> +
> +or
> +
> + at example
> +:- pragma import(@var{Lang},
> +		@var{Func}(@var{Mode1}, @var{Mode2}, @dots{}) = @var{Mode},
> +		@var{Attributes}, "@var{Name}").
> + at end example

s/pragma inport/pragma foreign_import/

> + at noindent
> +imports a function in the foreign language specified by @var{Lang}
> +for use by Mercury.

s/function/procedure/g

> + at var{Pred} or @var{Func} must specify the name of a previously declared
> +Mercury predicate or function, and @var{Mode1}, @var{Mode2}, @dots{},
> +and (for functions) @var{Mode} must specify one of the
> +modes of that predicate or function.
> +There must be no clauses for the specified Mercury procedure;
> +instead, any calls to that procedure will be executed by calling
> +the function specified by @var{Name}.

s/the function/the foriegn language procedure/

> +The @var{Attributes} argument is optional; if present,
> +it specifies properties of the given function
> +(@pxref{Foreign code attributes}).

s/function/procedure/g

> +The interface to the function for a given Mercury procedure is
> +determined as follows.
> +Mercury types are converted to foreign types according to the rules in
> + at ref{Data passing conventions}.
> +Mercury arguments declared with input modes
> +are passed by value to the function.
> +Mercury arguments declared with output modes
> +are passed by reference.

This is really language-specific.  The section on "Data passing
conventions" is part of the C interface documentation and only describes
what happens for the C interface, not for other languages.
And output arguments will definitely not be passed by reference for the
Java interface, for example.

Same applies to the remainder of this section,
e.g. the comments about io__states not being passed
because I/O is done via side effects should not be
true for the Haskell or Clean interface.

The semantics need to be divided into language-specific and
language-independent parts.

-- 
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-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------