Absender: Timo Sandmann
Datum: Mi, 30.03.2011 16:05:44
In-reply-to:
<20110329231209.3a643626.bergeruw@xxxxxxx>
References:
<1ac236efdb2ae353dba0652e0009d0d7.squirrel@xxxxxxxxxxxxxxxxxxx> <BDD47587-412D-4D50-AC42-4B488A95575E@xxxxxxxxxxxxxxx> <4CF809BA.3070600@xxxxxxx> <B796DEF3-49CB-4F9A-B0AA-D42C7000926D@xxxxxxxxxxxxxxx> <20110309225657.432787bb.bergeruw@xxxxxxx> <4D19D5D5-4972-4D76-95F1-AFA65B36A076@xxxxxxxxxxxxxxx> <4D80E3E5.8050702@xxxxxxx> <C2269E6E-EBB2-40E9-B1EB-06984CD3ECDF@xxxxxxxxxxxxxxx> <9DDF1CF6-342A-4681-8296-77899A820AA8@xxxxxxxxxxxxxxx> <20110320213615.6522f43a.bergeruw@xxxxxxx> <6FB8CA6E-9D8F-4556-936C-0B0CC95B789A@xxxxxxxxxxxxxxx> <1a7fbb756d29789435f7638aa199bea6.squirrel@xxxxxxxxxxxxxxxxxxx> <77714C4A-E5BA-4D31-AFE5-4D20122ACC7C@xxxxxxxxxxxxxxx> <4D921683.5060902@xxxxxxx> <CEAAFE4A-1B5A-4163-ABAF-053B7261EC0A@xxxxxxxxxxxxxxx> <20110329231209.3a643626.bergeruw@xxxxxxx>
Hallo, Am 29.03.2011 um 23:12 schrieb Uwe Berger: > ich hätte jetzt nicht gedacht, dass jemand so intensiv die EBNF in der Doku liest :-). Für die letzte Änderung habe ich sie wahrscheinlich nur halbherzig angepasst, mal sehen ob es trotzdem passt: na ja es ist ganz praktisch, um einen Überblick über den Sprachumfang zu bekommen und nicht alles auch gleich ausprobieren zu müssen (insbesondere natürlich, wenn man den Code noch nicht mal eingebaut hat...) > korrekt, es sind nur Zahlen zugelassen. Das ist der Kompromiss um auch die alte Zeilennummerierung zuzulassen. Text-Label hätten einen größeren Eingriff im Code erfordert. Ja verständlich, durch den Doppelpunkt sah es für mich nur erst so aus, als wenn Labels anders behandelt würden als Zeilennummern. > ja. Ich habe den Doppelpunkt nur deshalb optional zugelassen, weil Label in vielen BASIC-Dialekten mit selbigen Zeichen gekennzeichnet werden. Das kannte ich eben nur mit Text-Labels, daher die Frage, wie Labels aussehen müssen. Aber ich habe a) schon länger nichts mehr mit Basic programmiert und b) kaum goto benutzt. >> - Auf das Label muss immer auch noch eine Anweisung in derselben Zeile folgen? >> goto 10 >> 10: von B >> print "hier ist korrekt..." >> wäre also kein gültiges Programm? >> > hmm, in der Hinsicht ist die Darstellung im EBNF (ungewollt) richtig. Es muss ein Statement kommen, ansonsten wird ein Syntax-Fehler geschmissen. (habe ich gerade ausprobiert) > > Absicht ist es aber nicht und werde ich mir nochmal anschauen. Eigentlich hatte ich in der aktuellen Version reichlich Gehirnschmalz in solcher Sachen wie Leerzeilen und Einschübe verwendet, um die Formatierung von BASIC-Quelltext zu ermöglichen (Frank hatte sich da beschwert, dass es bisher nicht möglich war...:-)). Ungetestet dachte ich damit auch Label ohne Statement zugelassen zu haben. Aber wenn man nicht testet, kann man nie sicher sein...;-) Ah ok. >> - Laut EBNF wäre auch folgendes Programm gültig: >> GOTO CALL ("foo", 42) >> das dürfte aber wohl kein korrektes Programm sein. >> > doch, für den Fall dass call() eine Funktion, also mit Rückgabewert (natürlich vom Typ Integer) ist! Das ist eine ganz bewußte Geschichte, die ich vor einigen Versionen eingeführt habe: die Sprungziele von GOTO und GOSUB können auch Ergebnisse von Ausdrücken sein. Das ermöglich ein paar interessante Programmkonstrukte: Ach so, das ist natürlich eine feine Sache. Mir ging es übrigens nicht darum, kleinlich nach Bugs zu suchen, der Hintergrund ist viel mehr die Überlegung, evtl. eine Syntaxprüfung in den Basic-Programm-"Editor" mit einzubauen, so dass Syntaxfehler schon vor der Übertragung zum Bot direkt im Quellcode angezeigt werden. Dafür möchte man aber wohl nicht den Parser des uBasic-Interpreters noch mal implementieren. Deutlich sinnvoller wäre es, einen Parser automatisch aus der EBNF-Grammatik erstellen zu lassen. Dafür muss die EBNF aber natürlich auch möglichst genau stimmen, gerade was Leerzeilen / -Zeichen usw. angeht, ist das evtl. etwas stressig. Grüße, Timo