[m-dev.] functional dependencies syntax

[Mark Brown]

On 23-Mar-2005, Mark Brown <mark at cs.mu.oz.au> wrote:
> (I'm making up concrete syntax for functional dependencies here.  Feel free
> to chip in with alternatives.)

There has been some discussion in the office, which I shall summarise here.
Two main suggestions were made, both of which I am inclined to agree with.

Suggestion 1:

Use '->'/2 as the top-level operator for a functional dependency, and use
','/2 as the operator to construct sets of type variables in the domain
and range of the FD.

Some example FDs with this syntax:

	(A -> B)
	(A, B, C -> D)
	(A, B -> C, D, E)

The drawback of this is that there is no obvious way to specify an empty
domain or range.  I doubt that is important, though, since an empty range
wouldn't have any use at all (it would not constraint the set of possible
instances at all) and I can't see an empty domain as being useful (it would
constrain the specified range arguments to always having the same type).

Suggestion 2:

Rather than introduce a new keyword to precede the FDs (I used "given" in
my earlier example), make '->'/2 into a special builtin typeclass with the
semantics of FDs and place any FDs in the set of constraints on your
typeclass declaration.

For example:

	:- typeclass container(C, E) <= (C -> E) where ...
	:- typeclass foo(A, B) <= (bar(A, B), (A -> B)) where ...
	:- typeclass baz(A, B, C) <= (quux(A), (A, B -> C), quuux(B, C)).

The FDs would be able to appear anywhere in the set of constraints.

An alternative is that FDs must be at the start of the list of constraints.
Another alternative is that they must be at the end of the list.

Drawbacks:

	- This would preclude the use of '->'/2 as the name of a user
	defined typeclass, unless we provide some way of escaping the
	special meaning of this name in typeclass declarations.

	- There is a slight lack of orthogonality here because, unlike
	ordinary constraints, FDs can only appear on typeclass declarations.
	They can't appear on instances, preds, funcs, or existentially
	quantified types.

Cheers,
Mark.

--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------