mirror of
https://github.com/Mercury-Language/mercury.git
synced 2025-12-14 05:12:33 +00:00
0607c27543
The non-style changes include
- Replacing outdated information with up to date information.
- Deleting fully obsolete information, such as references to the IL backend.
- Replacing list entries that were just bare words or phrases
with full sentences, where this is useful.
- Improvements to make documents easier to read and understand.
However, the bulk of the diff consists of style changes. The initial main
of these changes are to eliminate, or at least reduce, inconsistencies
- between the styles of the different parts of each document, and
- between the styles of differents documents.
This applies both as they appear in a browser, and in the source .html file.
The main style changes are
- Add a vim mode line to each file.
- Do not specify a color for the page background; let the browser decide.
- Add a heading to the top of each page that echoes the title.
- Avoid SHOUTING in headings.
- Avoid the unneeded use of <hr>.
- Avoid the use of headings (e.g. h5) that are so low in the hierarchy that
browsers render them in a font that is *smaller* than the usual font.
- Replace definition lists with standard unordered lists
when the list items are not definitions.
- Replace ordered lists with standard unordered lists
when the list items have no meaningful order.
- Do not indent the contents of unordered lists, with the exception of
nested lists.
- Unless all entries in a list are extremely short,
do not try to put anything next to <li>.
- Fix violations reported by weblint.
compiler/notes/compiler_design.html:
The changes described above.
Explicitly introduce the notion of the middle end.
compiler/notes/bootstrapping.html:
Rewrite this almost from scratch.
compiler/notes/work_in_progress.html:
Rename the page to make it clear that these issues are NOT being
worked on.
compiler/notes/release_checklist.html:
compiler/notes/todo.html:
Note that these lists are quite out of date.
compiler/notes/allocation.html:
compiler/notes/analysis.html:
compiler/notes/bytecode.html:
compiler/notes/c_coding_standard.html:
compiler/notes/coding_standards.html:
compiler/notes/developer_intro.html:
compiler/notes/failure.html:
compiler/notes/gc_and_c_code.html:
compiler/notes/glossary.html:
compiler/notes/grade_library.html:
compiler/notes/index.html:
compiler/notes/interface_files.html:
compiler/notes/mlds_tail_recursion.html:
compiler/notes/overall_design.html:
compiler/notes/promise_ex.html:
compiler/notes/reviews.html:
compiler/notes/trailing.html:
compiler/notes/type_class_transformation.html:
compiler/notes/upgrade_boehm_gc.html:
compiler/notes/Mmakefile:
Add a target to run weblint on all the HTML files.
138 lines
3.5 KiB
HTML
138 lines
3.5 KiB
HTML
<!--
|
|
vim: ts=4 sw=4 expandtab ft=html
|
|
-->
|
|
|
|
<html>
|
|
<head>
|
|
<title>Promise Ex Declarations</title>
|
|
</head>
|
|
|
|
<body>
|
|
|
|
<h1>Promise Ex Declarations</h1>
|
|
|
|
This document is a description of promise ex declarations,
|
|
which are currently unfinished and as such are undocumented
|
|
in the reference manual.
|
|
<p>
|
|
|
|
<h2>Syntax</h2>
|
|
|
|
There are currently three promise ex declarations:
|
|
promise_exclusive, promise_exhaustive, and promise_exclusive_exhaustive.
|
|
They are used to denote determinism properties of a disjunction,
|
|
and denote either exclusivity exhaustiveness or both.
|
|
The examples of each, given below,
|
|
also show the different ways that existential quantification can be handled.
|
|
|
|
<ul>
|
|
<li>
|
|
Mutual exclusivity:
|
|
<pre>
|
|
:- all [X, Y] promise_exclusive
|
|
some [Z] (
|
|
p(X, Y, Z)
|
|
;
|
|
q(X, Y, Z)
|
|
).
|
|
</pre>
|
|
<li>
|
|
Exhaustiveness:
|
|
<pre>
|
|
:- all [X] promise_exhaustive
|
|
(
|
|
p(X, _)
|
|
;
|
|
q(X, _)
|
|
).
|
|
</pre>
|
|
<li>
|
|
Both together:
|
|
<pre>
|
|
:- all [X] promise_exclusive_exhaustive
|
|
some [Y] (
|
|
p(X, Y)
|
|
;
|
|
q(X, Y, Z)
|
|
).
|
|
</pre>
|
|
</ul>
|
|
|
|
All three declarations are restricted in the following ways:
|
|
<ul>
|
|
<li>
|
|
Any variable that occurs in more than one disjunct
|
|
must be explicitly quantified.
|
|
<li>
|
|
Any variable occurring in only one disjunct is existentially quantified.
|
|
This is similarly applicable when an underscore is used in place of a variable.
|
|
</ul>
|
|
<p>
|
|
|
|
<h2>Development</h2>
|
|
|
|
This tracks the use of promise ex declarations through the compiler,
|
|
and may be useful as a quick summary of the current state of development.
|
|
Items marked with an asterisk (*) are not yet implemented.
|
|
Places where data structures etc. have been defined are in italics.
|
|
|
|
<ol>
|
|
<li>
|
|
The declarations enter the parse tree.
|
|
<ul>
|
|
<li>
|
|
<i>The operators are defined</i> (library/ops.m).
|
|
<li>
|
|
<i>The structure for promise ex declarations in the parse tree
|
|
is defined</i> (prog_data.m).
|
|
<li>
|
|
They are parsed and entered into the parse tree (parse_item.m).
|
|
</ul>
|
|
<li>
|
|
They may be pretty printed (mercury_to_mercury.m, parse_tree_out.m).
|
|
<li>
|
|
They are error checked, and entered in to the HLDS as dummy predicates.
|
|
<ul>
|
|
<li>
|
|
Error checking (make_hlds.m).
|
|
<li>
|
|
Entering of declarations into the HLDS as dummy predicates (make_hlds.m).
|
|
</ul>
|
|
<li>
|
|
They go through typechecking as predicates.
|
|
After typechecking they are removed from processing as predicates
|
|
and entered into the appropriate table in the HLDS.
|
|
<ul>
|
|
<li>
|
|
Post typechecking processing initiated for promise ex declarations
|
|
(purity.m).
|
|
<li>
|
|
promise_exclusive and promise_exhaustive declarations
|
|
are indexed by the predicate calls made in them
|
|
in the exclusive table (post_typecheck.m).
|
|
<li>
|
|
<i>Definition of exclusive table as part of HLDS,
|
|
and operations on the table</i> (hlds_module.m).
|
|
<li>
|
|
(*) Where a promise_exhaustive declaration
|
|
is paired with a promise_exclusive declaration,
|
|
they are merged into a promise_exclusive_exhaustive declaration;
|
|
otherwise the promise_exhaustive declaration
|
|
is entered in the exhaustive table of the HLDS (post_typecheck.m).
|
|
<li>
|
|
(*) <i>Definition of exhaustive table as part of HLDS, and
|
|
operations on the table</i> (hlds_module.m).
|
|
</ul>
|
|
<li>
|
|
(*) Exclusivity information is used during switch detection,
|
|
and where it leads to a full switch being made,
|
|
applicable exhaustiveness information is also used (switch_detection.m).
|
|
<li>
|
|
(*) Exhaustiveness information is used
|
|
during determinism analysis (det_analysis.m)
|
|
or as an add-on to switch detection (switch_detection.m).
|
|
</ol>
|
|
|
|
</body>
|
|
</html>
|