Visual Brainf***

DocJunioR

Ich hab gerade mal so drüber nachgedacht, ob es nicht möglich wäre, ein visual brainf*** zu schreiben.
Okay, ist irgendwie krank, aber bestimmt ne Herausforderung. Man müsste das Ganze dann wahrscheinlich etwas ausbauen, so dass Verknüpfungen mit den GUI-Elementen und Variablen möglich sind.

Beispielsweise könnte das so laufen:
Die Ressourcedatei wird per klicknpaste zusammengebaut, der interpreter setzt das Formular zusammen.
Da jedes Ressourcenelement ja eine Nummer bekommt, kann man die doch gleich so einlesen, bzw. ausgeben:

...
   [>[>++++<-]<-].1000 // gib nach ressourcenelement 1000 aus
 ...
   ,2000  // lies Ressourcenelement 2000 ein

Dann brauchen wir noch variablen, auf denen wir arbeiten können. Hier können wir ja eigentlich auch gleich zu Anfang die Größe unseres Touringbandes definieren:

#defv MyVar (100)      // Die globale Variable MyVar hat 100 bytes

#defp main (256)       // Das Band der Main - Prozedur hat 256 Bytes
 ...
#endp

#defp Klick1001 (256)  equ 1001:WM_CLICK 
             // Das Band der Button_Klick - Prozedur hat 256 Bytes 
             // und wird mit Element 1001, Message WM_CLICK verknüpft
 >>>++<. 
 ***
 ***
#endp

...

Nun muss man nur noch Unterprozeduren ausführen können. Hierzu vielleicht der Unterstrich?

[>+++<-].Par1>.Par2_MyProc_<.2002

Die Kommunikation zwischen den Prozeduren läuft über Variablen. Ist nicht schön, aber es sollte reichen.

So, soviel dazu.
Ich werd' mich mal demnächst daran setzen. Wenn irgendwer Lust hat, mir zu helfen, oder sich selber mal probieren möchte, dann meldet euch mal - Ergebnisposings wären auch nicht schlecht..

cYa
DjR

Acid-Sky

wie willst du eine sprache mit 8 befehlen, die weder strukturierte noch objektorientierte - ja nicht mal funktionale - programmiertechnik unterstützt in das framework einbauen?

vor allem, da BF rein auf zeigern basiert, und nicht einmal die paar zeiger von C++ kannste bei managed apps verwenden...

die idee ist cool... aber ich denke nicht durchführbar...

DocJunioR

haste meinen Beitrag gelesen?
Dort sind schon alle Sachen geklärt.
Event-Handler, Prozeduren, Variablen, ..

Was noch fehlt kann man hinzusetzen.
Außerdem hat Brainfuck nichts mit Zeigern zu tun. Brainfuck ist nichts weiter, als eine Turingmaschine.
Ist auch nicht wirklich für den praktischen Einsatz gedacht, sondern als interessante Spielerei zwischendurch

cYa
DjR

Mr. N

Pervers. Einfach nur pervers. Interessanter wärs mit einer erweiterung für brainfuck, die code ignoriert, ihn in den Ram kopiert und dann einen pointer auf ihn an die aktuelle position stellt {bla}. Eine weitere Erweiterung (§) würde dann den Code an der aktuellen Stelle ausführen oder (falls ausführen unmöglich) nichts tun.
DANN wäre ein Visual Brainfuck halbwegs machbar.

Acid-Sky

jaja.. touringmaschine isses sicher... aber was macht die denn bitte im modernen rechner anderes als zeigerarithmetik...

alles was das teil macht is n pointer an ne speicherstelle zu setzen und dann fröhlich bits zur verschieben...

aber unabhängig davon: viel glück... wenn du es schaffst hast du meine bewunderung... allerdings glaub ich eher etwas von einem wahnsinnigen Informatiker auf deutschlands strassen zu lesen

DocJunioR

Wie gesagt. nur so'n Scherz zwischendurch. ICh werd auf keinen Fall jetzt verbissen daran rumschrauben - aber mal basteln kann net schaden...

cYa
DjR

Bashar

@Acid-sky: Man kann doch auch Array-Indizes verwenden, wozu Zeiger?

Walli

Ich find die Idee nicht so gut. Brainfuck ist halt ne leichte aber harte Sprache. Durch die Erweiterungen würdest du der Sprache ihren ganzen Charakter nehmen.

TriPhoenix

DocJunioR schrieb:

Ich hab gerade mal so drüber nachgedacht, ob es nicht möglich wäre, ein visual brainf*** zu schreiben.
Okay, ist irgendwie krank, aber bestimmt ne Herausforderung. Man müsste das Ganze dann wahrscheinlich etwas ausbauen, so dass Verknüpfungen mit den GUI-Elementen und Variablen möglich sind.

dann aber bitte im BF-Style ausbauen.

Beispielsweise könnte das so laufen:
Die Ressourcedatei wird per klicknpaste zusammengebaut, der interpreter setzt das Formular zusammen.
Da jedes Ressourcenelement ja eine Nummer bekommt, kann man die doch gleich so einlesen, bzw. ausgeben:
...
   [>[>++++<-]<-].1000 // gib nach ressourcenelement 1000 aus
 ...
   ,2000  // lies Ressourcenelement 2000 ein

Danns chon lieber sowas wie &, gibt nach Ressourcenelement a[n] aus, was in a[n+1] steht, wobei a der Speicher ist und n die aktuelle Bandposition. Andersrum z.B. %, liest ressourcenelement a[n] in a[n], sozusagen eine ersetzung. Die Synatx die du vorshclägst bricht mit der BF-Art, ein Zeichen ein Befehl.

Dann brauchen wir noch variablen, auf denen wir arbeiten können. Hier können wir ja eigentlich auch gleich zu Anfang die Größe unseres Touringbandes definieren:
#defv MyVar (100)      // Die globale Variable MyVar hat 100 bytes

#defp main (256)       // Das Band der Main - Prozedur hat 256 Bytes
 ...
#endp

#defp Klick1001 (256)  equ 1001:WM_CLICK 
             // Das Band der Button_Klick - Prozedur hat 256 Bytes 
             // und wird mit Element 1001, Message WM_CLICK verknüpft
 >>>++<. 
 ***
 ***
#endp

...

Nun muss man nur noch Unterprozeduren ausführen können. Hierzu vielleicht der Unterstrich?
[>+++<-].Par1>.Par2_MyProc_<.2002

Ebenso bricht das. Dann doch lieber einen Jump-Befehl einführen, dann kann man über makros sich problemlos Funktionen bauen.

Was ich halt am wichtigsten finde: erfinde nichts was mit 1-Zeichen-Befehlen bricht.

Walli

TriPhoenix schrieb:

Was ich halt am wichtigsten finde: erfinde nichts was mit 1-Zeichen-Befehlen bricht.

Jo, sonst wird der Interpreter nachher auch schwerer zu schreiben. BTW: Hab gestern aus purer Langeweile nen STL-basierenden BF-Interpreter geschrieben . Wie so ein Thread doch inspirieren kann .