[mercury-users] Working with exported types

Julien Fischer juliensf at csse.unimelb.edu.au
Thu Jul 27 17:18:43 AEST 2006


On Thu, 27 Jul 2006, Jonathan Morgan wrote:

> On 7/27/06, Julien Fischer <juliensf at csse.unimelb.edu.au> wrote:
>> 
>> Another approach that I have thought about adding (because doing the above
>> in the OpenGL binding was fairly tedious), is to add a foreign_enum pragma
>> that would allow you to safely use the values of Mercury enums on the other
>> side of the foreign language interface, something like:
>> 
>>         :- type foo
>>                 --->    foo
>>                 ;       bar
>>                 ;       baz
>> 
>>         :- pragma foreign_enum("C", [
>>                 foo - "FOO",
>>                 bar - "BAR",
>>                 baz - "BAZ"]).
>> 
>> The compiler would then add the following to the modules .mh file:
>> 
>>         #define FOO <representation of foo>
>>         #define BAR <representation of bar>
>>         #define BAZ (representation of baz>
>
> Interesting idea.  I have considered a more general export that would
> use functions and deal with any user-defined types.

I've found that the enumeration case crops up frequently enough when
writing bindings to C/C++ libraries that the above sort of thing would
be worth it.

> For something
> like the following:
>
> :- type my_type --->
>   type1(int, int) ;
>   type2(char, int) ;
>   type3(char, string).
>
> I think that the only reasonable way of accessing it is using accessor
> functions like:
>
> :- pred my_type_is_type1(my_type :: in, int :: out, int :: out) is semidet.
> my_type_is_type1(type1(X, Y), X, Y).
>
> :- func my_type_type1(int, int) = type1.
> my_type_type1(X, Y) = type1(X,Y).
>
> Again, this gets verbose, but something more general than foreign_enum
> would be required if you wished to avoid doing it manually.  The
> export would probably have to either have to name all the functions
> (getters and setters), or just name the type.

The export would have to name all the functions anyway: not all valid
Mercury constructor names are valid C names (and you really don't want
to have to rely on names generated by the Mercury name mangler!).

> I would prefer to just name the type, so that pragma
> export_type(my_type, "module_my_type") would give me, for each
> constructor, something like module_my_type_[constructor], which takes
> a set of parameters and constructs the type, and
> module_my_type_is_[constructor], which has a set of out parameters to
> deconstruct the type.  However, this is probably not worth adding to
> the language.

Outside of a few common types like the maybe type the number of times
I have wanted to construct a non-enum Mercury term in foreign code is
very few - I certainly don't think its worth adding to the language.

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



More information about the users mailing list