[m-rev.] for review: reserve builtin inst and mode names

[Zoltan Somogyi]

This diff aims to change the language definition in a small way:
to make it illegal to define an inst or a mode with a name that has
a builtin meaning to Mercury, such as "bound" or "unique". I think
that generating good error messages when using these builtin insts
is MUCH more important than users being able to define new insts
with these names, and the latter interferes with the former.
The reuse of builtin inst and mode names also makes code harder
to read.

There are possible compromises, such as allowing the reuse of
those names but allowing only fully qualifying references to those
reuses, allowing the compiler to assume that any reference to
a known inst constructor such as "unique", *when used unqualified*,
is a reference to the builtin inst constructor and not the user defined
inst name, but I think those would be more complex to explain
and document, and that this extra complexity is not worth it.
However, the addition of the hardcoded/builtin_inst_rename test case,
in 2003 for HAL, indicates that at *some* point, *someone* wanted this
flexibility, though I have no idea why. (At least a fully qualified
reference to the reused name would not be easily confusable
with the builtin, for readers of the code.)

(BTW, the delete of that test case is not in the diff because git rm
doesn't have anything equivalent to git add -N.)

Any opinions? And any opinions about doing the same for type definitions?
E.g. should a user module be able to define ":- type int ---> ..."?

Zoltan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Log.parse_inst_mode
Type: application/octet-stream
Size: 3310 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20150823/1a89f512/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DIFF.parse_inst_mode
Type: application/octet-stream
Size: 64397 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20150823/1a89f512/attachment-0001.obj>