Mercury Bugs - mercury
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000556mercuryBugpublic2022-04-06 12:102022-04-07 12:56
Reporterjuliensf 
Assigned Tozs 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0000556: Stage 2 compiler does not build with --intermod-opt -O5 and rotd-2022-04-04
DescriptionFrom testing.mercurylang.org

fact_table.m:2543: error: the user defined inst
fact_table.m:2553: error: the user defined inst
fact_table.m:3400: error: the user defined inst
building of stage 2 compiler not successful

In non-truncated form it is:

fact_table.m:2543: In the second argument of predicate `get_hash_table_type'/2:
fact_table.m:2543: error: the user defined inst
fact_table.m:2543: `ll_backend.fact_table.key_char'/0
fact_table.m:2543: is declared to be applicable only to values of type
fact_table.m:2543: `char.char'/0,
fact_table.m:2543: but here it is applied to values of type
fact_table.m:2543: `character'/0.
fact_table.m:2553: In the third argument of predicate
fact_table.m:2553: `get_hash_table_type_loop'/3:
fact_table.m:2553: error: the user defined inst
fact_table.m:2553: `ll_backend.fact_table.key_char'/0
fact_table.m:2553: is declared to be applicable only to values of type
fact_table.m:2553: `char.char'/0,
fact_table.m:2553: but here it is applied to values of type
fact_table.m:2553: `character'/0.
fact_table.m:3400: In the fifth argument of predicate
fact_table.m:3400: `generate_hash_lookup_code'/7:
fact_table.m:3400: error: the user defined inst
fact_table.m:3400: `ll_backend.fact_table.key_char'/0
fact_table.m:3400: is declared to be applicable only to values of type
fact_table.m:3400: `char.char'/0,
fact_table.m:3400: but here it is applied to values of type
fact_table.m:3400: `character'/0.

It looks like equivalence types are not being expanded in insts correctly.




TagsNo tags attached.
Relationships
Attached Files

Notes
(0001187)
zs   
2022-04-06 15:18   
I started fixing this by expanding type_ctors in inst definitions,
but realised that this is wrong approach. The reason is that the inst
will (in virtually all cases) contain function symbols of the named type,
and thus makes sense only if the user who wrote the inst knows the
ultimate expansion of the "for typector". If they know it, why not write it?

Therefore I propose to fix this bug in two ways.

- Replace char with character in the inst definition in fact_table.m.

- Add code that detects when the "for type_ctor" part of an inst defn
  is an equivalence type, and generates a version of the error messag
  above that mentions this fact.
  
Any objections?
(0001188)
juliensf   
2022-04-06 15:37   
I don't have any particularly strong objections. Your proposed fix does introduce a certain lack
of uniformity with respect to how equivalence types are treated by different parts of the language.
(It's probably not too bad in presence of an error message describing what is wrong.)

As to "if they know, why not write it?", I think this bug answers that question. It wasn't written because the equivalence type is the preferred name for the type in question. When deprecating a type name we quite often start by introducing an equivalence that defines the new name and then swapping them around later, before finally (after a respectable interval) deleting the original name. (That isn't quite the story with character / char, but it's close.)

Another reason a user may have used char instead of character here, is that they may have read the library documentation. It is fairly emphatic on the point:

    Originally we used `character' rather than `char' for the type name
    because `char' was used by NU-Prolog to mean something different.
    But now we use `char' and the use of `character' is discouraged.
(0001189)
zs   
2022-04-07 12:56   
Fix committed 2022 apr 7.

Issue History
Date ModifiedUsernameFieldChange
2022-04-06 12:10juliensfNew Issue
2022-04-06 12:22zsAssigned To => zs
2022-04-06 12:22zsStatusnew => assigned
2022-04-06 15:18zsNote Added: 0001187
2022-04-06 15:37juliensfNote Added: 0001188
2022-04-07 12:56zsStatusassigned => resolved
2022-04-07 12:56zsResolutionopen => fixed
2022-04-07 12:56zsNote Added: 0001189