BlitzBasicScript

Worklogs BlitzBasicScript Kommentare

Montag, 21. Januar 2019 um 12:21 Uhr von DAK

Starke, bzw. schwache Typisierung hat leider keine richtige Definition. Eine Definition für Starke Typisierung ist z.B. keine impliziten Konvertierungen. Eine andere Definition ist die statische Typisierung.

Um das also auf besser definierte Worte zu stellen: BB hat implizite Konvertierungen (z.B. "3"+4 => "34", oder i = "34" ergibt eine Konvertierung des Strings auf int), aber eine statische Typisierung (da jede Variable fix und unänderbar einen Typ hat, und dieser Typ dauerhaft so bleibt). JS hat auch implizite Konvertierung aber dynamische Typisierung, da einer Variable Werte unterschiedlichen Typs zugewiesen werden dürfen.

BB hat (ähnlich wie JS) ziemlich blöde Umwandlungsregeln. So wird beim Cast auf int "10" auch 10 (wie erwartet), aber "0x10" ergibt 0, genauso wie "A10" oder "True" (beim ersten Fall könnte man hoffen das BB Hex unterstützt, beim zweiten Fall könnte Blitz alle nicht-numerischen Werte strippen, beim dritten Fall könnte Blitz "True" als True also 1 behandeln.). Auch sinnvoll möglich wäre hier eine Exception, die sagt, dass der Wert nicht umgewandelt werden hat können, aber es gibt in BB ja auch keine Exceptions, also that's that.

Wenn da BBS mit BB kompatibel sein soll, dann müsste man all den Schwachsinn da auch mit rein nehmen. In JS verhält sich das nämlich anders. Auch gibt es in JS auch echte Booleans (true und false) im Gegensatz zu BB, wo True==1 und False==0 und beides einfach als Int behandelt wird.

Samstag, 19. Januar 2019 um 19:09 Uhr von Thunder

Ich weiß genau was du meinst! Wie ich begonnen habe BB zu lernen, habe ich mal stundenlang diesen Fehler gesucht!
Das ist aber eigentlich ein Beispiel für schwache Typisierung, soweit ich die Begriffe richtig verstehen. Bei starker Typisierung würde der Compiler hier einen Error geben, weil er den String "Hallo Welt" nicht in ein Int konvertieren kann. Das schwach typisierte BB nimmt aber eine "Konvertierung" vor (wenn ich mich richtig erinnere wird einfach 0 zugewiesen). Also implizite Typumwandlungen sprechen für schwache Typisierung, und die hast du afaik in BB und in Javascript.

Aber: Javascript ist dynamisch typisiert und BB statisch.
Btw: du brauchst das Dollarzeichen oder die Raute # nur bei der ersten Verwendung der Variable - auch hier gilt: wenn ich mich richtig erinnere - damit der Compiler dem Symbol einen Typ zuordnen kann.

Jo, die Syntaxänderung mit dem = und == ist natürlich leichter zu kompilieren. Aber das ist nicht immer leichter für den Computer. Andererseits gibt es genug Beispiele für "leichte" Programmiersprachen (Lua, Python, Go), die die Unterscheidung machen, also, und auch weil es dein Projekt ist, bleibt es schlussendlich dir überlassen.

Ich finde aber Compilerbau sehr interessant und gebe gerne meinen Senf dazu! Very Happy

Donnerstag, 17. Januar 2019 um 11:49 Uhr von Spark Fountain

@Thunder: Danke für den Hinweis mit dynamischen Datentypen. Wobei BB dem Programmierer gegenüber ja eher suggeriert, es würde stark typisiert sein, denn sonst bräuchte man aus meiner Sicht nicht immer die Suffixe %, $ und #. Sehr nervig finde ich bis heute sowas:

Global message = "Hello World"
Print message

Und das nur, weil man ein Dollarzeichen vergessen hat anzuhängen... Was den Vergleichsoperator angeht, so hätte es schlicht für den Lexer den Vorteil, dass er leichter entscheiden kann, um welche Operation es sich handelt (Zuweisung oder Vergleich). Momentan habe ich auch die ==-Variante implementiert, denn sonst müsste der Lexer entweder den Kontext der Tokens um das Gleichheitszeichen analysieren, oder es gäbe nur ein allgemeines "="-Token und der Parser darf dann immer alles entscheiden. Letzteres wäre aber mit viel Refactoring verbunden, weil ich eine Tokenklasse "Comparison" eingeführt habe, welche ich dann nicht mehr so verwenden könnte.

Mittwoch, 16. Januar 2019 um 23:04 Uhr von Thunder

Habe mir jetzt auch ein paar Gedanken zur Hauptschleife gemacht und denke, dass die Lösung von dir gut ist. Da kann man leider nicht viel machen.

