[m-rev.] for review: foreign enumerations

[Ian MacLarty]

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

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