mirror of
https://github.com/Mercury-Language/mercury.git
synced 2026-04-18 10:53:40 +00:00
6f5c716a08
In (at least) two places we say that partial instantiation doesn't work or
isn't supported. This has raised confusion so this patch attempts to
explain what exactly is unsupported and why.
doc/reference_manual.texi:
library/list.m:
LIMITATIONS:
As above.
library/list.m:
Delete deprecated modes.
Move partial instantiation states and modes into a private interface
section. Note all of the instantiation states are partial, some can be
safely used for subtyping so I've left those where they are.
LIMITATIONS:
Include Zoltan's explanation of why this doesn't work for our future
selves and others.
46 lines
1.9 KiB
Plaintext
46 lines
1.9 KiB
Plaintext
|
|
The current implementation does not yet completely implement the
|
|
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:
|
|
|
|
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.
|
|
|
|
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
|
|
not guaranteed to handle the resulting partially instantiated terms
|
|
correctly, simply because they weren't *designed* to. Mantis bug 311
|
|
shows this very clearly. Though I can imagine the different backends
|
|
misbehaving differently on such code. Some may even generate correct
|
|
code by accident :-)
|
|
|
|
This does not affect support for instantiation state subtyping.
|
|
|
|
* The compiler does not yet use structure reuse or compile-time
|
|
garbage collection to exploit unique modes :-(
|
|
|
|
* Type inference and mode inference are a bit imperfect.
|
|
|
|
We hope to eliminate all of these problems.
|
|
|
|
In addition, design decisions in this implementation have imposed the
|
|
following fixed limits:
|
|
|
|
* Predicates and functions can have at most about 1000 arguments.
|
|
|
|
* Higher order terms are limited to arity of about 500.
|
|
|
|
These limits can be lifted (with some effort), but would possibly incur
|
|
performance penalties. Contact the Mercury team (mercury@mercurylang.org)
|
|
if you find these limits are affecting your application.
|
|
|