[m-dev.] Existentially quantified data constructors

Peter Ross pro at missioncriticalit.com
Thu May 8 15:04:22 AEST 2008


On Mon, Apr 21, 2008 at 3:15 PM, Julien Fischer
<juliensf at csse.unimelb.edu.au> wrote:
>  On Mon, 21 Apr 2008, Ian MacLarty wrote:
> > Well, suppose you have the typeclass:
> >
> > :- typeclass set(Set, Element) <= (Set -> Element)
> >
> > then all you need to uniquely identify the instance is the type of the
> > first argument, so instances like:
> >
> > :- instance set(set_ctree234(T), T)
> >
> > should be allowed.
> >
> > I tried modifying the algorithm for generating the name of the global
> > variable that holds the base typeclass info.  I modified it so that if a
> > variable appeared in the instance type list, it just used the string "T"
> > in that position.  This then allows me to use instances like the one
> > above.
> >
> > If we relax the instance restrictions in the following way:
> >
> > 1. Arguments may be variables as long as they only appear in the range
> >  of a functional dependency (i.e. don't appear in the domain of a
> >  functional dependency, or outside a functional dependency).
> > 2. Duplicate variables are allowed as long as there are only two
> >  occurences of the duplicated variable, with each occurance being in a
> >  separate argument position, and those argument positions having a
> >  functional dependency between them.
> >
> > then we would be able to define a lot of useful instances that we can't
> > now, without weakening our current ability to detect overlapping
> instances.
> >
> > Here is my experimental diff, along with a program with some
> > instances we can't have now that compiles and runs after applying the
> > diff.
> >
> >
> > Is it worth incorporating this diff and modifying the instance check
> > accordingly?
> >
>
>  ...
>
>  Please do *not* commit this diff at the moment.
>
Have you thought about this anymore?

I hit another case today where I think this diff would've been helpful for me.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au
--------------------------------------------------------------------------



More information about the developers mailing list