[m-rev.] for review: subtypes

[Peter Wang]

On Mon, 6 Jan 2014 17:46:48 +1100, Mark Brown <mark at mercurylang.org> wrote:
> Hi Peter,
> 
> On Mon, Jan 6, 2014 at 2:19 PM, Peter Wang <novalazy at gmail.com> wrote:
> > On Tue, 31 Dec 2013 05:05:15 +1100, Mark Brown <mark at mercurylang.org> wrote:
> >> Hi everyone,
> >>
> >> I have had a shot at implementing something along the lines of the old
> >> subtypes proposal. It is for review by anyone. The log message is
> >> attached, and the diff can be found at
> >>
> >> https://github.com/markbrown/mercury/
> >>
> >> in the subtypes branch. Please note I am not currently subscribed to this list.
> > ...
> >>
> >> Another design issue is that subtypes are currenly only allowed to be used
> >> in pred and func declarations (including typeclass methods).  Alternative
> >> designs could include:
> >>
> >> (1) Allowing subtypes to be used in ordinary type declarations, inferring a
> >> ground inst for every type that refers, directly or indirectly, to a subtype.
> >
> > This seems a major restriction.
> 
> Indeed, I hit it already in parsing_utils.
> 
> Do you think the alternative is better? I mentioned some concerns
> about it already, so I wanted feedback before looking further.

I would find subtypes much more useful then.

Could `cord' be written like this?

    :- type cord(T)
        --->    empty
        ;       unit(T)
        ;       list(nonempty_list(T))
        ;       branch(nonempty_cord(T), nonempty_cord(T)).

What do you mean by "inferring a ground inst ..."?

> >  I think the main use I would have for
> > subtypes is to recover the inst of a value after passing through some
> > container (which doesn't use polymorphic modes).
> 
> That's what polymorphic modes are for. Why don't you want to use them?
> 
> (I guess the real question is why the standard library doesn't provide them.)

I tried polymorphic modes on a small example; it didn't work :(
If I'm not mistaken, container types could not be abstract exported.

> >
> > construct would be even more complicated, no doubt.
> 
> The types in type_desc currently provide access to type information
> only, not inst information. I wasn't planning to change that at all,
> even in the alternative design, so construct, etc, won't be affected.

construct should not be able to subvert the type declaration, though.

Peter