2020-07-09 10:43 AEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000485mercuryBugpublic2019-09-29 14:05
Assigned Tozs 
PrioritynormalSeverityminorReproducibilityhave not tried
Product Version 
Target VersionFixed in Version 
Summary0000485: Various bits of extras not building with rotd-2019-09-28
DescriptionVarious graphics library bindings (e.g. the OpenGL one) in extras no longer build due to the fact
that they contain things like:

    :- module foo.
    :- interface.

    :- type quad_boolean_state ---> color_writemask.

    :- implementation.

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

TagsNo tags attached.
Attached Files




zs (developer)

I think the bugs in each extra should be fixed by whoever understands that program
the best.


juliensf (administrator)

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.


zs (developer)

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.


juliensf (administrator)

Last edited: 2019-09-29 05:05

View 2 revisions

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.


zs (developer)

Fix committed 2019 sep 29.

-Issue History
Date Modified Username Field Change
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
+Issue History