[m-dev.] foreign type syntax

Tyson Dowd trd at cs.mu.OZ.AU
Mon Oct 29 23:39:25 AEDT 2001


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? 

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 guess you could be asking whether I plan to eliminate the need to box
and unbox from the other backends .... no such luck I'm afraid ;-) 

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



More information about the developers mailing list