2024-11-21 21:07 AEDT
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000538mercuryBugpublic2021-09-13 00:132021-09-13 05:34
Reporterdirkz 
Assigned Tozs 
PrioritylowSeverityminorReproducibilityalways
StatusresolvedResolutionno change required 
Platformmercury-srcdist-rotd-2021-09-08OSmacOS CatalinaOS Version10.15.7
Product Version 
Target VersionFixed in Version 
Summary0000538: Compiler does not recognise a chained subtype definition
DescriptionExample:
========

    % Html content categories modelled as subtypes (simplified)
    % 1. All html elements belong to the base type flow_content
    % 2. Phrasing_content is a subset of flow_content
    % 3. Nesting of a-elements (hyperlinks) is invalid. Neither direct nor
    % indirect nesting is allowed.
    %
:- type flow_content
    ---> p(list(phrasing_content))
    ; div(list(flow_content))
    ; a(list(flow_content_without_a))
    ; text(string).


:- type flow_content_without_a =< flow_content
    ---> p(list(phrasing_content_without_a))
    ; div(list(flow_content_without_a))
    ; text(string).


:- type phrasing_content =< flow_content
    ---> a(list(phrasing_content_without_a))
    ; text(string).


    % 1. Explicitly declared subtype of phrasing_content
    % 2. Implicit subtype of flow_content_without_a, because both share the
    % same base type (flow_content) and the subtype only omits constructor
    % definitions
    %
:- type phrasing_content_without_a =< phrasing_content
    ---> text(string).


Expected result:
================
The module should compile without error.


Actual result:
==============
Compiler error. Mercury does not recognise the implicit (undeclared) subtype
relationship between subtype phrasing_content_without_a and its supertype
flow_content_without_a. The subtype definition is valid, because both share
the same base type (flow_content) and phrasing_content_without_a only omits
constructor definitions of flow_content_without_a.

$ mmc --make subtype
Making Mercury/int3s/subtype.int3
Making Mercury/ints/subtype.int
Making Mercury/cs/subtype.c
subtype.m:036: Error: the first argument of `a' has a type,
subtype.m:036: `list.list(subtype.phrasing_content_without_a)', which is not
subtype.m:036: a subtype of the corresponding argument type
subtype.m:036: `list.list(subtype.flow_content_without_a)' in the supertype.
** Error making `Mercury/cs/subtype.c'.
Steps To ReproduceRun attached Mercury module with:
mmc --make subtype
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0001151

zs (developer)

2021-09-13 05:34

 As you say in the bug report, the attached code gets a compiler error because
"Mercury does not recognise [an] implicit (undeclared) subtype relationship".
This is because Mercury is not *designed* to do so. It pays attention only
to *declared* subtype relationships, and there is no such relationship between
the two types involved in the error, phrasing_content_without_a and flow_content_without_a.

Letting a type have two or more supertypes, such as letting phrasing_content_without_a have both phrasing_content and flow_content_without_a as supertypes, would not be
a bug fix. It would be a new feature, and it would have to be designed as such.
It would certainly require new language rules. At the moment, when each subtype
has exactly one supertype, every subtype-to-supertype chain ends in a unique base type.
If we allowed more than supertype, there would be many possible subtype-to-supertype
chains starting at any given subtype, and we would definitely have to require that
they all end in the same base type. However, other rules may be required as well.
+Notes

-Issue History
Date Modified Username Field Change
2021-09-13 00:13 dirkz New Issue
2021-09-13 00:13 dirkz File Added: subtype.m
2021-09-13 05:34 zs Assigned To => zs
2021-09-13 05:34 zs Status new => resolved
2021-09-13 05:34 zs Resolution open => no change required
2021-09-13 05:34 zs Note Added: 0001151
+Issue History