diff options
author | Gregor Kleen <gkleen@yggdrasil.li> | 2017-10-25 09:34:11 +0200 |
---|---|---|
committer | Gregor Kleen <gkleen@yggdrasil.li> | 2017-10-25 09:34:11 +0200 |
commit | 7cdccabeedda7566ad5164ad297695b4d9f8d0be (patch) | |
tree | f444b73fe86f86528298693c11d5e2b09cd959ee /topic.md | |
parent | de87f85cfeb6dbe354bc16bbd3acc32291ee4b54 (diff) | |
download | incremental-dfsts-7cdccabeedda7566ad5164ad297695b4d9f8d0be.tar incremental-dfsts-7cdccabeedda7566ad5164ad297695b4d9f8d0be.tar.gz incremental-dfsts-7cdccabeedda7566ad5164ad297695b4d9f8d0be.tar.bz2 incremental-dfsts-7cdccabeedda7566ad5164ad297695b4d9f8d0be.tar.xz incremental-dfsts-7cdccabeedda7566ad5164ad297695b4d9f8d0be.zip |
Support includes
Diffstat (limited to 'topic.md')
-rw-r--r-- | topic.md | 37 |
1 files changed, 14 insertions, 23 deletions
@@ -1,25 +1,16 @@ | |||
1 | Ziel ist es eine Methode zu erarbeiten mit der sich Parser beschreiben lassen, | 1 | Wir möchten inkrementelle Parser sowohl in ihrer algebraischen Struktur als auch |
2 | die, gegeben ein vorheriges Ergebnis und eine Beschreibung des Unterschieds | 2 | in einer Implementierung in Haskell als edit-lenses (alá @hofmann2012edit) |
3 | zwischen des damaligen Inputs und dem aktuellen, schneller das neue Ergebnis | 3 | auffassen. |
4 | produzieren können als es ohne zusätzlichen Kontext möglich wäre. | ||
5 | 4 | ||
6 | Zunächst wird hierfür nach bereits vorhandener Arbeit recherchiert (z.B. die | 5 | Unter einem inkrementellen Parser verstehen wir (analog zu |
7 | inkrementellen Parser des Texteditors “Yi”) und versucht deren Ergebnisse vom | 6 | @ghezzi1979incremental) ein Programm, das, nach einem initialen Parsevorgang, |
8 | obigen Thema abzugrenzen. | 7 | gegeben eine Spezifikation einer Änderung der textuellen Eingabe schneller ein |
8 | neues Ergebnis erzeugt als es ohne zusätzlichen Kontext möglich wäre | ||
9 | (gewöhnlicherweise in logarithmischer Zeit in der Länge der Eingabe). | ||
10 | Für die Darstellung als edit-lens erweitern wir diese Definition und fordern, | ||
11 | dass statt einem neuen Ergebnis eine Spezifikation einer Änderung am Ergebnis | ||
12 | erzeugt werden soll (das Anwenden dieser Änderung auf ein altes Ergebnis sollte | ||
13 | die Laufzeit nicht verschlechtern). | ||
9 | 14 | ||
10 | Die algebraische Darstellung von Parsern als funktionale Linsen und von der | 15 | Unsere Implementierung soll inkrementelle Parser für reguläre- und |
11 | Applikation von Änderungen (sowohl an der Eingabe, als auch, im Optimalfall, an | 16 | $LL(1)$-Sprachen sowie für Fragmente von Java und XML bereitstellen. |
12 | der Ausgabe eines Parsers) als “edit-lenses” soll verwendet werden. | ||
13 | |||
14 | Dann wird die naheliegenden Konstruktion für den Speziallfall, dass es sich beim | ||
15 | betrachteten Parser um einen DFA handelt der nur prüft ob eine Eingabe | ||
16 | akzeptiert wird und wmgl. eine Implementierung dieser Konstruktion in Haskell | ||
17 | vorgestellt. | ||
18 | Nun wird versucht die Konstruktion zunächst auf Parser und dann auf mächtigere | ||
19 | Automaten zu erweitern. | ||
20 | Speziell sollen hier Parser betrachtet und implementiert werden, die paarweise | ||
21 | auftretende Klammern gruppieren und sicherstellen, dass Variablen in der Syntax | ||
22 | einer imperativen Programmiersprache nur benutzt werden, nachdem sie deklariert | ||
23 | wurden. | ||
24 | Es soll dann versucht werden iterative Parser für XML und ein Fragment der | ||
25 | Programmiersprache Java zu entwicklen und zu implementieren. | ||