|View Issue Details [ Jump to Notes ]||[ Issue History ] [ Print ]|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000485||mercury||Bug||public||2019-09-29 03:54||2019-09-29 14:05|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||Fixed in Version|
|Summary||0000485: Various bits of extras not building with rotd-2019-09-28|
|Description||Various graphics library bindings (e.g. the OpenGL one) in extras no longer build due to the fact|
that they contain things like:
:- module foo.
:- type quad_boolean_state ---> color_writemask.
:- pragma foreign_enum("C", quad_boolean_state/0, [
color_writemask - "561"
Building the interface files now results in:
foo.m:008: Error: the Mercury definition of `quad_boolean_state'/0 is not an.
foo.m:008: enumeration type, so there must not be any
foo.m:008: `:- pragma foreign_enum' declarations for it.
foo.m:004: That Mercury definition is here.
|Tags||No tags attached.|
I think the bugs in each extra should be fixed by whoever understands that program
|Why does the compiler think that quad_boolean_state/0 is not an enumeration? Because it's a dummy type? If so, that's wrong, because the presence of a foreign_enum pragma should suppress the dummyness of the type.|
The Mercury definition is a dummy type, and the type as a whole is a dummy type
on every platform on which that foreign_enum is not applicable.
The crux here is that
- enum types have N functors of arity 0
- dummy types have 1 functor of arity 0
so yes, dummy types can be viewed as a special case of enum types
in terms of whether a foreign enum is applicable to them.
The question for me is: when someone writes code like that (Mercury dummy type
paired with a foreign enum with one constant) is it likely to be an error? The type
requires representation on some backends, but not others, which is strange.
I haven't used foreign enums much, so I don't know the answer.
Last edited: 2019-09-29 05:05
This issue arises in the OpenGL, GLFW and Allegro bindings. Since they are all bindings to C libraries the issue of the type requiring a representation on some backends but not others is a non-issue; those bindings cannot be meaningfully compiled with the other backends anyway.
The information conveyed by such types is the foreign value of the functor. In the example I gave above, even though quad_boolean_state only has a single value in Mercury, the functions that use it in C can take many other values -- in Mercury, we represent those other values are represented using other enum types.
Another reason this may arise is due to a library binding being incomplete.
Both the code in extras and not treating foreign_enums as dummy types is intentional.
|Fix committed 2019 sep 29.|
|2019-09-29 03:54||juliensf||New Issue|
|2019-09-29 04:04||zs||Note Added: 0001048|
|2019-09-29 04:18||juliensf||Note Added: 0001049|
|2019-09-29 04:31||zs||Note Added: 0001050|
|2019-09-29 05:05||juliensf||Note Added: 0001051|
|2019-09-29 05:05||juliensf||Note Edited: 0001051||View Revisions|
|2019-09-29 12:03||zs||Assigned To||=> zs|
|2019-09-29 12:03||zs||Status||new => assigned|
|2019-09-29 14:05||zs||Status||assigned => resolved|
|2019-09-29 14:05||zs||Resolution||open => fixed|
|2019-09-29 14:05||zs||Note Added: 0001052|