[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