Diskussion:Locomotive BASIC

Abschnitt Funktionsweise:

Die Zeiten wechseln wild!

Ed --79.224.210.203 01:20, 29. Nov. 2012 (CET)

Die BASIC-Beispielprogramme verwenden kleingeschriebene Befehle (print, input, ...). Dies ist falsch, inbesondere wenn der Befehl sich in einer Zeilennummer befindet. Der Grund dafür ist der, dass die im Zeileneditor eingegebene Zeile nach Drücken der Eingabetaste vorübersetzt wird. Zum Beispiel wird aus den fünf Buchstaben "print" der Code des PRINT-Befehls ermittelt und abgespeichert. Das hat zur Folge, dass in der Liste der Programmzeilen nun immer PRINT steht und nicht print oder Print oder andere Schreibweisen. Es müssen also alle BASIC-Befehle (jedenfalls die mit Zeilennummer davor) ausschließlich groß geschrieben werden. Locomotive BASIC unterscheidet, wie die meisten anderen BASIC-Dialekte auch, nicht zwischen Groß- und Kleinschreibung. D. h., dass flaeche und FLAECHE identische Variablen bezeichnen. Auch kann der Befehl print in Kleinschreibung direkt eingegeben und ausgeführt werden. Innerhalb einer Zeilennummer allerdings, wird jeder erkannte Locomotive-Befehl wie bereits erläutert, ausschließlich in Großschrift angezeigt bzw. gespeichert. (nicht signierter Beitrag von 82.210.249.4 (Diskussion) 15:40, 23. Apr. 2013 (CEST))

Schreibweise BASIC Befehle

Ich habe nochmals die Schreibweise der in Token umgewandelten Basic-Befehle überprüft: Sowohl im Original-Benutzerhandbuch eines Schneider CPC 464 von 1985 als auch in einer CPC 6128 Emulationssoftware als auch im Wikipedia-Artikel zum Amstrad CPC 464/664/6128 findet die Tokenisierung statt bzw. wird davon berichtet. Ergo sind die Basic-Befehle groß zu schreiben und der entsprechende neue Abschnitt, der erläutert, dass Locomotive Basic bereits bei Eingabe die Befehle in Token vorübersetzt sollte nunmehr gesichtet und in den Artikel übernommen werden. (nicht signierter Beitrag von 82.210.249.4 (Diskussion) 16:02, 25. Apr. 2013 (CEST))

Strukturierte Programmierung

Ich will den Artikel nicht selber ändern, weil meine Programmierkenntnisse zu schlecht sind, und ich nicht sicher bin, ob alles, was ich jetzt anführe, korrekt ist. Aber einen Einwand/Diskussionspunkt hätte ich trotzdem. Im ersten Abschnitt des Artikels heißt es:

"Entsprechend der Entwicklungszeit fehlen allerdings die großen Ansätze des strukturierten Programmierens weitgehend, werden aufgrund des häufig überschaubaren Programmierumfanges aber auch noch nicht wesentlich vermisst bzw. mit anderen Methoden wie den berüchtigten GOTOs dann doch gekonnt umgesetzt."

Ich halte diese Aussage für falsch. Gerade die Möglichkeit, in Basic recht nahe an das "Ideal" der Strukturierten Programmierung heranzukommen, war bei seinem Erscheinen ein Alleinstellungsmerkmal des Schneider CPC. Locomotive Basic bietet - meines Wissens nach 1984 als einziger serienmäßiger Basic-Dialekt - einen sehr brauchbaren Ansatz zur strukturierten Programmierung. Die zentralen Anforderungen der Strukturierten Programmierung wie Zerlegung in Teilprogramme, Vermeidung von Sprunganweisungen (z. B. GOTO), lediglich drei Kontrollstrukturen, lassen sich mit Locomotive Basic umsetzen. Codewiederholungen können ausgeschlossen werden.

Im Mittelpunkt steht das Befehlspaar GOSUB - RETURN. Zwar erfordert GOSUB immer noch die Angabe der Zeilennummer eines Teilprogrammes, RETURN springt aber automatisch an die Stelle zurück, von der aus das Teilprogramm aufgerufen wurde.

Selbst umfangreiche Programme können so ohne eine einzige Sprunganweisung (GOTO) realisiert werden. Die einzelnen Unterprogramme können modulartig eingefügt werden, weil Einsprung und Ende jedes Unterprogrammes genau definiert werden können bzw. das System den Korrekten Rücksprung verwaltet. Jeder Teil des Hauptprogrammes (oder eines Unterprogrammes) kann jederzeit per "GOSUB" auf ein Unterprogramm zugreifen, ohne, dass der Programmierer am Ende des Unterprogrammes sich Gedanken á la "GOTO wohin soll ich zurückspringen?" machen muss. RETURN regelt das. Mehrere verschachtelte GOSUB - RETURN Instanzen sind möglich.

Beispiel:

10 REM Deklarationen (meist optional)
20 a=1, i=1, wait=100

100 REM Hauptprogramm
110 WHILE a<100: REM Beginn Schleife 99 Durchläufe
120 GOSUB 1000
130 GOSUB 2000: REM Aufruf des Unterprogramms Warteschleife aus dem Hauptprogramm
140 a=a+1
150 WEND: REM Ende Schleife

160 GOSUB 3000
170 END

900 REM Hier beginnen die Unterprogramme
1000 REM Unterprogramm Textausgabe
1010 PRINT "Hello World! Durchlauf: "+a
1020 RETURN

2000 REM Unterprogramm Warteschleife
2010 FOR i=1 TO wait: NEXT i
2020 RETURN: REM RETURN verwaltet automatisch das korrekte Rücksprungziel, in diesem Beispiel einmal ins Hauptprogramm, einmal in das Teilprogramm Programmende

3000 REM Unterprogramm Meldung Programmende
3010 PRINT "Programmende"
3020 wait=999: GOSUB 2000: REM Aufruf des Unterprogramms Warteschleife aus einem Unterprogramm, Variable wait übergibt abgeänderte Wartezeit. Jetzt sind zwei GOSUB - RETURN Instanzen verschachtelt
3030 CLS
3040 RETURN

4000 REM Hier und am Ende der anderen Unterprogramme ist kein END nötig. Das Hauptprogramm und jedes Subprogramm kennt genau einen Anfang und ein Ende :)

Da Locomotive Basic bei der Vergabe von Zeilennummern sehr flexibel ist, und mittels des Befehls RENUM das Programm oder Teile des Programms neu numeriert werden können, lassen sich Teilprogramme auch nachträglich ändern, erweitern oder neu einfügen, ohne dass dabei der mit GOTO-Strukturen übliche Spaghetti-Code entsteht. Gängige Programmierpraxis war, jedem Unterprogramm einen eigenen "Tausenderbereich" zuzuweisen, während das Hauptprogramm oft im "Hunderterbereich" geschrieben wurde. In anderen Basic-Dialekten entstand Spaghetti-Code oft auch dadurch, dass eine nachträgliche Neunummerierung der Zeilen nicht möglich war und den Programmierern der Platz zwischen den bestehenden Zeilen ausging.

Schließlich bietet der Befehl ON variable GOSUB Zeilex, Zeiley, Zeilez sogar noch eine Auswahl-Verzweigung zu einzelnen Teilprogrammen - ohne GOTO und IF ... THEN ... Konstruktionen

--95.91.232.145 02:56, 24. Nov. 2014 (CET)

Tokenisierung machte eigentlich jedes Basick weil irgendwann muss man es parsen und besser vor der Laufzeit, außerdem läuft sonst der Speicher voll.