Mit dem kannst du weitere Befehle (auf die gleiche Weise wie MAP) einbinden, so Ideen wie X!READ oder X!LIST oder wie auch immer.
Äh. Herr Lehrer? 
In Ihrem Beispiel zu Map kommt doch der X! Befehl gar nicht vor. Was also macht der?
TSB Info
- GoDot
- Thread is Unresolved
-
-
Was also macht der?
Nichts. (Nur die bekannte Fehlermeldung.)
Er könnte aber...
Arndt
-
Nichts. (Nur die bekannte Fehlermeldung.)
Er könnte aber...Ach so. Jetzt ist mir alles klar.
-
Siehst du!
Arndt
-
Das ganz große Update! Nichts ist mehr, wie es vorher war!
Vielen Dank für die Mühe, die du dir damit gemacht hast. Ich finde die Anpassungen auf der Website sehr gut gelungen.
Neu für Programmierer: Die IF..THEN DO..ELSE..DONE-Konstrukte sind jetzt verschachtelbar
Das ist brillant. Ein langersehnter Traum in der Programmierwelt ist endlich wahr geworden.
Der TSB-Fanclub ist außer sich vor Freude.
-
Die IF..THEN DO..ELSE..DONE-Konstrukte sind jetzt verschachtelbar, ...
Hat das in der Vergangenheit mal jemand angefragt?
-
Darf ich mal ein bisschen Haarspalterei betreiben? Wenn ich die TSBneo -Disk im Emulator einlege, dann wird der Inhalt der Diskette stets in Großbuchstaben angezeigt. Und der Titel der TSBneo-Diskette ist dann leider nicht richtig lesbar. Man weiß also nicht, ob es sich um "TSB neo" oder um "GUT neo" oder um "AHA neo" handelt. Es sei denn man hat den Studiengang "Bachelor of PETSCII Arts" mit erfolgreichem Abschluss besucht.
-
Und der Titel der TSBneo-Diskette ist dann leider nicht richtig lesbar. Man weiß also nicht, ob es sich um "TSB neo" oder um "GUT neo" oder um "AHA neo" handelt.
Im Directory wird doch TSB angezeigt ...
-
Wenn ich die TSBneo -Disk im Emulator einlege, dann wird der Inhalt der Diskette stets in Großbuchstaben angezeigt.
Ah, danke! Das hab ich übersehen! Wird korrigiert. (Ist ein DirMaster-Fehler, die haben es - nach wie vielen Jahren? - immer noch nicht geregelt gekriegt, im Directory PETSCII statt ASCII einzusetzen!
)Arndt
-
Mal etwas ganz anderes: Wenn man in einem TSB-Programm Sprungmarken einsetzen möchte, dann macht man das genauso, als wenn man eine Prozedur einleiten würde. Also mit dem PROC-Befehl. Das finde ich stets irritierend. Man kann beim Durchsehen der Programmzeilen nicht auf den ersten Blick unterscheiden, ob es sich um ein Sprungmarke oder den Anfang einer Prozedur handelt.
Wäre es irgendwie möglich, dass man in TSB die Sprungmarken eindeutig von den Prozedurköpfen unterscheidet? Man würde dann nicht den PROC-Befehl zum Definieren einer Sprungmarke verwenden, sondern etwas anderes.
Bei VB verwendet man den Doppelpunkt am Ende einer Zeile, um eine Sprungmarke zu definieren. Wohingegen Prozeduren mit "Sub" und "End Sub" definiert werden.
Wäre der Luxus, Prozedurköpfe und Sprungmarken unterscheiden zu können, auch in TSB denkbar?
-
Wäre der Luxus, Prozedurköpfe und Sprungmarken unterscheiden zu können, auch in TSB denkbar?
Das hatte ich sogar schon mal mit petrus diskutiert. Ich hatte da an ein Schlüsselwort LABEL gedacht. Leider würde dadurch ein Rattenschwanz an Folgeerscheinungen im Code entstehen (Unterscheidung zwischen PROC und LABEL in den Suchroutinen usw.), und da der Platz dafür niemals reichen würde, habe ich das Projekt als undurchführbar abgehakt. Übrigens rührt von dieser Diskussion die Einführung der Schlüsselwörter CLS, MAP und X! her.
Arndt
-
...und da der Platz dafür niemals reichen würde, habe ich das Projekt als undurchführbar abgehakt.
Okay. Dann werde ich mich damit begnügen müssen, dass ich ich den "Prozedurnamen" für Sprungmarken ein SPR oder ein ähnliches Präfix voranstelle. Damit man sie von den Prozedurköpfen unterscheiden kann.
-
Wäre der Luxus, Prozedurköpfe und Sprungmarken unterscheiden zu können, auch in TSB denkbar?
Das hatte ich sogar schon mal mit petrus diskutiert. Ich hatte da an ein Schlüsselwort LABEL gedacht. Leider würde dadurch ein Rattenschwanz an Folgeerscheinungen im Code entstehen (Unterscheidung zwischen PROC und LABEL in den Suchroutinen usw.), und da der Platz dafür niemals reichen würde, habe ich das Projekt als undurchführbar abgehakt. Übrigens rührt von dieser Diskussion die Einführung der Schlüsselwörter CLS, MAP und X! her.
Arndt
Würde denn der Platz für ein zusätzliches Token (z.B. "LABEL") ausreichen? Wenn das exakt das Gleiche wie PROC macht, also nur ein Alias dafür ist, ohne weiteren Code zu beanspruchen, dann könnte man LABEL sprungmarke statt PROC sprungmarke schreiben.
Intern würde das als PROC sprungmarke verarbeitet werden (also keinen neuen Code erfordern), aber im Listing würde man LABEL sprungmarke sehen, was optisch den Unterschied ausmacht, den Omega angesprochen hat.
-
Okay. Dann werde ich mich damit begnügen müssen, dass ich ich den "Prozedurnamen" für Sprungmarken ein SPR oder ein ähnliches Präfix voranstelle. Damit man sie von den Prozedurköpfen unterscheiden kann.
Gute Idee!
Intern würde das als PROC sprungmarke verarbeitet werden (also keinen neuen Code erfordern), aber im Listing würde man LABEL sprungmarke sehen, was optisch den Unterschied ausmacht, den Omega angesprochen hat.
Du brauchst zur Unterscheidung aber ein neues Token, sonst wüssten weder der Tokenizer noch der Detokenizer etwas mit LABEL anzufangen. Um dieses „kleine“ Detail geht es.
Arndt
-
-
Ich finde die Idee von Snoopy gut. Wäre es denn so aufwändig, ein neues Token namens LABEL einzuführen?
Nein, das ist ja bereits vorhanden ("X!" umbenennen). Das Problem ist der Rattenschwanz hinten dran (Erkennung im laufenden Programm, Differenzierung bei den Suchroutinen: PROC, CALL und EXEC werden von Suchroutinen "bedient", die dann wissen müssten, dass es dieses neue Token gibt und was es damit auf sich hat. LABEL dürfte nur bei CALL reagieren, nicht aber bei EXEC, das müsste zusätzlich auch noch mit als Fehlermöglichkeit einprogrammiert werden, mitsamt Fehlermeldungstext.)
Arndt
-
Das mit dem X! umbenennen verstehe ich nicht. Wie geht das?
-
Ich finde die Idee von Snoopy gut. Wäre es denn so aufwändig, ein neues Token namens LABEL einzuführen?
Nein, das ist ja bereits vorhanden ("X!" umbenennen). Das Problem ist der Rattenschwanz hinten dran (Erkennung im laufenden Programm, Differenzierung bei den Suchroutinen: PROC, CALL und EXEC werden von Suchroutinen "bedient", die dann wissen müssten, dass es dieses neue Token gibt und was es damit auf sich hat. LABEL dürfte nur bei CALL reagieren, nicht aber bei EXEC, das müsste zusätzlich auch noch mit als Fehlermöglichkeit einprogrammiert werden, mitsamt Fehlermeldungstext.)
Ich schreibe mal meine Gedanken dazu:
CALL muss dann nur noch nach dem LABEL-Token suchen und nicht mehr nach PROC, da müsste eigentlich nur der Tokenwert, nach dem gesucht wird, ausgetauscht werden.
Und EXEC und PROC können LABEL komplett ignorieren, weil sie mit LABEL nichts zu tun haben, da müsste man meiner Ansicht nach nichts ändern.
-
Ich habe mir mal den Quellcode und auch die Einträge im C64-Wiki zu TSB angeschaut. Wenn ich ehrlich bin, ist mit der Unterschied zwischen CALL und EXEC nicht ganz klar. Machen die Befehle nicht das Gleiche?
