Re: Pattern Matching

Ich muss erst drüber nachdenken - die Sache hat verschiedene Aspekte. Zunächst ist es erstaunlich, wie gut es tut.
Das gute ist, wie man sieht kommt man so einfach nicht von davon die Logik von Push und Pop wird zu der üblichen Katastrophe, nicht was Push und Pop betrifft - sondern solche Sachen - die easy scheinen im Allgmeinen. Ich halte ihnen darüber keinen Vortrag.

Ich denke, dass wir erkennen, dass das Problem von Push und Pop zu einem geometrischen Problem wird. Wir kennen das hier

                    |
      |             |           |
  |   |   |     |   |   |    |  |  |
| | | | | | | | | | | | | | | | | | | | |

Wir kennen das Thema die Türme von Hanoi, die tatsächlich vielleicht so aussehen, weil sie sind, wie sie sind - letzten Endes auch das ein Thema, was durch geschicktes Stapeln und Umstapeln erledigt wird. Aber wir kennen auch Themen wie aus der Mathematik. Die eigentlich von Euklid stammen. Arithmetisches Mittel. Die Mitte zwischen zwei Punkten a und b - auf einer Geraden. Interessant ist - dass das Ende eines Abschnittes, der eine Hälfte war, jetzt die Mitte eines grösseren Abschnitts wird. Compilerbau wird zur Geometrie und - das Intervallhalbierungsverfahren findet hier seinen Platz. So einfach ist das nicht.

Man findet eine Lösung, die geht. Aber es fehlen uns immer noch Dinge, die wir für das absolute verständnis brauchen. Und dann droht uns das gleiche, was uns vorher auch drohte.

Kaum fangen wir an - an etwas herum zu manipulieren, zeigt es erst einen Fortschritt und plötzlich entsteht ein Chaos.

Etwas das nicht mehr klar ist, ist die Konstellation untereinander.

Wir treten ein in die Welt der Datenbanken und Tupel. Nein, Datenbanken nicht, aber, was wir jetzt verstanden haben, es ist ein geometrisches Problem. Aber es ist immer noch Chaos. Etwas, das jetzt schon nicht klar aussieht, obwohl es das ist - ist, was das Datum ist

Dazu gibt es Aspekte

Es gibt generell zwei Zustände.

Es gibt Zustand 1 und 2. Ich würde sie nicht als Links und Rechts bezeichnen, was wieder ein Aspekt ist. Ein jeder Automat hat mit der geringsten Eingabemenge, entweder den einen Folgezustand oder den anderen. Links und Rechts bezieht sich auf die Struktur wie der "Baumäufgebaut ist, der unser Ausdruck ist

Also gut, wir haben den einen Folgezustand und den anderen. Und meistens sind die gleich. Kommt auf ein a ein b - dann ist 1 und 2 gleich b. Das passiert uns in einem Baum eher nicht, dass ein Knoten einen Nachfolger hat, auf den r und l zeigen

Gut. Jetzt kommen wir aber zu anderen Themen. Wir haben Anfang, Mitte, Ende. Dazu haben wir aber, wenn wir das ganze ausgeben, eben etwas, das dazwischen steht, ich habe es mit d1 und d2 bezeichnet. In der Ausgabe zu erkennen. Ich sagte, das ist Atom. Muss es aber nicht sein. Hälfte 1 und Hälfte 2. Gut: Damit sind Bezeichnungen klarar

Aber etwas ist nicht klar. Die Entitäten, nennt man das bei MySQL. Zunächst habe ich einen Anfang, habe ich einen Anfang. Der Anfang das sind zwei Dinge

Wieder ensteht ein Denkunterschied. Ich habe Zustand1 und Zustand2. Aber hier ist es nicht unklar, was Folgezustand1 und Folgezustand2 heisst. Anfang ist im Zustandsdiagramm ein Zustand. Er hat den einen Folgezustand und den anderen. Somit muss ich ihn nehmen und initialieren, wenn die Daten da sind. Das sind sie ja. Aber in der Struktur ist ein Anfang missverständlich. Er kann der Zustand selber sein, aber er kann auch ein Zeiger auf den Anfang sein. Und nicht nur das:

Es gäbe somit einen Anfang - welcher der Zustand ist. Es gäbe aber auch das, was auf Anfang folgt 1 und 2. Das ist bei IF wichtig. Der Anfang selber ist ein Zustand.

Wir erkennen jetzt: R ist und unglaublich wichtig, stellt keinen Zustand dar - sondern die ganze Konstruktion zwischen IF und END IF. Trotzdem ist es keine dynamische Datenstruktur

Aber, es gibt noch etwas, das man klarer ausdrücken könnte, definieren könnte. Die Entitäten

Zwischen Anfang1 und d1 kann eine Beziehung bestehen. Zwischen d1 und d2 unter umständen, besonders umgekehrt vielleicht nicht. das müssen wir definieren.