mercurylang/mercury
1
0
Fork 0
mirror of https://github.com/Mercury-Language/mercury.git synced 2026-04-15 01:13:30 +00:00
Code Issues Projects Releases Wiki Activity

Clarify some explanations.

Browse Source
This commit is contained in:
Zoltan Somogyi
2021-07-25 01:57:02 +10:00
parent de1d35257f
commit dfe46bb31b
1 changed files with 16 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
LIMITATIONS
View File

@@ -1,19 +1,23 @@
The current implementation does not yet completely implement the
Mercury language. The main limitations of the current implementation
Mercury language. The main limitations of the current implementation
are the following:
* We do not allow definite aliasing in the mode system. Without this,
partially instantiated modes are unusable, and so are nested unique modes
:-( When partial instantiation appears to work it is only by chance. The
detailed explanation is:
* We do not allow definite aliasing in the mode system. That is, we do not
allow the unification of two free variables. Without this, partially
instantiated terms (i.e. terms which contain both function symbols and
free variables) are unusable, and so are nested unique modes :-(
When partial instantiation appears to work, it is only by chance.
The detailed explanation is:
If you unify a variable and an argument of a term, then when either the
variable or the argument is bound, the other should be bound to the same
thing. In the absence of alias tracking, this won't happen. The only
situation in which this is ok is if "the other" does not exist anymore,
which the current compiler can be sure about only if its scope is
restricted to the unification.
If you unify a free variable (say X) and an argument of a term
which is also free at the time (say the third argument of g in g(a, b, Y)),
then when either the variable X or the argument Y is bound, the other
should be bound to the same thing. In the absence of a recorded
alias between X and Y, this won't happen. The only situation in which
this is ok is if "the other" does not exist anymore, which the current
compiler can be sure about only if its scope is restricted to the
unification (i.e. if whichever of X and Y is "the other" appears
*only* in the unification, and nowhere else).
Even for code in which a free variable's scope is confined to its
unification with a free variable in a term, the code generators are