Schönheitswettbewerb

[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.

{-# 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", der Name 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.