[m-dev.] foreign type syntax

Tyson Dowd trd at cs.mu.OZ.AU
Tue Oct 30 00:02:58 AEDT 2001


On 29-Oct-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> On 29-Oct-2001, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> > If you specify the types using C syntax, you are going to have a bit of
> > a hard time marshalling them to and from asm (you won't know how to
> > generate type specifications in gcc's tree representation without
> > parsing the type specifications).
> 
> What's wrong with just using `gcc__ptr_type_node' for all such types, and
> handling the marshalling needed by generating appropriate C code in the
> C wrapper function that we generate for C `pragma foreign_proc' procedures?

As I said:

> > I wouldn't be shocked if you could hack around this by using lots of
> > hacky casts and some sneaky interfacing code, but it might be nice if
> > you don't have to...

I think this solution falls into the hacky casts category.

The problems are that it forces the user to box non-word sized values,
and constrains the implementation such that it cannot carry the exact
type, even if it otherwise would be able to.

For the C backend it isn't such a big deal because everybody does hacky
casts all the time, it often costs you nothing, and having the exact
type around doesn't often help the compiler at all.  But for other
backends (.NET, Java) it does, because casts are checked.

If you want to you could specify the type as a string -- there is no
reason we can't support both.  Specifying a string has other advantages.

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