[m-dev.] foreign type syntax

[Fergus Henderson]

On 29-Oct-2001, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> On 29-Oct-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > On 25-Oct-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > > On 25-Oct-2001, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> > > > We propose adding a foreign_type pragma, which allows you to define a
> > > > Mercury type as being equivalent to a foreign language type. 
> > > 
> > > What happens if the foreign language type doesn't fit in a single word?
> > > Will the Mercury compiler automatically box/unbox it, like it does for `float'?
> > 
> > I didn't see any answer to this question.
> > 
> > I guess this means that you have no idea what the answer should be ;-)
> > 
> > It would help to know what the intended semantics are when deciding
> > on the syntax...
> 
> I'm not sure I understand the question -- let me explain why:
> 
> If the implementation requires non-word sized structures to be
> boxed/unboxed, then the implementation must do that.
> We clearly don't intend foreign_type to be buggy.
> Therefore we have to box/unbox foreign types.
> 
> There is no choice here, so I don't understand the question.
>
> What could be the other choice? 

Well, 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.
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.

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

> If the backend never requires a uniform size representation (e.g.
> everything is a word) then you don't have to box.  But as far as I know
> every backend requires a uniform representation at some points (although
> high-level data may someday completely eliminate it).

I think the "everything is a word" example is in fact an example of the
opposite.  But if I ignore the example then what you say makes sense ;-)
You're right that every backend requires a uniform representation
at some points.  Since Mercury supports parametric polymorphism,
this is not going to change as a result of --high-level-data.

[Eliminating boxing for polymorphically typed arguments or fields
would require more radical changes, such as compiling to a target
language that supports generics (such as C++ or ILX) and preserving
the polymorphism in the translation, or doing C++ template-style
code expansion (which would require run-time code generation to do
completely in the presence of polymorphic recursion and dynamic loading).]

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