dde8c1f396
This functor was intended to have the same semantics as free/0, while
containing the type of the value it was applied to. However, commit
87e7e3bafa, the commit in which Fergus
introduced this function symbol, also contained an "XXX temporary hack"
in which the code that was supposed to create a value using this function
symbol when propagating a type into a free/0 inst, just ignored the type,
and left the inst as free/0. THIS TEMPORARY HACK HAS REMAINED IN THE CODE
SINCE 1994.
In a few places, we did hand-create insts using free/1 for code created
by the compiler itself. However, as far as I can tell, no free/1 inst
ever described any code read in from source files. This meant that
any code in switch arms for free/1 in switches on insts was never tested
in any meaningful sense. And predicates such as inst_merge_4, which
processed several kinds of insts without doing a complete switch on insts,
simply lacked code handle free/1 at all.
This diff deletes the free/1 function symbol. It does so NOT because
the type stored as its argument is not useful, but because it is useful
NOT JUST for free insts, but for ALL insts. This means that any mechanism
for providing information about the type of the value that an inst applies to
should work for all insts. This can be done
- either by passing along the type with every inst, and stepping into
the argument types of each argument of a function symbol as we process
bound insts, in every operation that operates on insts that needs
type information.
- or by including a type in ALL the function symbols of the inst type.
(We could do this either by adding a maybe(mer_type) field to each
function symbol, which would be "no" before the propagate-types-
into-modes pass, or by adding just a mer_type field, which would
be a special dummy value before that pass. I (zs) prefer the latter,
and so would juliensf.)
The second option would involve reintroducing a free/1 function symbol
into the inst type, but this would replace the existing free/0
function symbol, and it would inherit all the code that currently
handles free/0, NOT the code being deleted by this diff for handling
the *current* free/1.
The first option would be easier to implement if only one or maybe two
operations needed type info, the second would be both easier to implement
and more efficient if more operations needed that info.
compiler/prog_data.m:
Delete free/1.
compiler/add_mode.m:
compiler/add_mutable_aux_preds.m:
compiler/comp_unit_interface.m:
compiler/dep_par_conj.m:
compiler/direct_arg_in_out.m:
compiler/equiv_type_hlds.m:
compiler/error_msg_inst.m:
compiler/float_regs.m:
compiler/hlds_code_util.m:
compiler/hlds_out_goal.m:
compiler/hlds_out_mode.m:
compiler/hlds_statistics.m:
compiler/inst_abstract_unify.m:
compiler/inst_check.m:
compiler/inst_match.m:
compiler/inst_merge.m:
compiler/inst_mode_type_prop.m:
compiler/inst_test.m:
compiler/inst_user.m:
compiler/inst_util.m:
compiler/mode_constraints.m:
compiler/mode_errors.m:
compiler/mode_top_functor.m:
compiler/modecheck_coerce.m:
compiler/modecheck_util.m:
compiler/modes.m:
compiler/module_qual.qualify_items.m:
compiler/parse_tree_out_inst.m:
compiler/parse_tree_to_term.m:
compiler/pd_util.m:
compiler/prog_mode.m:
compiler/prog_rep.m:
compiler/recompilation.usage.m:
compiler/types_into_modes.m:
compiler/unused_imports.m:
compiler/xml_documentation.m:
Conform to the change above.
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.