Betrachten Sie die folgende GHCi-Sitzung:
%Vor% Ich habe eine Ahnung von dem, was hier passiert: Der Typ-Checker muss Coercible (Ord a => a -> Map a b -> Bool) (Ord a => a -> MySet a -> Bool) erfüllen und kann b in dieser Einschränkung nicht in () instanziieren.
Gibt es einen eleganteren Weg als mit -XTypeApplications ?
Bearbeiten: Ich suche vor allem nach Lösungen, die sich mit vielen Vorkommen von MySet a im Typ beschäftigen, zum Beispiel union :: Ord a => MySet a -> MySet a -> MySet a .
GHC muss akzeptieren
%Vor%Sieht das
%Vor%was es braucht
%Vor%was zu
führt %Vor% Aber was ist b ? Es ist mehrdeutig. In diesem Fall spielt es keine Rolle, was b ist, weil pro Parameter member möglicherweise nicht interessiert. Es wäre also durchaus sinnvoll, b ~ () zu wählen und den Zwang trivial zu lösen. Im Allgemeinen führt GHC jedoch keine solche Parameteranalyse in der Typinferenz durch. Ich vermute, es könnte schwierig sein, das zu ändern. Vor allem, wenn die Typinferenz "rät", besteht die Gefahr, dass sie falsch rät und an anderer Stelle Rückschlüsse verhindert. Es ist eine große Dose Würmer.
Was Ihr Problem angeht, ich habe keine gute Lösung. Wenn Sie mehrere Funktionen mit ähnlichen Mustern haben, können Sie sie abstrahieren, aber Sie werden immer noch mit erheblichem Ärger konfrontiert.
Die Lösung mit TypeApplications ist ziemlich einfach:
Beachten Sie, dass einige Funktionen mehr oder weniger Platzhalter benötigen, z.
%Vor%Um zu bestimmen, wie genau Sie die Typanwendungen angeben müssen (abgesehen von Versuch und Irrtum), verwenden Sie
%Vor% Die Reihenfolge der Variablen, die Sie von :i erhalten, ist die gleiche, die von TypeApplications verwendet wird.
Beachten Sie, dass Sie coerce nicht für fromList verwenden können - das ist keine Einschränkung, es ergibt keinen Sinn:
Dies ergibt den Fehler
%Vor%Das Beste, was Sie hier tun können, ist wahrscheinlich
%Vor%Tags und Links haskell unification coerce