Mercury Bugs - mercury
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000485mercuryBugpublic2019-09-29 03:542019-09-29 14:05
Reporterjuliensf 
Assigned Tozs 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
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.
Relationships
Attached Files

Notes
(0001048)
zs   
2019-09-29 04:04   
I think the bugs in each extra should be fixed by whoever understands that program
the best.
(0001049)
juliensf   
2019-09-29 04:18   
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.
(0001050)
zs   
2019-09-29 04:31   
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.
(0001051)
juliensf   
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.
(0001052)
zs   
2019-09-29 14:05   
Fix committed 2019 sep 29.

Issue History
Date ModifiedUsernameFieldChange
2019-09-29 03:54juliensfNew Issue
2019-09-29 04:04zsNote Added: 0001048
2019-09-29 04:18juliensfNote Added: 0001049
2019-09-29 04:31zsNote Added: 0001050
2019-09-29 05:05juliensfNote Added: 0001051
2019-09-29 05:05juliensfNote Edited: 0001051bug_revision_view_page.php?bugnote_id=1051#r52
2019-09-29 12:03zsAssigned To => zs
2019-09-29 12:03zsStatusnew => assigned
2019-09-29 14:05zsStatusassigned => resolved
2019-09-29 14:05zsResolutionopen => fixed
2019-09-29 14:05zsNote Added: 0001052