[m-rev.] for review: foreign enumerations

[Julien Fischer]

On Fri, 10 Aug 2007, Ian MacLarty wrote:

> On Thu, Aug 09, 2007 at 06:28:50PM +1000, Julien Fischer wrote:
>>
>>  The changes to RTTI and tabling are for review by Zoltan.
>>  The rest is for review by anyone.
>>
>>  Estimated hours taken: 50
>>  Branches: main
>>
>>  Add support for foreign enumerations to Mercury.  These allow the
>>  programmer to assign foreign language values as the representation of
>>  enumeration constructors.
>>
>>  e.g.
>>  	:- type status
>>  		--->	optimal
>>  		;	infeasible
>>  		;	unbounded
>>  		;	unknown.
>>
>>  	:- pragma foreign_enum("C", status/0, [
>>  		optimal    - "STATUS_OPTIMAL",
>>  		infeasible - "STATUS_INFEASIBLE",
>>  		unbounded  - "STATUS_UNBOUNDED",
>>  		unknown     - "STATUS_UNKNOWN"
>>  	]).
>>
>>  The advantage of this is that when values of type status/0 are passed to
>>  foreign code (C in this case) no translation is necessary.  This should
>>  simplify the task of writing bindings to foreign language libraries.
>>
>>  Unification and comparison for foreign enumerations are the usual
>>  unification and comparison for enumeration types, except that the default
>>  ordering on them is determined by the foreign representation of the
>>  constructors.  User-defined equality and comparison work also work.
>>  on foreign enumeration types.
>>
>>  In order to implement foreign enumerations we have to introduce two
>>  new type_ctor representations.  The existing ones for enum type do not
>>  work since they use the value of an enumeration constructor to perform
>>  table lookups in the RTTI data structures.  For foreign enumerations
>>  we need to perform a linear search at the corresponding points.  This
>>  means that some RTTI operations related to deconstruction are more
>>  expensive.
>>
>>  The dummy type optimisation is not applied to foreign enumerations as
>>  the code generators currently initialise the arguments of non-builtin
>>  dummy type foreign_proc arguments to zero.  For unit foreign enumerations
>>  they should be initialised to the correct foreign value.  (This is could be
>>  implemented but in practice it's probably not going to be worth it.)
>>
>
> Does this mean that if I have the type:
>
> :- type open_mode
>    --->    read.
>
> :- pragma foreign_enum("C", open_mode/0, [
> 	read    - "MODE_READ"
> ]).
>
> then when I pass a value of this type to foreign code it will always
> have the value 0 instead of MODE_READ?

No, it means the opposite, i.e. it will have the value MODE_READ.
That's why I said, "For unit foreign enumerations they should be
initialised to the correct foreign value.".

> I might want to look at the
> value of this type, because I may be planning to extend it with more
> options (for example a 'write' option) in future.  So I think
> initialising the value to the correct foreign value would definitely be
> worth it.

I agree; that's why it does that ;-)

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