> > bin auf [diesen genialen 15-Zeiler](http://programmablelife.blogspot.co.at/2012/07/adventures-in-declarative-programming.html) gestoßen. Das haut mich aus den Socken. > > Das Programm benutzt eine Bibliothek, die, der Beschreibung nach, nicht einmal zum Standardumfang von Prolog gehört. Ich kann das nicht im Detail bewerten, aber worauf ich hinaus will: Ich baue dir einen Sudoku-Löser in einem Einzeiler, indem ich den ganzen Code in eine Bibliothek stecke. Berechtigte Kritik, ich möchte das mit zwei Vergleichen einschätzen: Die Funktionen trim() und array_map() aus PHP gehören nicht zum Sprachkern, sondern werden in den String- und Array-Erweiterung respektive definiert. Das DOM gehört nicht zum JavaScript-Kern, es ist trotzdem eine Standard-API in allen Browsern, oder in Spec-Sprech: document ist kein *built-in object* sondern ein *standard object*. Auf vergleichbare Art gehört *Constraint Logic Programming over Finite Domains* nicht zum Prolog-Kern, ist aber Teil von SWI Prolog.

> > bin auf [diesen genialen 15-Zeiler](http://programmablelife.blogspot.co.at/2012/07/adventures-in-declarative-programming.html) gestoßen. Das haut mich aus den Socken. > > Das Programm benutzt eine Bibliothek, die, der Beschreibung nach, nicht einmal zum Standardumfang von Prolog gehört. Ich kann das nicht im Detail bewerten, aber worauf ich hinaus will: Ich baue dir einen Sudoku-Löser in einem Einzeiler, indem ich den ganzen Code in eine Bibliothek stecke. Berechtigte Kritik, ich möchte das mit zwei Vergleichen einschätzen: Die Funktionen trim() und array_map() aus PHP gehören nicht zum Sprachkern, sondern wird in den String- und Array-Erweiterung respektive definiert. Das DOM gehört nicht zum JavaScript-Kern, es ist trotzdem eine Standard-API in allen Browsern, oder in Spec-Sprech: document ist kein *built-in object* sondern ein *standard object*. Auf vergleichbare Art gehört *Constraint Logic Programming over Finite Domains* nicht zum Prolog-Kern, ist aber Teil von SWI Prolog.