[m-dev.] for discussion: proposed additions to FFI

[Julien Fischer]

On Mon, 23 Jun 2008, Jonathan Morgan wrote:

>
> I like the idea of the new pragmas, but they raise a few questions in
> my mind (especially with the frequent comparisons with
> foreign_export_enum).
>
> 1. Is it possible to automatically generate names, prefixes and so
> forth, and then use prefixes and overrides, like foreign_export_enum?
> Otherwise most du types will need a lot of foreign declarations to
> export them completely, and I imagine most of the time you would want
> the export to be either complete or close to it.

Since you have to use a separate pragma for each data constructor anyway
there doesn't seem much point in allowing automatically generated names.

I envisaged this feature be used primarily with types that have only
a small number of constructors - e.g. maybe/0, maybe_error/0 the kind
of things that result in small integers being passed across the 
boundary of the foreign language interface in foreign language bindings.

For larger types there is a point where it is going to be easier
to manipulate the type drectly in Mercury.

> 2. Does this proposal handle dummy types?  If not, will the
> documentation say so?

There is no reason that dummy types could not be handled, although
pragma foreign_export_enum would be a better solution in that case.
(And testing and deconstructing dummy types is obviously a bit
pointless.)

> 3. Are there going to be any other attributes governing the pragmas,
> like there are for some other foreign pragms?

What do you have in mind?

> 4. Will the exported procedures be thread-safe?  [this becomes
> important when you are using them to write foreign procedures].

Yes, I think so -- testing and construction are and I can't think
of where deconstruction wouldn't be.  (In any case the
thread_safe/not_thread_safe attribute of the calling foreign_proc will
apply as normal.)

> 5. With the proposed C semantics, will you get similar results from:
>
> if(deconstruct_constructor1(mercury_var, &param1, &param2, &param3))   {
> // Do something.
> } else if(deconstruct_constructor2(mercury_var, &param1, &param2, &param3))   {
> // Do something else.
> }
> ...
>
> as from
>
> if(test_is_constructor1(mercury_var)) {
>  deconstruct_constructor1(mercury_var, &param1, &param2, &param3)
>  // Do something.
> } else if(test_is_constructor2(mercury_var)) {
>  deconstruct_constructor2(mercury_var, &param1, &param2, &param3)
>  // Do something else.
> }

Yes.

> ...
>
> 6. Will you ever want to be able to do something like:
> switch(get_constructor(mercury_var))  {
>    case CONSTRUCTOR1:
>         deconstruct_constructor1(...);
>    case CONSTRUCTOR2:
>         deconstruct_constructor2(...);
>        ...
> }
>
> I think that the other form, testing for an individual constructor,
> will work better, but it could be more lengthy and less possible to
> produce a complete switch, and it won't be verified by the compiler
> (though if you want that, you might want to do it in Mercury anyway).

That would also require generating the enumerated constants.  It could
be done, but I think that sort of thing is getting close to the
pointer where I would implement it in Mercury.

Julien.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au
--------------------------------------------------------------------------