BlitzBasicScript

Gehe zu Seite 1, 2  Weiter

Worklogs BlitzBasicScript Kommentare

Montag, 3. Februar 2020 um 09:00 Uhr von Spark Fountain

@Jan_: Stimmt, der Code auf der Startseite ist auch mehr als Platzhalter gedacht, damit man ein typisches Game-Code-Beispiel sieht, das natürlich später auch mal funktionieren soll.

Momentan ist der Parser jedoch noch sehr eingeschränkt und kann (im Moment) noch nicht mal globale Variablen anlegen und beschreiben / auslesen. Gerade bin ich dabei, dem Parser beizubringen wie man Ausdrücke ("mathematische Terme") analysiert. Das ist für mich gerade eine ganz ordentliche Nuss, weshalb ich auch Codebeispiele aus dem Netz zu Rate ziehe.

Getestet

Sonntag, 2. Februar 2020 um 08:25 Uhr von Jan_

Hallo, dein hier geposteter Code funktioniert, das Beispiel voin der Startpage leider nicht :-/
Sieht aber viel versprechend aus!

Sonntag, 4. August 2019 um 11:23 Uhr von Fobsi

cooles projekt

Webassembly

Samstag, 11. Mai 2019 um 09:00 Uhr von DivineDominion

RE: MainLoop, kannst du nicht auch einfach einen "Callback" voraussetzen? Also statt es zu einem Keyword zu deklarieren, muss man in BBScript eine Hauptfunktion implementieren.

Code: [AUSKLAPPEN]


Function MainLoop(delta#)
    ...
End Function


Dann kann man in BB, sofern kompatibel, eine eigene main.bb schreiben, die die Schleife ausführt und die Funktion selber aufruft, während du diesen main-loop-wrapper halt als Teil vom Framework lieferst.

Super.

Donnerstag, 9. Mai 2019 um 16:57 Uhr von Matthias

Ich finde dein Projeckt echt Super.

Und ich hoffe du bleibst dran. Auch wenn es mal schwierig wird.

Als Tipp.
Kaum jemand will seine alten BlitzBasic Programme 1:1 konvertieren.
Deshalb mach es so wie es für dich am besten zu programmieren ist.

Ich bin gespannt wie du Types und Listen umsetzt.
Ich bleibe auch dran. Jedenfalls beim lesen. Smile

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.

Gehe zu Seite 1, 2  Weiter


Kommentar schreiben

Titel:
Text: