[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 02:18:53PM +1100, Julien Fischer wrote:
>>>
>>> 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.
>
> I'm pretty sure I've used this and it worked in the C backends.  I think the
> issue might have been the Erlang backend.
>
> https://github.com/Mercury-Language/mercury/blob/master/mdbcomp/feedback.m#L98
>
> I remember that this piece of code was contentious because it prevented
> Mercury from being built in the Erlang grade.  But AFAIK it works in the C,
> C# and Java grades.

I suspect that specific code only "works" in those grades more by luck
than design.  In general, it does not work.

(Not working in the Erlang grade was one reason that piece of code was
contentious; the other, IIRC,  was simply that it would be more straightforwad
without using partial instantiation anyway.)

>>>>>  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.
>
> That's what I said.
>
>> 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.
>
> Okay, since they're unused I don't see a problem with that.

Only the deprecated ones should be removed.

> Perhaps they should be moved to samples/ as an example of how to use
> partial instantiation?

Why provide an example of it?  As I said, it's not useful at the moment.
I think hiding the confusing definitions should be sufficient.  (I
wouldn't delete them as I think they're may possibly be test cases for
the constraint based mode analyser that use them.)

Cheers,
Julien.