[m-dev.] foreign type syntax

[Fergus Henderson]

On 30-Oct-2001, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> On 30-Oct-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > ... one option would be to just require that this pragma only
> > be used with foreign types that fit in a single word.  This is the
> > "user does the boxing/unboxing" approach, since the user would be
> > forced to manually box/unbox anything that didn't fit in a single word.
> 
> This is in fact all that is implemented right now.
> 
> But I regarded this as NYI, but I guess you could also view it as a
> concious choice to restrict the user and hence eliminate the problem.
> 
> But my intention is to support this.
> 
> > With this option, there's a further choice of whether the implementation
> > is required to report an error if this constraint is violated, or whether
> > violating the constraint just leads to undefined behaviour.
> 
> The current implementation stops you violating the constraint by
> only allowing you to write reference types (well, unless you want to get
> really tricky with your foreign type name).
> 
> > Another option would be to *always* box foreign types, whenever they are
> > used from Mercury; the only time they would be represented as unboxed
> > would be when interfacing with foreign code.  Code to box/unbox them
> > would be inserted in the marshalling wrappers (and nowhere else).
> > 
> > A third option would be to box/unbox foreign values only when
> > they are used in polymorphic data structures or other places
> > that the back-end in question requires uniformly-sized values
> > (e.g. fields, for the high-level C back-end,
> > or both fields and arguments, for the low-level C back-end).
> 
> Ok, this is a distinction I wasn't drawing as I was assuming we *could*
> do either, so it is really just an implementation choice as to which
> makes the most sense.
>
> However, this has no impact on semantics as far as the user is
> concerned.

Not quite.  If the user does any foreign language interfacing
directly with the generated target code that the Mercury compiler
emits for Mercury procedures (rather than via the wrappers that
it emits for procedures explicitly exported using `pragma export'),
then the types used there will be visible to the user.

In the documentation that you posted on mercury-reviews,
this was explicitly documented in the section explaining
how `pragma export' works for the .NET back-end:

| Futhermore, any externally visible Mercury procedure will use
| @var{DotNetForeignType} as the parameter type for parameters with
| @var{MercuryTypeName}.

This requires the implementation to use the third option.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  | "... it seems to me that 15 years of
The University of Melbourne         | email is plenty for one lifetime."
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- Prof. Donald E. Knuth
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------