Nur Standardbibliotheken.Zitat:
Zitat von Feenstaub
Genauso wie überall sonst: %Gewinn%:100%%|50%%|nichtsZitat:
Wie ist das mit Prozent-zeichen in den Variablenwerten? zb: %Gewinn%:100%|50%|nichts
Druckbare Version
Nur Standardbibliotheken.Zitat:
Zitat von Feenstaub
Genauso wie überall sonst: %Gewinn%:100%%|50%%|nichtsZitat:
Wie ist das mit Prozent-zeichen in den Variablenwerten? zb: %Gewinn%:100%|50%|nichts
Und bei anderen doppeldeutigen Token? zB: %operator%:&|||:|^
Sollen diese aus dem Kontext heraus erkannt werden? Oder gilt das %-Zeichen generell als literal Definition?
Küsschen,
Feenstaub.
Wie wär's, wenn Variablen keine Sonderzeichen enthalten dürften oder wenn nötig dann nur als ASCII-Zeichen übermittelt werden dürften? Dann könnte man ASCIIs wie folgt in einer Variablen kennzeichnen:
Dies würde dann so dargestellt werden: (ASCII-Zeichen 37 ist das "%" Zeichen.)Code:Variable ist: %var%
%var%:Der Inhalt betraegt 50 %ASC(37) .
Variable ist: Der Inhalt betraegt 50 %.
Oder irgendwie sonst der Variable klarmachen, dass hier ein bestimmtest ASCII-Zeichen eingefügt werden soll.
Jetzt weiß ich, worauf du hinauswillst. Glaube ich.Zitat:
Zitat von Feenstaub
%Gewinn%:100%|50%|nichts würde einen Fehler erzeugen, weil da ein | im Variablennamen steht - die dürfen aber nur alphanumerisch sein.
%operator%:&|||:|^ ist in Ordnung. Es ist absolut okay, wenn mehrmals der gleiche Wert vorkommt (er ist dann eben wahrscheinlicher) und der Doppelpunkt hat nur am Anfang der Zeile eine Funktion. Danach gilt er als normales Zeichen.
%operator%|:Wert würde einen Fehler erzeugen. Die Zeilen fangen mit einem Variablennamen und einem Doppelpunkt an, das tut diese nicht.
@Sunny: Warum? Es gibt nur zwei Zeichen, die irgendeine Bedeutung haben und das sind % (das mit der %%-Regelung problemlos dargestellt werden kann) und | (das bisher nicht dergestellt werden kann - das korrigiere ich mal, bevor sich noch jemand aufregt).
Ich könnte natürlich die Anregung aufnehmen und verlangen, daß jeder Interpreter eine $[xxxx]-Funktion beinhaltet, wobei xxxx der Hexcode für ein Unicode-Zeichen ist. Andererseits müßte ich das ja auch programmieren.
Ähm... nicht so ganz. Ich drück' mich wohl nicht richtig aus. Sorry. Ich versuche es nochmal. (Das Problem ist, dass du die Sprache in Satzform definiert hast, anstatt vielleicht BNF oder Syntaxdiagramme... dadurch wäre die Grammatik "durchschaubarer" ^^)Zitat:
Zitat von Jesus
Ich habe meine Arbeit begonnen, indem ich mir deine Beispiele angeschaut habe:
[FONT=Courier New]Ich habe eine%Tier%.
%Tier%:n Hund| Katze[/FONT]
Das Leerzeichen vor Katze hat mir gesagt, dass das "|"-Zeichen die Trennung der Variablenwerte vornimmt. Nur so macht der Satz: "Ich habe eine(Leerzeichen)Katze." Sinn. Also habe ich mir gesagt. Das "|" trennt die einzelnen Werte KONKRET. Sprich, die Werte werden nicht links und rechts getrimmt!
[FONT=Courier New]OMG LOL%weiter%
%weiter%:!%weiter%|1%weiter%|[/font]
Hier schreibst du, dass hinter dem letzten "|" die leere Menge spezifiziert ist. Das heisst für mich: A) Eine leere Menge ist erlaubt. B) Die leere Menge ist definiert mit "kein Zeichen". C) Als letztes Zeichen in der Variablendeklaration steht entweder ein "|", dass die leere Menge mit einschliesst, oder der letzte Buchstabe eines echten Wertes (ein String).
Das führt aber zu folgender Doppeldeutigkeit:
[FONT=Courier New]%VarName%:|||[/font]
kann entweder heissen:
[FONT=Courier New]|(Leere Menge)|(Leere Menge)|[/font]
oder aber:
[FONT=Courier New]|("|"-Zeichen)|[/font]
und was ist: [FONT=Courier New][%VarName%:][/font]? Eine Variable, die nur die leere Menge enthält? Oder ist das syntaktisch falsch?
Und dann gibt esnoch etwas, dass zwar kein wirkliches Problem ist, aber die Nutzung zusäzlich erschwert. Auf Grund der Textdatei lässt sich nicht immer genau sagen, wie der Wert wirklich aussieht:
[FONT=Courier New]Das%tier%ist alt.
%tier%:| Pferd | Schaf [/font]
Hier habe ich hinter Schaf noch ein Leerzeichen. Im Text sieht man das aber nicht. Trotzdem ist die Syntax grundsätzlich richtig. Vielleicht sollte man ein Ende-Zeichen einführen? zB einen Punkt:
[FONT=Courier New]Das%tier%ist%fuellwort%alt.
%tier%:| Pferd | Schaf .
%fuellwort%: sehr | noch nicht .[/font]
Aber das ist nur ein formeller Hinweis. ;)
Zurück zu deinen Anforderungen. Von meinem bescheidenen Verständnis sähe die Variablendeklaration in EBNF etwa so aus:
Ist das so richtig? Und wie sollen wir vorgehen, wenn "AnyChar" ein '|' enthält?Code:VarDecl := "%" VarName "%" ":" (Value "|")* Value.
VarName := AlNum+.
AlNum := Alpha | Num.
Alpha := 'A'|'B'...'Y'|'Z|'a'|'b'...'y'|'z'.
Num := '0' | '1' ... '8' | '9'.
Value := AnyChar*.
Küsschen,
Feenstaub.
p.s. Sorry für den langen Post, aber Compilerbau war eine meiner Lieblingsthemen... damals... vor langer, langer Zeit... in einer weit, weit entfernten Galaxie...
Ich tippe mal drauf das, dass einen Fehler ausgibt.
Der Interpreter sollte das als ungeschlossene(?) Variable erkennen da das %-Zeichen nicht escaped ist (mit %%).
EDIT:
Mwah, total überflüssig. Ich sollte vielleicht auch mal darauf achten das es 2 Seiten in diesem Thread gibt.
Bin zwar nicht Jesus, aber ich erklär's mal so wie ich's verstanden hab:Zitat:
Zitat von Feenstaub
Man muss sich die Definition auf der ersten Seite eben mehrmals durchlesen, da Jesus sie immer wieder verändert. Ich zitiere:
Dein genanntes Beispiel würde also eine Variable mit vier leeren Mengen initialisieren, also so:Zitat:
Zitat von Jesus_666
[FONT=Courier New]%VarName%:(Leere Menge)|(Leere Menge)|(Leere Menge)|(Leere Menge)[/font]
Für ein |-Zeichen müsste der Code also so aussehen:
[FONT=Courier New]%Varname%:%|%[/font].
Ich denke mal das ist einfach ne leere Menge. Warum auch nicht?Zitat:
Zitat von Feenstaub
Ja, so einen Schluss-Punkt fände ich auch gut und so.Zitat:
Zitat von Feenstaub
freundliche Grüße, Rolus
Wenn ich erst noch allen hier die (E)BNF beibringen wollte wäre der Anfangspost mindestens dreimal so lang - und die Nachbesprechung auch. Erstaunlicherweise ist es ziemlich schwer, anderen Leuten das beizubringen, was man an der Uni gelernt hat.Zitat:
Zitat von Feenstaub
Ursprünglich sollte der Contest sich mit der Simulation eines deterministischen endlichen Automaten befassen. Nachdem ich Luki mit meinen Erklärungsversuchen, was ein DEA tut, völlig verwirrt habe hab' ich das dann lieber doch gelassen.
Das kommt so hin.Zitat:
Das Leerzeichen vor Katze hat mir gesagt, dass das "|"-Zeichen die Trennung der Variablenwerte vornimmt. Nur so macht der Satz: "Ich habe eine(Leerzeichen)Katze." Sinn. Also habe ich mir gesagt. Das "|" trennt die einzelnen Werte KONKRET. Sprich, die Werte werden nicht links und rechts getrimmt!
Zu ersterem: Das | war nicht als druckbares Zeichen vorgesehen. Für den Fall, daß jemand es doch ausgeben will habe ich in den Regeln den Sonderfall %|% eingeführt.Zitat:
Das führt aber zu folgender Doppeldeutigkeit:
[FONT=Courier New]%VarName%:|||[/font]
kann entweder heissen:
[FONT=Courier New]|(Leere Menge)|(Leere Menge)|[/font]
oder aber:
[FONT=Courier New]|("|"-Zeichen)|[/font]
und was ist: [FONT=Courier New][%VarName%:][/font]? Eine Variable, die nur die leere Menge enthält? Oder ist das syntaktisch falsch?
Zu letzterem: %VarName%: würde ich tatsächlich als eine Variable, die nur ein leeres Wort enthält, betrachten.
BTW, du kannst statt dem [font]-Tag auch den [tt]-Tag verwenden, den es seit Kurzem gibt. Der ist plattformunabhängiger (nicht jedes Betriebssystem muß eine Courier New-Schriftart haben).
Stimmt, allzu lesbar ist mein Format nicht. Ich mache trotzdem keine Zeilenenden rein, das wäre in erster Linie eine kosmetische Veränderung.Zitat:
Und dann gibt esnoch etwas, dass zwar kein wirkliches Problem ist, aber die Nutzung zusäzlich erschwert. Auf Grund der Textdatei lässt sich nicht immer genau sagen, wie der Wert wirklich aussieht:
[FONT=Courier New]Das%tier%ist alt.
%tier%:| Pferd | Schaf [/font]
Hier habe ich hinter Schaf noch ein Leerzeichen. Im Text sieht man das aber nicht. Trotzdem ist die Syntax grundsätzlich richtig. Vielleicht sollte man ein Ende-Zeichen einführen? zB einen Punkt:
[FONT=Courier New]Das%tier%ist%fuellwort%alt.
%tier%:| Pferd | Schaf .
%fuellwort%: sehr | noch nicht .[/font]
Aber das ist nur ein formeller Hinweis. ;)
Habe ich schon in den Regeln festgelegt, nach meinem letzten Post. %|%. Ist zwar etwas häßlich, aber ich bin nie davon ausgegangen, daß jemand ein | ausgeben will...Zitat:
Zurück zu deinen Anforderungen. Von meinem bescheidenen Verständnis sähe die Variablendeklaration in EBNF etwa so aus:
Ist das so richtig? Und wie sollen wir vorgehen, wenn "AnyChar" ein '|' enthält?Code:VarDecl := "%" VarName "%" ":" (Value "|")* Value.
VarName := AlNum+.
AlNum := Alpha | Num.
Alpha := 'A'|'B'...'Y'|'Z|'a'|'b'...'y'|'z'.
Num := '0' | '1' ... '8' | '9'.
Value := AnyChar*.
Küsschen,
Feenstaub.
(E)BNF ist auf jeden Fall ein besseres Thema als Programmsemantik.Zitat:
p.s. Sorry für den langen Post, aber Compilerbau war eine meiner Lieblingsthemen... damals... vor langer, langer Zeit... in einer weit, weit entfernten Galaxie...
Klingt interessant. Aber 2 Fragen:
1. Du sagst was von jeder erdenklichen Programmier- oder Skriptsprache? Soll das heißen, dass PHP theoretisch auch erlaubt wäre? Nicht, dass ich vorhätte, das in PHP zu machen.
2. Ist es beabsichtigt, dass die Variablen entgegen jeder (mir bekannten) Regel erst ausgegeben und dann definiert werden? In dem Fall isses zwar ziemlich egal, weil jede Variable nur einmal definiert werden kann, aber trotzdem isses unlogisch und umständlich. Das würde jede Erweiterung der Sprache unmöglich machen.
Ich habe vor, einen Interpreter in PHP zu schreiben. Jede Programmier- und Skriptsprache, die nicht gerade ein Spezialtool zum Bau von Compilern ist.Zitat:
Zitat von DFYX
Du gehst davon aus, daß es sich um eine Skriptsprache handelt. Es ist aber lediglich eine Spielerei, die nichts anderes tut, als einen String mit Zufallskomponenten auszugeben. Da soll nichts erweitert werden.Zitat:
2. Ist es beabsichtigt, dass die Variablen entgegen jeder (mir bekannten) Regel erst ausgegeben und dann definiert werden? In dem Fall isses zwar ziemlich egal, weil jede Variable nur einmal definiert werden kann, aber trotzdem isses unlogisch und umständlich. Das würde jede Erweiterung der Sprache unmöglich machen.
Die Notation habe ich übrigens vom Inputformat eins ähnlichen Programms übernommen, das in Perl geschrieben war. Leider habe ich keinen Link oder ein Beispiel.
Doppelpost weil regelkritisch.
Aus irgendeinem Grund ist noch niemand auf die Idee gekommen, nach der Operatorpräferenz zu fragen. Sprich, ob % oder | Vorrang hat.
Ich sage mal, daß | Vorrang hat, also zurst ausgewertet wird. Immerhin sollen die Variablen ja innerhalb der einzelnen Werte gelten und die Werte werden durch | getrennt.
Auß0erdem habe ich den Kommentar, [tt]%|%[&tt] sei die einzige Möglichkeit, zwischen zwei Prozentzeichen nicht-alphanumerisch zu schreiben, entfernt. Ich gehe nicht ins Detail, aber rein theoretisch gibt es da dieses leere Wort namens Lambda...
Und wie benutzt man dann | in Variablen? Wenn | Vorrang hat wirdZitat:
Zitat von Jesus_666
jaCode:%var%:blabla %|% bla
Was wiederum zum Parsererror führt.Code:%var%[0]=blabla%
%var%[1]=% bla
Guter Eiwand. Ja, da habe ich in der Tat Unsinn gedacht. % hat natürlich Vorrang.Zitat:
Zitat von Dingsi
*notiert sich: Nicht mehr spät nachts versuchen, zu denken*
Mir wird das alles zu komplex und seltsam, sorry aber irgendwie ist das ein komisches Thema. Ein klares Ziel wäre schön, dessen Weg dort hin sich jeder selber suchen kann. Das wär ein gutes Contest thema. Aber hier gibt's bald mehr Regeln und Dinge zu beachten als in der deutschen Verkehrsverordnung.
Gute Idee, Sunny. Wollen wir einfach festlegen, dass % und | nicht anders als als Operatoren behandelt werden müssen?
Nun, sie tun Dinge. Sie sind das, was in dieser kleinen Billigsprache einem Operator am nächsten kommt - aber es ist an sich egal, wie man sie betrachtet.Zitat:
Zitat von Dingsi
@Sunny: Ich muß auch zugeben, daß ich das Thema unterschätzt habe. Die Definition selbst einer einfachen nichttrivialen Sprache ist ziemlich aufwendig, weil man Dinge berücksichtigen und explizit angeben muß wie die Reihenflge, in der die Sache verarbeitet wird oder das exakte Format von Variablennamen in Abhängigkeit von der Mondphase.
Wenn ich gewußt hätte, worauf das hier hinausläuft hätte ich wohl einen Rechner mit polnischer Notation verlangt, die ist einfacher zu definieren.
BTW, es ist trotz der Regeln nicht sooo aufwendig, einen Interpreter zu bauen. Ich habe in drei Stunden den kompletten Parser mit allen Fehlerchecks implementiert gekriegt (allerdings in PHP; mal sehen wie's in Java aussehen wird).
Mhm, also ich finde das Thema *ein bisschen* zu schwierig, und da ich sowie so nicht genügend Zeit finden werde lass ichs für's erste.
[Ich habs soweit das ich unendlich Vars deklamieren könnte, allerdings keine Vars in Vars.
Das ganze dann als Lustige Delphi Konsolen-App mit dem Namen 'Jesus_666-Skript Interpreter' :D)
Ack.Zitat:
Zitat von Sunny
Nichts gegen Plattformunabhängigkeit, bin ich auch voll dafür. Aber wenn ich das ganze erst 'ne halbe Stunde entziffern muss, dann verliere ich irgendwann die Lust am Lesen.Zitat:
Zitat von Jesus
Mein Firefox + WinXP stellt das dar:
BTW, warum hast du es mit dem "|"-Operator so kompliziert und anders gemacht als mit dem %%? Wie ich oben bereits erwähnte, wäre a) die Benutzung des "%"-Zeichen als Escape-Charakter und b) eine geteilte Semantik für die Ausgabezeile und die Variablendeklarationen wesentlich durchschaubarer und auch selbst ohne Syntaxdiagramm mit Worten einfacher zu beschreiben. ... ... (glaube ich zumindest ^^)
Küsschen,
Feenstaub.
Hm, scheint doch recht häufig zu sein, daß eine Schriftgröße Unterschied sich extrem äußert. Ich werde mal Chocwise bitten, daß er den [tt]-Tag auf die normale Schriftgröße zurcksetzt und bei mir clientseitig die Schrift verkleinern.Zitat:
Zitat von Feenstaub
Ich will statt %| %|%, weil das die Überprüfung auf nicht-geschlossene Variablennamen einfacher macht. Im Nachhinein wäre \ als Escapezeichen vielleicht doch keine schlechte Idee gewesen. Wenn genug Leute dafür sind ändere ich meinetwegen die Regeln nochmal - die sind ja sowieso noch im Fluß.
Was meinst du mit geteilter Semantik?
\ als Escapezeichen = gut.