*** Protokolldatei gestartet
*** Datum: Mi. Jun 27 19:57:51 2012

[Mittwoch, 27. Juni 2012] [19:57:51] Betreten Sie haben den Kanal #forth-ev betreten (-bernd@p5DCD6250.dip0.t-ipconnect.de).
[Mittwoch, 27. Juni 2012] [19:57:53] <Mandalargon> danke
[Mittwoch, 27. Juni 2012] [19:57:56] Modus Kanalmodi: 
[Mittwoch, 27. Juni 2012] [19:57:56] <Mandalargon> moin
[Mittwoch, 27. Juni 2012] [19:58:03] <BerndPaysan> Hallo!
[Mittwoch, 27. Juni 2012] [19:58:03] <MatthiasT> Hallo Bernd
[Mittwoch, 27. Juni 2012] [20:05:53] <BerndPaysan> In der VD sind noch 1,5 Seiten Platz.
[Mittwoch, 27. Juni 2012] [20:06:13] <BerndPaysan> Ich glaube, die fülle ich mit dem neuen Recognizer von Gforth.
[Mittwoch, 27. Juni 2012] [20:06:42] <MatthiasT> Gute Idee
[Mittwoch, 27. Juni 2012] [20:10:25] <BerndPaysan> Ich habe damit letzten Sonntag ein echtes String-Literal implementiert, das ging total einfach.
[Mittwoch, 27. Juni 2012] [20:10:47] <MatthiasT> Ich stöbere grade im Hayes-tester output nach verwertbarem
[Mittwoch, 27. Juni 2012] [20:11:09] <BerndPaysan> Echtes String-Literal: "Dies ist ein String"
[Mittwoch, 27. Juni 2012] [20:11:12] <MatthiasT> So manche Fehlermeldung ist für amforth einfach nicht korrekt ;)
[Mittwoch, 27. Juni 2012] [20:11:15] <BerndPaysan> Ohne Quote hinter dem startenden "
[Mittwoch, 27. Juni 2012] [20:11:23] <BerndPaysan> Äh, Leerzeichen.
[Mittwoch, 27. Juni 2012] [20:11:37] <MatthiasT> Als Alternative zum s" im Interpreter?
[Mittwoch, 27. Juni 2012] [20:11:56] <BerndPaysan> Genau.
[Mittwoch, 27. Juni 2012] [20:12:03] <BerndPaysan> Weil s" nicht so sonderlich gelungen ist.
[Mittwoch, 27. Juni 2012] [20:12:23] <BerndPaysan> Ein anderer Vorschlag ist ->foo statt TO FOO
[Mittwoch, 27. Juni 2012] [20:13:24] <MatthiasT> warum?
[Mittwoch, 27. Juni 2012] [20:13:26] <BerndPaysan> Ein Vorzug vom Recognizer ist, dass man diese Konstrukte auch mit POSTPONE compilieren kann.
[Mittwoch, 27. Juni 2012] [20:13:32] <BerndPaysan> Also POSTPONE ->foo
[Mittwoch, 27. Juni 2012] [20:13:36] <BerndPaysan> Mach' das mal mit TO :-)
[Mittwoch, 27. Juni 2012] [20:13:53] <MatthiasT> achso, du hast kein Leerzeichen zwischen > und f
[Mittwoch, 27. Juni 2012] [20:14:08] <BerndPaysan> Genau.
[Mittwoch, 27. Juni 2012] [20:14:22] <MatthiasT> tofoo ist aber auch nett ;) (evt mit einem o weniger)
[Mittwoch, 27. Juni 2012] [20:14:54] <MatthiasT> jo, solche syntaktischen Sachen kann man prima mit recognizern organisieren
[Mittwoch, 27. Juni 2012] [20:16:19] <BerndPaysan> Ich glaube, dass die Recognizer ein wichtiger Baustein sind, um Forth wirklich umfassend erweiterbar zu machen.
[Mittwoch, 27. Juni 2012] [20:16:54] <MatthiasT> Zumindest können sie es werden.
[Mittwoch, 27. Juni 2012] [20:25:08] <BerndPaysan> Weil der Recognizer ein Interface zu Postpone hat, ist er kein so Problem wie parsing words.
[Mittwoch, 27. Juni 2012] [20:28:15] <BerndPaysan> Ein Gedanke ist mir bei " noch gekommen: Soll der Recognizer eventuell das Parsing selbst übernehmen?
[Mittwoch, 27. Juni 2012] [20:28:27] <BerndPaysan> Also bisher bekommt mein Recognizer den String von PARSE-NAME übergeben.
[Mittwoch, 27. Juni 2012] [20:28:55] <BerndPaysan> Der "-Recognizer setzt dann >IN auf die Position nach dem " und parst dann selber nochmal.
[Mittwoch, 27. Juni 2012] [20:29:23] <MatthiasT> Bislang ist der Recognizer auf Leerzeichen blind.
[Mittwoch, 27. Juni 2012] [20:29:52] <MatthiasT> Aber Du hast ja addr/len als Returnparameter eingeplant. Das könnte man doch umwidmen zu "mach einfach hier weiter"
[Mittwoch, 27. Juni 2012] [20:29:53] <BerndPaysan> So ungefähr. Man kann damit also nicht Whitespace implementieren ;-)
[Mittwoch, 27. Juni 2012] [20:31:15] <MatthiasT> andererseits weiss er nicht, wie er im Zweifel die Eingabezeile neu füllen muss
[Mittwoch, 27. Juni 2012] [20:31:17] <BerndPaysan> Die Idee momentan mit addr len ist, dass der Recognizer-Stack den geparsten String bekommt, und solange dran rummacht, bis er etwas verdaubares gefunden hat.
[Mittwoch, 27. Juni 2012] [20:31:24] <BerndPaysan> refill
[Mittwoch, 27. Juni 2012] [20:31:32] <MatthiasT> also ein mehrzeiliger String ist nicht
[Mittwoch, 27. Juni 2012] [20:31:37] <BerndPaysan> Das wäre dann für mehrzeilige Strings.
[Mittwoch, 27. Juni 2012] [20:31:45] <BerndPaysan> Muss' ich mir mal überlegen, ob man das nicht gleich mit einbaut.
[Mittwoch, 27. Juni 2012] [20:31:47] <BerndPaysan> Ist nicht so schwierig.
[Mittwoch, 27. Juni 2012] [20:31:56] <MatthiasT> klar, aber bislang nicht spezifiziert
[Mittwoch, 27. Juni 2012] [20:32:28] <MatthiasT> ebenso die Block-Inputs. die können von Haus aus mehrere Zeilen haben.
[Mittwoch, 27. Juni 2012] [20:34:15] <MatthiasT> andererseits ist es ja grade der charme der recognizer, dass die nicht mehr so viel parsen müssen
[Mittwoch, 27. Juni 2012] [20:34:39] <MatthiasT> die " müsste der Interpreter machen
[Mittwoch, 27. Juni 2012] [20:35:52] <MatthiasT> also eher parse
[Mittwoch, 27. Juni 2012] [20:35:52] <BerndPaysan> Nein, der soll nur ein Gerüst sein, in das man verschiedene Dinge einhängen kann.
[Mittwoch, 27. Juni 2012] [20:36:05] <BerndPaysan> Deshalb die Überlegung, auch PARSE-NAME in den Recognizer einzubauen.
[Mittwoch, 27. Juni 2012] [20:36:13] <MatthiasT> Dann müsste der Parser genauso ausgelagert werden
[Mittwoch, 27. Juni 2012] [20:36:37] <MatthiasT> ergo "lies mal die Zeile und wuschtele solange daran herum, bis was sinnvolles herauskommt"
[Mittwoch, 27. Juni 2012] [20:36:38] <Mandalargon> ich werde erstmal los müssen
[Mittwoch, 27. Juni 2012] [20:36:45] <Mandalargon> bbis demnächst
[Mittwoch, 27. Juni 2012] [20:36:48] Verlassen Mandalargon hat den Kanal verlassen.
[Mittwoch, 27. Juni 2012] [20:36:48] <MatthiasT> dito
[Mittwoch, 27. Juni 2012] [20:37:05] <BerndPaysan> Ciao
[Mittwoch, 27. Juni 2012] [20:37:55] <MatthiasT> Wobei es genau zwei Regeln gibt: Entweder mit Leerzeichen oder doppelte Hochkomma, die paarweise vorkommen müssen
[Mittwoch, 27. Juni 2012] [20:38:09] <BerndPaysan> Nein, die Regeln bestimmt jeder Recognizer für sich.
[Mittwoch, 27. Juni 2012] [20:38:35] <BerndPaysan> Da kannst du auch einen (al*ge+bra-isch/e)-Formel-Recognizer einbauen, der Ausdrücke in Klammern parst.
[Mittwoch, 27. Juni 2012] [20:39:03] <MatthiasT> hmm
[Mittwoch, 27. Juni 2012] [20:39:43] <MatthiasT> Dann muss er wirklich den Endpunkt seiner Arbeiten kommunizieren.
[Mittwoch, 27. Juni 2012] [20:39:53] <MatthiasT> Damit der Interpreter weiss, wo es weitergeht
[Mittwoch, 27. Juni 2012] [20:40:04] <BerndPaysan> Der Interpreter bekommt Token.
[Mittwoch, 27. Juni 2012] [20:40:18] <BerndPaysan> Token, die man interpretieren, compilieren und serialisieren kann.
[Mittwoch, 27. Juni 2012] [20:40:30] <BerndPaysan> Wie, liefert der Recognizer mit.
[Mittwoch, 27. Juni 2012] [20:41:07] <BerndPaysan> Ein Formel-Recognizer kann also z.B. einen Tree anlegen, und den dann durchlaufen.
[Mittwoch, 27. Juni 2012] [20:41:46] <MatthiasT> Der Formel-Recognizer wird wohl eher ein Programm generieren, das den Formelausdruck berechnet
[Mittwoch, 27. Juni 2012] [20:41:55] <MatthiasT> Richt etwas nach lisp
[Mittwoch, 27. Juni 2012] [20:43:46] <BerndPaysan> Wie er das macht, ist mir eher egal.
[Mittwoch, 27. Juni 2012] [20:44:13] <BerndPaysan> Bisher hatte man Formel-Recognizer, die einfach Spaces zwischen den Symbolen benötigten.
[Mittwoch, 27. Juni 2012] [20:44:24] <BerndPaysan> Das war ja auch schon gut.
[Mittwoch, 27. Juni 2012] [20:46:56] <MatthiasT> IN jedem fall dürfte der recognizer einen String bekommen und damit ein execution token bauen, dass der Interpreter dann verarbeiten kann. Oder?
[Mittwoch, 27. Juni 2012] [20:47:12] <BerndPaysan> Ja, so ungefähr.
[Mittwoch, 27. Juni 2012] [20:47:25] <BerndPaysan> Meiner liefert drei Execution Tokens in einem kurzen Array zurück.
[Mittwoch, 27. Juni 2012] [20:47:45] <BerndPaysan> Für interpretieren, compilieren und serialisieren (aus dem man dann POSTPONE bauen kann)
[Mittwoch, 27. Juni 2012] [20:47:52] <MatthiasT> (naja: ein XT mit 3 Einträgen)
[Mittwoch, 27. Juni 2012] [20:48:22] <BerndPaysan> Kann man vielleicht ungefähr so sehen.
[Mittwoch, 27. Juni 2012] [20:50:29] <MatthiasT> Braucht man dann eigentlich noch einen Executor?
[Mittwoch, 27. Juni 2012] [20:50:39] <MatthiasT> der dann das XT verarbeiten kann
[Mittwoch, 27. Juni 2012] [20:51:12] <MatthiasT> Bislang macht "mein" recognizer die ganze Arbeit selbst. Der gforth-recognizer scheint schon was anderes zu machen.
[Mittwoch, 27. Juni 2012] [20:51:33] <MatthiasT> zumindest erscheint es sinnvoll, die Arbeit aufzuteilen
[Mittwoch, 27. Juni 2012] [20:52:21] <MatthiasT> Recognizer macht aus einem String den XT (ich bleibe dabei, ein XT), der Executor verarbeitet den dann und auf in die nächste iteration
[Mittwoch, 27. Juni 2012] [20:52:43] <BerndPaysan> Ja, so ungefähr.
[Mittwoch, 27. Juni 2012] [20:52:52] <MatthiasT> Postpone/execute/compile ist eh immer gleich
[Mittwoch, 27. Juni 2012] [20:53:11] <BerndPaysan> Nur trenne ich an einer anderen Stelle: Der Recognizer weiß nicht, ob das dann im Interpreter-Modus, im Compiler-Modus oder von Postpone weiterverarbeitet wird.
[Mittwoch, 27. Juni 2012] [20:53:23] <MatthiasT> muss er ja auch nict
[Mittwoch, 27. Juni 2012] [20:53:46] <MatthiasT> wie erwähnt, mein XT ist komplexer als eine Zahl ;)
[Mittwoch, 27. Juni 2012] [20:54:58] <BerndPaysan> Ja, wenn man den Ansatz vom XT mit intelligent compile, hat, dann kann man das so direkt als XT interpretieren.
[Mittwoch, 27. Juni 2012] [20:55:11] <BerndPaysan> Da muss dann nur noch für POSTPONE ein postpone, oder sowas 'rein.
[Mittwoch, 27. Juni 2012] [20:57:42] <MatthiasT> Für den String-Recognizer ist allerdings interessant, wie er zu seinem abschließendem " kommen kann. Ein refill würde u.a. den input buffer kaputt machen.
[Mittwoch, 27. Juni 2012] [20:58:19] <BerndPaysan> Ja, zu dem Zeitpunkt darf er dann nicht mehr fehlschlagen.
[Mittwoch, 27. Juni 2012] [20:59:21] <MatthiasT> Trivialsysteme wie mein amforth könnten sich ja noch auf einzeilige Strings zurückzeiehen. Aber so generell wär das doch eher schick
[Mittwoch, 27. Juni 2012] [21:16:06] <MatthiasT> ich bin dann auch weg. Bis neulich
[Mittwoch, 27. Juni 2012] [21:16:17] Beenden MatthiasT hat den Server verlassen ("").