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

Julien Fischer jfischer at opturion.com
Mon Aug 24 15:34:27 AEST 2015


Hi Zoltan,

On Sun, 23 Aug 2015, Zoltan Somogyi wrote:

> 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.

Agreed.

> 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.)

Presumably because things in HAL had very similar names?   It hardly
matters now in any case since HAL is not an on going thing.

> (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 ---> ..."?

Builtin types: yes.

Standard library types: definitely not (just in case you were thinking
of that too!)

The diff looks fine.

Cheers,
Julien.



More information about the reviews mailing list