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

[Jonathan Morgan]

On Mon, Jun 23, 2008 at 6:24 PM, Julien Fischer
<juliensf at csse.unimelb.edu.au> wrote:
>
> 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.

Probably true.  I was just thinking you would want systematic naming,
and if you had systematic names it would be possible to automate.

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

Yes.

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

I was actually thinking of prefix and similar things, like is used in
foreign_export_enum.  If those aren't there, I can't think of anything
else.

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

I think you're right - I was just raising the possibility.

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