[m-rev.] for review: subtypes
novalazy at gmail.com
Wed Jan 8 17:27:01 AEDT 2014
On Tue, 7 Jan 2014 20:15:05 +1100, Mark Brown <mark at mercurylang.org> wrote:
> On Tue, Jan 7, 2014 at 6:23 PM, Peter Wang <novalazy at gmail.com> wrote:
> > On Tue, 7 Jan 2014 17:08:06 +1100, Mark Brown <mark at mercurylang.org> wrote:
> >> > If I'm not mistaken, container types could not be abstract exported.
> >> That's right. In none of these examples could the data structure be
> >> abstractly exported, since Mercury does not support abstract insts.
> >> The workaround in parsing_utils.m would still be needed.
> >> In the first two versions, that roadblock would at least be more
> >> obvious, since the insts are explicit.
> > In the alternative design, is that because you mean to export 'first'
> > and 'non_empty_cord(T)'? If 'non_empty_cord(T)' is not exported, then
> > the type 'cord(T)' can still be abstractly exported, right?
> No, I don't think it can. At least, I'm not sure what would go in the
> interface files.
> If the inst information is not passed on to importing modules, then
> they could indeed subvert the mode system using exactly the technique
> that you mention below.
I think I understand. So importing modules wouldn't work with 'ground'
cord values, but with the inferred inst because the cord type refers to
a subtype. The inferred inst is part of the cord module's interface.
A predicate argument with type cord(T) and mode 'in' is treated as
'inferred_inst >> inferred_inst', and mode 'out' is treated as
'free >> inferred_inst'.
I was imagining that importing modules would still work with 'ground'
cord(T) values, so the module interface remains unchanged. Where the
compiler can see a type declaration referring to subtypes, it can use
that information to infer more precise insts for functor arguments,
% C is ground
C = cord.list(L)
% C is bound(list(bound([ground | ground])))
% L is bound([ground | ground])
More information about the reviews