[m-dev.] diff: update documentation of existential types bugs

[Fergus Henderson]

Estimated hours taken: 0.25

doc/reference_manual.texi:
	Update the documentation about bugs with the implementation
	of existential types:
		- RTTI for existential types is now supported
		- document the problem with reordering better

Workspace: /d-drive/home/hg/fjh/ws-hg2/mercury
Index: doc/reference_manual.texi
===================================================================
RCS file: /home/mercury1/repository/mercury/doc/reference_manual.texi,v
retrieving revision 1.161
diff -u -d -r1.161 reference_manual.texi
--- doc/reference_manual.texi	1999/12/13 12:25:11	1.161
+++ doc/reference_manual.texi	1999/12/13 13:27:33
@@ -3587,9 +3587,6 @@
 @node Existentially typed data types
 @section Existentially typed data types
 
-Note: existentially typed data types are not yet fully supported.
-See @ref{Known bugs in the current implementation} for details.
-
 Type variables occurring in the body of a discriminated union type
 definition may be existentially quantified.  Constructor definitions
 within discriminated union type definitions may be preceded by
@@ -3769,17 +3766,23 @@
 The current implementation does not properly deal with most cases
 that involve both existentially quantified constraints and
 mode reordering due to the modes of type variables.
-The symptom in such cases is spurious mode errors.
-The solution is to write such code in the correct order manually
-rather than relying on the compiler's mode reordering.
+Note that this can easily arise if you're using nested function calls.
+The symptom in such cases is usually spurious mode errors,
+or sometimes internal compiler errors of the form
 
-We have not yet implemented RTTI (run-time type information) support
-for existentially quantified data types.  This means that many of
-the procedures in the Mercury standard library will not work for
-values of those types.  Functions affected include for example
- at samp{io__write}, @samp{io__read}, @samp{std_util__construct},
-and @samp{std_util__deconstruct}.  Likewise, the Mercury debugger
-does not yet support such types.
+ at example
+Software error: map__lookup: key not found
+Key Type: prog_data:class_constraint
+Key Functor: constraint/2
+Value Type: hlds_data:constraint_proof
+ at end example
+
+ at noindent
+The work-around is to write such code in the correct order manually
+rather than relying on the compiler's mode reordering.
+For nested function calls, you may need to split them up using
+temporary variables, e.g. instead of @samp{X = f(g(Y))},
+write @samp{G = g(Y), X = f(G)}.
 
 @node Semantics
 @chapter Semantics

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------