[m-rev.] for review: Correct status of partial instantiation support

[Julien Fischer]

On Wed, 12 Mar 2014, Paul Bone wrote:

> On Wed, Mar 12, 2014 at 01:40:38PM +1100, Julien Fischer wrote:
>>
>> On Wed, 12 Mar 2014, Paul Bone wrote:
>>
>>> For review, does anyone know if there are more places throughout the
>>> documentation that need correcting?  Thanks.
>>>
>>> Branches: master, version-14.01-branch
>>>
>>> ---
>>>
>>> Correct status of partial instantiation support
>>>
>>> In (at least) two places we say that partial instantiation doesn't work or
>>> isn't supported.  To be more correct it works to some extent but is
>>> 'experimental'.
>>
>> Experimental is a bit ambiguous, does it mean that: (1) it doesn't work,
>> (2) it partially works, (3) it works but hasn't been extensively tested?
>> I would prefer to say that support for partial instantiation is
>> incomplete in the current implementation.
>
> That it works but there are some caveats or you may run into bugs.  This is
> my understanding of how well partial instantiation works anyway.

IIRC, the current implementation allows you to construct partially
instantiated terms, but filling in the holes later on will not work.
Given that, they are pretty much useless for any pratical purpose at the
moment.

>>>  Correcting this statement will confuse users of Mercury
>>> less.  (It was pointed out to me by 1-2 people that this had confused them.)
>>
>> What exactly confused them?  That the compiler appeared to accept some
>> programs containing partially instantiated terms without complaining
>> even though the reference manual suggests otherwise?
>
> Pretty much yes.
>
> That the compiler accepts them, that there is code in list.m which defines
> then, but doesn't use them.

There is no code in list.m that uses them; there are only a few insts
that represent partially instantiated lists.  Looking at that section, I
note that some of those insts were marked as deprecated a long time ago,
so we should just delete them.  I my previous mail I suggested deleting
the others, although now I think just moving them out of the library
documentation (i.e. into a "private" interface") section would suffice.

If that's done the documentation for list.m shouldn't need to concern
itself with partial instanatiation at all.

Cheers,
Julien.