[mercury-users] Working with exported types

[Julien Fischer]

On Thu, 27 Jul 2006, Peter Wang wrote:

> On 2006-07-27, Julien Fischer <juliensf at csse.unimelb.edu.au> wrote:
>>
>> On Thu, 27 Jul 2006, Peter Wang wrote:
>>
>>> On 2006-07-27, Ralph Becket <rafe at csse.unimelb.edu.au> wrote:
>>>> Julien Fischer, Thursday, 27 July 2006:
>>>>> 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>
>>>>
>>>> This would be an excellent addition to the FLI.
>>>
>>> Can we get something in the opposite direction as well?
>>
>> What exactly do you mean?  The above also handles the opposite direction.
>
> Does it?

It depends on what you mean by "opposite direction".

> I'm interested in importing C constants *into* Mercury, without going
> through the contortions you've gone through in the OpenGL binding.  At the
> moment the easiest way to do that is to hard-code the value into the Mercury
> code, but that's brittle.  The second easiest way is probably to introduce a
> foreign proc for each C constant, but that's tedious.

The foreign_proc approach is what we use in the GLUT binding, and yes, it's
extremely tedious.

I think what you are after is the ability to do something like:


 	:- type matrix_mode
 		--->	texture
 		;	modelview
 		;	projection.

 	:- pragma foreign_enum("C",
 		[ texture    - "GL_TEXTURE",
 		  modelview  - "GL_MODELVIEW",
 		  projection - "GL_PROJECTION"
 		]
 	).

where the representation of texture is GL_TEXTURE, modelview is GL_MODELVIEW
etc.

Allowing users to assign values to Mercury enumerations, which is what
directly implementing the above would require, is going to be tricky.
Also, to be useful I think that in most cases you are going to want the
values to be #defined constants (think library bindings here).  It isn't
impossible but it's (most likely) going to be quite a bit of work to 
implement (more so than the simpler version of foreign_enum).

An alternative here is to allow types with the foreign_enum pragma to
automatically construct a pair of translation functions that map between the
Mercury representation and the foreign representation.  For types with these
pragmas the compiler would insert calls to the translation functions at the
foreign code boundary.   (Basically doing what we do in the OpenGL binding
now except that it would all be automatically generated.)

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