"Free" Typ Variablen durch funktionale Abhängigkeiten in Typ Synonyme gebunden

Question

eine Klasse Gegeben

class MonadSignal m sigs | m -> sigs where ... 

und eine Klasse

class CanSignal sigs sigs' where ... 

Ich möchte eine Art Synonym wie diese

type MonadSignal' sigs m = (MonadSignal m sigs', CanSignal sigs sigs') 

definieren

Hier wird die sigs' Variable im Kopf des MonadSignal' Typ Synonyms aber nicht erwähnt ist da, nur um die erste und die zweite Nebenbedingung zu verbinden, und es ist eindeutig durch m festgelegt, die ist im Kopf erwähnt.

Normalerweise denke ich, ich wäre in der Lage es auf der RHS forall aber da dies nur ein Constraint Synonym ist, gibt es keinen eigentlichen Körper für die Variable in erscheinen.

hier etwas getan werden kann? (Außer die Variable in den Kopf setzen und den falschen Eindruck, wenn das Synonym tatsächlich verwendet wird, dass es eine tatsächliche „Variable“)

Answer 1

Es ist keine konservative Änderung, aber eine Lösung wäre, von funktionalen Abhängigkeiten zu Typfamilien zu wechseln. Sie könnten eine zugehörige Familie

{-# LANGUAGE MultiParamTypeClasses #-} 
{-# LANGUAGE FlexibleContexts #-} 
{-# LANGUAGE ConstraintKinds #-} 
{-# LANGUAGE TypeFamilies #-} 
module TypeFamily where 

class Monad m => MonadSignal m where 
    type Sig m :: * 
    make :: m sig 

class CanSignal sigs sigs' where 

type MonadSignal' sigs m = (MonadSignal m, CanSignal sigs (Sig m)) 

Es ist machen vielleicht nicht ganz so hübsch wie Multitypklassen für beide verwenden, aber es sollte in Ausdruckskraft nur als gleichwertig sein und Sie müssen nicht über das Tun dieses „transitive closure“ Sorge irgendwie.

Answer 2

Sie die Art Synonym mit einer Klasse ersetzen:

class MonadSignal' sigs (m :: * -> *) 
instance (MonadSignal m sigs', CanSignal sigs sigs') => MonadSignal' sigs m 

In der Klasseninstanz, die Typvariable sigs' erscheint nicht im Klassenkopf, , also müssen Sie {-# LANGUAGE UndecidableInstances #-} verwenden, damit es funktioniert. Ich glaube zwar nicht, dass diese Klasse tatsächlich zur Beendigung führen kann.

Answer 3

Leider glaube ich, dass Sie diesen falschen Eindruck geben müssen, wenn Sie auf einem richtigen fempep bestehen (sehen Sie die Unterseite dieser Antwort, wenn Sie einen etwas anderen Ansatz akzeptieren). Ich dachte kurz, vielleicht könnten Sie stattdessen MonadSignal' eine Klasse machen, aber Sie würden nicht in der Lage sein, die Superklassenbeschränkung zu geben, die Sie wollen. Sie können das wettmachen, indem Sie wirklich explizit mit einer oder mehreren Dict Methoden arbeiten, aber dann wird Ihr Leben schwierig sein.

Obwohl dies nicht relevant ist, ist es wahrscheinlich besser

class MonadSignal sigs m | m -> sigs 

Vertauschen der Reihenfolge der Parameter zu definieren, die Ihnen weitere nützliche partielle Anwendung erhält und macht GeneralizedNewtypeDeriving Arbeit für Ihre Klasse.

---

Es gibt eine andere Art und Weise Art Familien zu verwenden, auf der Grundlage einer legitimen Umsetzung fundeps in Art Familien:

class (sigs ~ Sigs m) => MonadSignal sigs m where 
    type Sigs m :: * -- Or appropriate kind 
    ... 

type MonadSignal' sigs m = (MonadSignal (Sigs m) m, CanSignal sigs (Sigs m))