[m-dev.] Existentially quantified data constructors

[Julien Fischer]

On Mon, 21 Apr 2008, Ian MacLarty wrote:

> On Wed, Apr 16, 2008 at 02:18:32PM +1000, Julien Fischer wrote:
>>
>> On Wed, 16 Apr 2008, Ralph Becket wrote:
>>
>>> Julien Fischer, Wednesday, 16 April 2008:
>>>>
>>>>> (don't use equivalence types in instance declarations,
>>>>
>>>> There is no such restriction, perhaps this was the one you were
>>>> referring to?
>>>>
>>>> 	The types in an instance declaration must not be abstract types
>>>> 	which are elsewhere defined as equivalence types.
>>>
>>> Yes, that's the one.
>>>
>>>>> don't repeat variables in instance declarations, instance
>>>>> variable arguments must be of the form typector(typevar, typevar, ...),
>>>>
>>>> The reference manual already gives the reasons for these restrictions,
>>>> from section 10.2
>>>>
>>>> 	These restrictions ensure that there are no overlapping instance
>>>> 	declarations, i.e. for each typeclass there is at most one instance
>>>> 	declaration that may be applied to any type (or sequence of types).
>>>
>>> Is this a necessary restriction or an artefact of our implementation?
>>
>> The latter.  Certain aspects could (probably) be relaxed, e.g.
>> you could have unwrapped variables as some, although not all, arguments
>> of an instance head.  Exactly what restrictions could be dropped depend
>> on the form that any future version of the type class system takes.
>> (This has been extensively discussed on this list some time in the recent
>> past.)
>>
>>> Why isn't this rule relaxed with functional dependencies?
>>
>> I don't see how information from functional dependencies would help
>> here.
>>
>
> 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.

Julien.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------