compiler/typecheck_error_overload.m:
When reporting type a type ambiguity that is itself an error
(as opposed to being problematic *only* because it increases
the number of type assigns needed), do NOT use terminology
that implies that the problem is the sheer number of ambiguities.
Indeed, the main test case of this code, bad_ambiguity_msg,
involves just one predicate name that has two matches,
which is the lowest possible level of ambiguity that
deserves an error message.
The old code used this bad terminology becaused it reused
the code of the function that reported exceededing the
ambiguity warning limit. Another effect of this bad reuse,
apart from the bad wording of the always-printed message,
was the addition of a verbose-only hint about the way to fix
the excessive ambiguity, which is totally misleading in this
situation.
In the absence of this reuse, we can now simplify the operation
of the code that generates warnings and errors about too much
overloading.
In some cases, eliminate some repetition in the diagnostic text.
tests/invalid/Mercury.options:
Specify the printing of verbose-only parts of diagnostics.
With this enabled, the inappropriateness of the reuse
would have been immediately apparent.
tests/invalid/bad_ambiguity_msg.err_exp:
Expect the updated wording. Do not expect a reminder about
any verbose-only part, since now there is none.
tests/invalid/coerce_ambig.{m,err_exp}:
Test for reporting not just one variable being ambiguous,
but also for two variables being ambiguous. (Together,
these exercise both paths through the relevant code.)
Mercury
Mercury is a logic/functional programming language which combines the clarity and the expressiveness of declarative programming with advanced static analysis and error detection features.
More information is available on the website's about pages, in other README files in the source code repository, and in the documentation.
Small sample programs written in Mercury can be found in the samples and extras directories of the source code repository.
README files
The Mercury compiler has two different backends and works on different operating systems. Specific information is contained in individual README files:
-
Bootstrapping discusses how to get Mercury installed.
This is important, as the Mercury compiler is written in Mercury.
-
C Low-level backend
This backend works well with GCC but also works with:
-
High-level backend targets
-
Supported operating systems
-
Other platform information
Other information
See the current release notes for the latest stable release. The news file lists any recent changes. The history file is relevant if you want to find out more about the past development of Mercury. The limitations file lists some ways in which the Mercury implementation does not yet meet its goals.
Information for developers
If you are considering contributing to the Mercury project, the website contains some documents that may be helpful. These include a document about contributions in general and specific information about contributing such as coding styles.
Contact
See our contact page.