Diskussion:Typinferenz
Die seltsamen Regeln für den Ergebnistyp ignorieren Überläufe, oder irre ich mich da?[Quelltext bearbeiten]
Wenn man das Ergebnis der Addition zweier int in einen Datentyp stecken will, reicht dafür aber int nicht notwendigerweise aus, außer man riskiert nen Überlauf. Wie geht SML denn damit um? Noch akuter wird es bei der Multiplikation, darum wird bekommt sie auf Maschinencode-Ebene meist einen Ergebnistyp mit doppelter Bitbreite verpasst. Also: Die Multiplikation zweier 32-Bit-Zahlen wird in ein 64-Bit-Ergebnis gepackt. Ebenso besitzen die 32-Bit-Addition und -Subtraktion über das Carry-Flag quasi ein 33-Bit-Ergebnis. Jedoch bildet dies keine mir bekannte höhere Programmiersprache korrekt ab. Oder kann SML sowas etwa? --RokerHRO 22:29, 28. Jan. 2010 (CET)
- Das ist auch nicht der Sinn der Typinferenz. Die Typinferenz leitet lediglich anhand der vorgegebenen Regeln den (allgemeinsten) Typ eines Ausdrucks ab. Sollen Überläufe o.ä. berücksichtigt werden, müssen die Regeln entsprechend angepasst werden. Ich weiß nicht, ob sowas in SML erlaubt ist, in Haskell bspw. kann der *-Operator durch eine Variante ersetzt werden, die statt dem Typ der Operanden einen doppelt so breiten Ergebnistyp hat. Ein Beispiel:
(*) :: Word32 -> Word32 -> Word64, * wird also als Funktion von zwei 32-Bit breiten Werten auf einen 64-Bit breiten Wert deklariert; die Implementierung muss dann entsprechend angegeben werden. -- PyroPi 04:49, 5. Jan. 2011 (CET)
Zweifelhaftes Beispiel[Quelltext bearbeiten]
Aus
int a;
c = a+b;
zu schließen, dass auch b und c int sein müssen, ist schlicht falsch. Beide können auch zB double sein. Jeder größere Datentyp ist möglich. Erst
int a;
a = b+c;
legt den Schluss nahe, dass auch b und c vom Typ int sein müssen, oder sich zumindest von einem kleineren Typ nach int konvertieren lassen. Oder übersehe ich hier irgend etwas? --Guternachbar (Diskussion) 13:14, 9. Jun. 2017 (CEST)
- @Guternachbar: Ich habe das Beispiel nun klarer gemacht. --Trustable (Diskussion) 16:19, 16. Aug. 2022 (CEST)
- Es ist überhaupt nicht schlicht falsch. In Haskell ist in der Standardbibliothek etwa festgelegt, dass + nur auf Operanden gleichen Typs wirken kann, und etwas vom gleichen Typ zurückgibt. Implizite Konversion gibt's da nicht. Implizite Konversion (a.k.a. "Subtypen") kollidiert sowieso mit richtig nützlicher Typinferenz (theoretisches Resultat), weswegen C# etwa auch nur einen ganz kleinen Teil der möglichen Funktionalität bietet.
- Was jetzt im letzten Satz der Einleitung steht (als die Auflistung von ein paar Programmiersprachen) passt nicht sehr gut mit dem kurz davor gesagten zusammen:
- "Gewisse Spracheigenschaften wie Typanpassungen und manchmal Überladen wurden zurückgedrängt, weil sie mit der Typinferenz kollidieren."
- Also ich meine, bzgl. der aufgelisten Sprachen werden ja v.a. Abstriche an der Typinferenz gemacht und nicht andersherum.
- M.E. kann man ohne Verlust zu https://de.wikipedia.org/w/index.php?title=Typinferenz&oldid=167497915 zurückkehren.
- --Daniel5Ko (Diskussion) 19:11, 16. Aug. 2022 (CEST)