[m-dev.] foreign type syntax

[Tyson Dowd]

On 30-Oct-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> 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.

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.  It might help efficiency.  So my intention here is that the
implementor can make whatever decisions they like, but anything that
might interest the user should probably be documentated (e.g. if you are
boxing every time you exit foreign code, it would be nice for them to
know about this).

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

Oops.  All a matter of how far the scope of that "never" extends.
But I'll admit that my scope is pretty non-traditional in English usage.

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

Ugh.

-- 
       Tyson Dowd           # 
                            #  Surreal humour isn't everyone's cup of fur.
     trd at cs.mu.oz.au        # 
http://www.cs.mu.oz.au/~trd #
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------