[m-rev.] for review: subtypes
novalazy at gmail.com
Tue Jan 7 14:18:03 AEDT 2014
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)
; 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.
More information about the reviews