Feedback zu den anderen Vorschlägen
-Goto und Gosub werden nicht unterstützt -> voll ok
-es wird schwach typisiert -> schwach? BB ist auch schwach typisiert. Meinst du dynamisch?
-der Vergleichsoperator wird von = zu == verändert, um mehr Eindeutigkeit zu haben -> finde ich nicht so gut.
Was würde dann in BBScript ein If (x = y == 2) bewirken? Das = auch als Vergleichsoperator zu benutzen, macht
die Sprache leichter. Falls du die Unterscheidung dennoch machen willst, würde ich den Zuweisungsoperator in
diesem Kontext verbieten.
-dim-Arrays müssen keine feste Größenangabe mehr bekommen -> ok

Montag, 14. Januar 2019 um 16:07 Uhr von DAK

Die Hauptschleifenerkennung ist eigentlich prinzipiell unmöglich. Dafür müsstest du in etwa das Halteproblem lösen. So eine Lösung wie du sie hast scheint die einzige Möglichkeit zu sein... Außer, du definierst Repeat Until als Hauptschleife, währen While einfach eine normale While-Schleife bleibt. Nur damit du nicht insgesamt vier verschiedene Schleifenarten (While, Repeat-Until, For, MainLoop) brauchst.

@Datenströme

Dienstag, 8. Januar 2019 um 19:03 Uhr von Eingeproggt

Servus,

Gute Beschreibung, gute Absicht Smile
Inwiefern man alte BlitzBasic-Programme damit in den Webbrowser transferieren kann wird aber noch eine knifflige Frage.

Ein Problem hast du gut beschrieben, die Files und FileHandles.
Aus meiner Sicht gibt es unterschiedliche "Anwendungsbereiche":

1) Lokale Dateioperationen
Mein Lieblings-Anwendungsfall, für den ich BB bis vor ~1.5 Jahren regelmäßig verwendet habe (auf Windows... bin mittlerweile auf Linux). So eine Art "Batch Verarbeitung", wenn ich zB alle Dateien in einem Ordner nach einem Schema umbenennen will.
Das geht logischerweise im Web nicht - ist absolut nicht dafür gedacht. Und darauf müsste man keine gesonderte Rücksicht nehmen.

2.) Spieldaten (Maps, Config, Items,...) laden (bis hin zum "Leveleditor")
Das macht man in der Webprogrammierung komplett anders. Da bietet sich zB JSON an. Die JSON files liegen entweder - wie alle anderen Resourcen - am Webserver... oder werden aus einer Datenbank geladen. Diese Datenbank hast du ja in gewissermaßen "nachgemacht" mit deinem php-Ansatz? Es verträgt sich nicht ganz mit dem Gedanken, alte Programme zu portieren... Aber in dem Fall würde ich fast empfehlen, sollen die Entwickler sich doch an die Web-Technologien "anpassen". Anstatt (mit einigen Einschränkungen und erneuten Anpassungen) die Read- / Write- Befehle zu "erzwingen".

3.) Lokale Highscores
Wir haben wohl alle mal ein Spiel geschrieben, das den Highscore lokal in eine Textdatei oder so geschrieben hat. Wenn man das ins Web übertragen will, wäre mein erster Gedanke Cookies? Ja, ich hab in den letzten Jahren auch immer wieder mit Web-Entwicklung zu tun gehabt... aber ich muss peinlich-berührt eingestehen dass ich jetzt gar nicht weiß, ob JS die Cookies manipulieren kann? Ich denke schon (Cookies der eigenen Domain natürlich)?

4.) Online-Highscores
Das ist kein Anwendungsfall von lokalen Dateien Wink Das ist eher das, was man in BB immer mühsam selbst mit einem php-Skript und einem eigenen Webspace / Server nachprogrammieren musste. Im Grunde hast du das jetzt getan, oder? Heißt, aus meiner Sicht ist deine aktuelle Lösung eine Art "Online Datenbank"... und damit schon recht weit von Files und Filehandles entfernt. Wer unbedingt einen Online-Highscore braucht, der hat vermutlich ohnehin schon seine eigene Lösung dafür parat.

Zusammen gefasst will ich damit sagen:
Warum zwanghaft mit einem php-Skript diese Datenströme "nachbilden"? Ich würd in einer ersten "Bauchgefühl-Reaktion" komplett drauf verzichten? (Natürlich hast du da schon länger drüber nachgedacht Wink )

Sonntag, 6. Januar 2019 um 10:05 Uhr von Spark Fountain

@DAK: Vielen Dank! Ich habe deinen Worklog auch gelesen und fand das damals echt spannend. Mein erster Implementierungsversuch hat übrigens genau wie deiner auf einen echten Parser verzichtet und versucht, nur Zeile für Zeile die Syntax anzupassen. War eine Katastrophe, vor allem bei anonymen lokalen Variablen und asynchronen Befehlen Wink

Donnerstag, 3. Januar 2019 um 17:54 Uhr von DAK

Klingt sehr cool!

Ich hab ja auch mal sowas Ähnliches probiert, da ging es darum BlitzBasic nach Java zu kompilieren. Ich wünsch dir mehr Erfolg als ich es gehabt habe! Mehr Ausdauer hast du wohl schon, und mehr technisches Verständnis, als ich damals gehabt habe, auch.


Kommentar schreiben

Titel:
Text: