[m-rev.] for review: parsing and pretty printing of promise ex declarations
Fergus Henderson
fjh at cs.mu.OZ.AU
Tue Feb 5 15:43:53 AEDT 2002
On 01-Feb-2002, Lars Yencken <lljy at students.cs.mu.oz.au> wrote:
>
> compiler/prog_data.m:
> Changed assertion constructor in type item to a more gereral
s/gereral/general/
> To avoid confusion:
> - a `promise ex declaration' refers to one of the new
> promise_exclusive, promise_exhaustive or
> promise_exclusive_exhaustive declarations
> - an `assertion' refers to one of the old `:- promise'
> declarations
> - a `promise' refers to a declaration of either of the above
> types, and should be used when it concerns both of them
It would be a good idea to add these to compiler/notes/glossary.html.
> +++ compiler/mercury_to_mercury.m 1 Feb 2002 01:17:40 -0000
> @@ -613,9 +613,18 @@
> "check_termination")
> ).
>
> -mercury_output_item(_, assertion(Goal, VarSet), _) -->
> - io__write_string(":- promise "),
> +mercury_output_item(_, promise(PromiseType, Goal, VarSet, UnivVars), _) -->
> { Indent = 1 },
> + ( { PromiseType = true } ->
> + io__write_string(":- promise ")
> + ;
> + io__write_string(":- all ["),
> + { AppendVarNum = no },
> + mercury_output_vars(UnivVars, VarSet, AppendVarNum),
> + io__write_string("]"),
> + mercury_output_newline(Indent),
> + prog_out__write_promise_type(PromiseType)
> + ),
Why don't you output the `all [UnivVars]' quantifier for assertions?
That looks like a bug to me.
(If there is a good reason for this, it should be documented in comments here.)
> +++ compiler/prog_data.m 1 Feb 2002 02:28:32 -0000
> @@ -89,6 +91,12 @@
...
> +:- type promise_type
> + ---> exclusive
> + ; exhaustive
> + ; exclusive_exhaustive
> + ; (true).
"true" doesn't need to be in parentheses.
There should be some comments here explaining what these are for
(especially the "true" alternative).
Since the new declarations are not yet documented in the language
reference manual, it would be a good idea to include in the comments
here the URL of the appropriate email(s) in the Mercury mailing list
archives where these language features were proposed. Or, even better,
the description of this language feature could be put in a file in
compiler/notes, together with some notes about which parts are implemented
and which parts are not yet implemented.
Otherwise that looks fine. Please post both a relative diff and a new full
diff when you have addressed these comments.
P.S. Looking at your change to modules.m, I noticed that the current
module system implementation will have problems with allowing promise ex
declarations in the interface section of a module unless they are
restricted to only refer to procedures defined in that module.
--
Fergus Henderson <fjh at cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-reviews mailing list
post: mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------
More information about the reviews
mailing list