[m-rev.] for review: rewrite of Modes chapter
Mark Brown
dougl at cs.mu.OZ.AU
Mon Feb 24 01:13:37 AEDT 2003
On 23-Feb-2003, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> I thought the "is at least as instantiated" and "matches" orderings
> in Mark's proposed text were corresponding to inst_matches_initial
> and inst_matches_final respectively. If that is not the case, then I
> need to review the change again.
"Matches" does correspond to inst_matches_final, but "is at least as
instantiated as" doesn't correspond to inst_matches_initial; in
particular, the uniqueness ordering condition is reversed, whereas for
inst_matches_initial the uniqueness ordering condition should be the same.
Looking back, it seems the following part of the change relating to
implied modes is wrong:
On 20-Feb-2003, Mark Brown <dougl at cs.mu.OZ.AU> wrote:
> In Mercury it is always possible to call a procedure with an
> -argument that is is more bound than the initial inst specified for that
> +argument that is more instantiated than the initial inst specified for that
> argument in the procedure's mode declaration. In such cases, the
> compiler will insert additional unifications to ensure that the
> argument actually passed to the procedure will have the inst
> specified.
According to the definition I have given, 'ground' is more instantiated
than 'unique'. But it shouldn't be possible to call a procedure with
'ground' where 'unique' is expected, so the instantiatedness order is not
the right order to use here -- inst_matches_initial would be correct.
(I took this definition of implied modes from the thesis draft, so I think
the same error occurs there.)
If, on the other hand, I changed the definition of the "instantiatedness"
order to correspond to inst_matches_initial, then the other uses of it
would be incorrect (e.g., the definition of "compatible" relies on it
staying as it is). So I'm going to need to think again about what
partial order(s) would be most useful to present the material that we
want to present. I'll post a full diff after doing that, and addressing
the above issue.
Cheers,
Mark.
--------------------------------------------------------------------------
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