[m-rev.] for review: Clearly explain what part of partial instantiation isn't supported.

Paul Bone paul at bone.id.au
Mon Mar 17 13:44:45 AEDT 2014


On Mon, Mar 17, 2014 at 11:30:11AM +1100, Julien Fischer wrote:
>> diff --git a/doc/reference_manual.texi b/doc/reference_manual.texi
>> index a7a34b2..fc6bbfc 100644
>> --- a/doc/reference_manual.texi
>> +++ b/doc/reference_manual.texi
>> @@ -2540,9 +2540,11 @@ can do so by simply defining them using a mode declaration:
>> These two modes are enough for most functions and predicates.
>> Nevertheless, Mercury's mode system is sufficiently
>> expressive to handle more complex data-flow patterns,
>> -including those involving partially instantiated data structures.
>> -(The current implementation does not handle
>> -partially instantiated data structures yet.)
>> +including those involving partially instantiated data structures, data
>> +structures with ``free'' @emph{holes} in them.
>
> I suggest:
>
>    i.e.@: data structures with ``free'' @emph{holes} in them.
>

Is the "@" symbol sagnificant?

>> diff --git a/library/list.m b/library/list.m
>> index 102edb6..91d25fc 100644
>> --- a/library/list.m
>> +++ b/library/list.m
>> @@ -34,32 +34,23 @@
>>
>> %-----------------------------------------------------------------------------%
>>
>> -    % Some declarations for complicated modes using lists.
>> -    % (Note that partial instantiation is not currently supported.)
>> -
>> +    % These instantiation states and modes can be used for instantiation
>> +    % state subtyping.
>> +    %
>> +    % They could also be used for partial instantiation but partial
>> +    % instantiation does not work completely.  Mercury's mode system does
>> +    % not attempt to perform alias tracking.  Therefore filling in the
>> +    % 'holes' of a partially instantiated data structure may not work as
>> +    % expected, when this appears to work it is only by chance.  Furthermore
>> +    % partial instantiations are not supported on the Erlang backend at all.
>> +    % Additionally most existing code is not instantiation state polymorphic
>> +    % (for example the standard library itself).
>> +    %
>
> I don't think this explanation belongs here.  (If here, why not everywhere else
> we define such insts?  e.g. in the maybe module etc.)  I think the confusion
> you refer to above could be resolved in this case simply by deleting the
> reference to partial instantiation entirely.  (If you really want to keep it
> then replace the above with pointer to the LIMITATIONS file.)

Okay.

>
> Shift this hidden interface section so that it occurs just after the first `:-
> implementation' declaration in the module (as with other such hidden interfaces
> in the library).
>

Okay.

Thanks.

-- 
Paul Bone



More information about the reviews mailing list