@deets: Um verschiedene Implementierungen mit derselben Schnittstelle zu versehen, nutzt Haskell Typklassen. Typklassen definieren ähnlich den Schnittstellen in Java eine Menge an Operationen, die Typen unterstützen müssen. Die Zuordnung eines Typen zu einer Typklasse geschieht allerdings
explizit, wobei die generischen Operationen der Typklasse konkret für den speziellen Typen implementiert werden müssen. Typklassen sind die Basis generischer Operationen wie beispielsweise Gleichheit oder Ordnung.
Verwendet eine Funktion Funktionen einer Typklasse, so schlägt sich das in im Typschema der Funktion nieder. "sort" hat beispielsweise den Typen "(Ord a) => [a] -> [a]", ist also nur für Typen definiert, die Instanz der Typklasse "Ord" sind (diese Klasse definiert Vergleichsoperationen und somit die natürliche Ordnung eines Typen) (
Beispiel mit nach Alter geordneten Personen).
Der Zugriff auf den Typen erfolgt also nur indirekt über die Operationen der Typklasse, wobei konkrete Typen explizit als Instanz einer Typklasse markiert werden. Mithin kann der Haskell-Compiler für die Typklasse eine ABI festlegen, und für Instanzen Wrapper erzeugen, welche dieser ABI entsprechen. Vor dem Aufruf von Funktionen, die eine Typklasse verlangen, können Objekte konkreter Typen dann in den entsprechenden Wrapper verpackt werden, die Funktion selbst muss den konkreten Typen gar nicht kennen.
Die ML-Familie nutzt statt Typklassen Funktoren, also Module höherer Ordnung, um die Problemstellung, identische Schnittstellen mit verschiedenen Implementierungen zu versehen, zu lösen.
Was die Namenskonvention händisch implementierter Opal-Typen angeht, so vermute ich, dass das primär erst einmal der Typprüfung dient. Um vollständige Typinferenz durchzuführen, muss der Compiler die Typschemen solcher Typen ebenfalls kennen. Opal kodiert diese Typen offenbar in der Signatur der C-Funktion, und erspart sich so die Notwendigkeit, die Typschemen zusätzlich zu speichern. Haskell erzeugt bei der Übersetzung von Modulen separate Dateien mit Typinformationen.
Und wie gesagt, ich sage ja nicht, dass eine solche Optimierung generell unmöglich ist. Im Gegenteil, man kann sie auf verschiedenste Weise umsetzen, aber halt jeweils mit anderen Nachteilen. Ich habe nur versucht zu erklären, warum Haskell und ML dergleichen nicht umsetzen, und das sind halt die einzigen rein funktionalen Sprachen ihrer Art, die auch praktisch eingesetzt werden.