Schönheitswettbewerb
bearbeitet von 1unitedpower> da muss ich jetzt erstmal eine Weile drüber nachdenken. Und mir darüber klar werden, ob ich mir die Kopfschmerzen wirklich antun will 😂.
Die Kopfschmerzen gehen auf meine Kappe, weil ich ein miserabler Erklärbär bin - sorry dafür. Ich glaube trotzdem, dass dir Haskell gefallen würde, deiner Aktivität in den Mathe-Threads zu Folge, bist du auf jedenfall Mathematik-begeistert - und die Mathematik hinter Haskell ist äußerst elegant und spannend.
> Immerhin habe ich eins schon kapiert: hier ist ein > zuviel 😉.
Gut gesehen.
> Und ich habe wohl die Begriffe "Currying" und "Partieller Anwendung" durcheinandergeworfen. Meine Curry2-Funktion führt ja offenbar kein Currying durch, sondern stellt die partielle Anwendung einer zweistelligen Funktion mit einem Parameter dar.
> Ob deine curry2/uncurry2 Funktionen sich auf der Ebene des generierten Codes tatsächlich aufheben (sprich: Ob Haskell das erkennt und wegoptimiert), das wäre mal eine interessante Frage.
Da bin ich mir selber nicht sicher. Was man auf jeden Fall machen könnte, ist dem Haskell-Compiler die Optimierung bekannt zu machen, dazu kann man Termersetzungsrelgen angeben.
~~~haskell
{-# RULES
"curry2/uncurry2" forall f . curry2 (uncurry2 f) = f
"uncurry2/curry2" forall f . uncurry2 (curry2 f) = f
#-}
~~~
Hier werden zwei Optimierungs-Regeln definiert, die erste Regel trägt den Namen "curry2/uncurry2", sie dient lediglich Entwickler(innen) als Hilfe fürs Debugging und taucht im kompilierten Code nicht mehr auf. Die Regel drückt aus, dass wann immer ein Term der Form `curry2 (uncurry2 f)` gefunden wird, darf dieser Term durch `f` ersetzt werden und umgekehrt. Das `f` muss nicht `f` heißen, sondern kann ein beliebiger Term sein, deshalb ist `f` all-quantifiziert.
Eleganter wäre es natürlich den Bloat von vornerein zu vermeiden.