FORTH Beispiel

Nein, aber Einlauftemperatur(Kessel(3)) ginge, wenn z.B. Kessel(3) eine entsprechende Struktur zurückgibt, für die dann "Einlauftemperatur" eine Accessor-Funktion ist. Natürlich nicht interaktiv, aber zum Verstehen beim Lesen sollte es reichen.

Sieht schon merkwürdig aus. Wenn ich das richtig verstehe, wird 0 zu einem Funktionspointer ohne Übergabeparameter und mit void als Rückgabetyp gecastet, der dann aufgerufen wird, also ein "goto 0".

Wolfgang Allinger schrieb: ...

...

Ich darf noch mal aus dem OP zitieren:

------------------ : abfragen ( a -- uMASKE uDATA )

@ 1- bits/Meldung /MOD ( -- rem qot ) Melder0 + Melder@ ( -- rem uDATA ) 1 ROT ( -- uDATA 1 rem )

------------------

Glaub's mir oder laß es: Ich verstehe gerade mal "1 ROT", falls ROT für "Rotieren" steht. Und das auch nur, weil ich programmiere.

"if (a>b) printf ("Größer\n"); else printf ("Kleiner\n");" versteht jeder, der "if" "else" und "print" kennt.

Falk

Wolfgang meinte auch den unteren Teil des Postings. Forth-Programme sind immer sehr fein strukturiert und teilweise in (gedanklichen) Schichten aufgebaut. Was du da zitiert hast, ist die unterste Systemschicht, die der typische Anwender nicht unbedingt sehen muß. Aber der Vollständigkeit hier die Erklärung der Wörter:

@: holt den letzten Wert vom Stack (TOS) und liest den Wert an der Adresse, die dieser Wert bezeichnet

/MOD: letzten beiden Werte vom Stack holen, teilen, push Rest und Quotient

rot: trickreicher Befehl, aber manchmal sinnvoll: rotiere die Position der drei letzten Werte auf dem Stack (also aus "rem uDATA 1" wird "uDATA 1 rem").

Die Stackkommentare in Klammern, was vom Forth-Interpreter ignoriert wird, helfen dann den Ablauf leichter zu verfolgen: Nach dem "--" steht, was am Ende der Zeile auf dem Stack liegt (relativ zum Anfang), bei der Wortdefinition vor dem "--", was als Eingangswerte auf dem Stack erwartet wird.

bits/Meldung ist ein Wort, da es keine besonderen Einschränkungen bezüglich Sonderzeichen bei Wörtern gibt.

Naja, Holländer können auch deutsch lesen, umgekehrt isset was schwerer :-p

Bingo, war der Sprung an die Adresse 0, um die Reset Funktion auszuführen.

Wo und wie das genau war (ob für einen Z80 Emulator oder sowas) hab ich vergessen, aber das Trumm wegen der Übersichtlichkeit und Klarheit gut gespeichert :-)

Saludos Wolfgang

snipped-for-privacy@spambog.com (Wolfgang Allinger) schrieb:

Sowas würde nur ein Schwachkopf schreiben. Aber wenn man statt des Nullpointers eine vernünftige Adresse reinschreibt machts schon Sinn. Damit kann man eine Sprungtabelle implementieren. Mal ein Windows Beispiel:

void Dummy_1() { AfxMessageBox(_T("Dummy 1 aufgerufen")); } void Dummy_2() { AfxMessageBox(_T("Dummy 2 aufgerufen")); }

void *pDummy[2] = { Dummy_1, Dummy_2 };

void Test(int i) { (*(void(*)()) pDummy[i])(); }

Test(0) => "Dummy 1 aufgerufen" Test(1) => "Dummy 2 aufgerufen"

Ja, ROT macht ein ROTate auf dem Stack.

Aber wie gesagt, es ging nicht darum dass jeder versteht, wie ich an das eigentliche Programm der Application komme, sondern das man sieht, das man das eigentliche Anwendungs Wort Feuerlarm... leicht lesen und verstehen kann.

Das geht in Forth noch einfacher und klarer

optional noch ein CR dahinter, wenn Du eine neue Zeile brauchts. Das würde in einem 16bit Forth zu 23 byte an Programmcode führen, und je nachdem, wie Du das benutzen willst noch zu etwas overhead. Also im compilierten headerless Target für einen uC kämen noch 4 byte overhead dazu. Auf einem PC mit Header wohl geschätzt 20 byte.

obiges falls a und b auf dem Stack stehen (typisch bei Forth), sonst musst Du, wenn es variablen sind, noch

a @ b @ > IF ... schreiben,

Variablen hinterlassen ihre adresse auf dem Stack, drum das Laden des Inhaltes mit @

falls a und b als values deklariert sind, musst Du das Laden ('@') weglassen, genauso wenna und b andere Worte (Funktionen) sind...

also

a b > IF ...

Wobei man in Forth IF ELSE THEN besser im Kontext als FALLS ANDERNFALLS DANN (im Sinne danach) ansehen muss. ELSE kann man weglassen, wenn man es nicht braucht.

Ganz früher gabs statt THEN ein END-IF, fand ich persönlich besser, aber war den Forth Gurus wohl zu lang und umständlich und passte nicht in deren Kontext... Ich schätze, dass die überwiegende Anzahl aller Forth Systeme END-IF mit THEN gleichsetzt.

Man gewöhnt sich am allem, auch am Dativ!

Saludos Wolfgang

Test(2) => führt dazu, daß kleine Dämonen deiner Nase entfleuchen :-)

Frank Buss schrieb:

Parameterprüfung ist Luxus. Nicht jeder kann sich den leisten :-)

Hajü

Den da, nehme ich an:

-------------------------- : Feueralarm_bearbeiten 1. Rauchmelder anwählen, beginne Rauchmelder abfragen. Rauch entdeckt? Falls ja, Feueralarm melden. Den nächsten Rauchmelder anwählen, alle Rauchmelder abgefragt? dann aufhören ;

--------------------------

Ja, sieht leicht verständlich aus. Mit den Tricks in

-------------------------- : abfragen. abfragen ; : anwählen, anwählen ; : Falls ; : melden. melden ; : dann ja = ; : beginne [COMPILE] BEGIN ; IMMEDIATE : aufhören [COMPILE] UNTIL ; IMMEDIATE : ja, [COMPILE] IF ; IMMEDIATE : Den [COMPILE] THEN ; IMMEDIATE

--------------------------

Kann ich das auch in C realisieren:

-------------------------- hauptprogramm() START GANZZAHL a,b; Ausgabe("Feueralarm"); STOP

--------------------------

Kompiliert und läuft. Die #defines kannst Du leicht raten. Den Teil mit #define naechster_feuermelder a++ #define wenn if usw. habe ich mir geschenkt.

Das sollten C-Programme auch sein.

Also ein UPN-Assembler ;-)

Ich kann mir vorstellen, daß Forth seine Existenzberechtigung hat. Aus den Beispielen kann ich aber keinen Vorteil zu C sehen. Und wenn man davon ausgeht, daß jeder glaubt, C zu können, ist die Chance auf Idioten zu treffen natürlich größer als bei einem Exoten.

Falk

Frank Buss schrieb:

Weil in C keine Möglichkeit besteht, beliebige Definitionen und Funktionen eines kompilierten Programmes ohne Neuübersetzung aufzurufen.

Damit fällt C++ schonmal komplett raus. Und auch einige C-Standardfunktionen gehen nicht mehr: signal() bleibt tabu, qsort() auch.

Bernd

Ach $deity, die Klammern bringen dich ja nun wirklich nicht um. Die überliest man halt beim laut-vorlesen. Dein "beginne ... dann aufhören" ist da kein bisschen umgangssprachlicher, nur wortreicher.

Und ehrlich gesagt fehlt mir die Möglichkeit zur Klammerung in der normalen Sprache durchaus gelegentlich. Schon mal einen Satz mit "a and (b or c)" versucht, eindeutig zu formulieren?

Du müsstest aber für jeden eingefügten natürlichsprachlichen Halbsatz einen Schwung unverständlicher Wortdefinitionen : dann ja = ; : beginne [COMPILE] BEGIN ; IMMEDIATE einfügen.

Und vor allem: jemand, der programmieren kann (dich ein halbes Jahr später eingeschlossen) kann das Ding überhaupt nicht mehr lesen. Man nehme zum Beispiel einfach mal einen off-by-one-Fehler. Passiert bei natürlichsprachlicher Ausdrucksweise gerne, wer verwendet schon "gleich" und "größer-gleich" auch in der Umgangssprache immer korrekt. Wie findet man den, wenn das Programm aus 500 Wortdefinitionen besteht, mit denen dann zufällig am Ende das natürlichsprachliche Programm compiliert?

Natürlich geht auch in C: #define beginne while(running) #define Rauchmelder /* Füllwort */ #define abfragen Rauch = abfragen(), #define entdeckt == true #define Falls /* Füllwort */ #define ja /* Füllwort */ #define Feueralarm /* Füllwort */ #define melden melden() : 0, #define Den /* Füllwort */ #define naechsten next(), #define anwaehlen /* Füllwort */ #define abgefragt == true #define dann /* Füllwort */ #define aufhoeren running = false : 0

bool running = true; /* Steuervariable */ bool Rauch; /* temporäre Variable */ bool alle; /* Rückgabewert von 'next', ob alles abgefragt wurde */

beginne Rauchmelder abfragen Rauch entdeckt? Falls ja Feueralarm melden Den naechsten Rauchmelder anwaehlen alle Rauchmelder abgefragt? dann aufhoeren ;

Im IOCCC könntest du damit vielleicht noch einen Trostpreis gewinnen...

Natürlich mag es nun toll klingen, dass man in FORTH dann eben Rauchmelder abfragen Rauchmelder rücksetzen Rauchmelder abschalten Rauchmelder abgefragt? schreiben kann, aber letztlich kann ich das z.B. in jeder objektorientierten Sprache auch: Rauchmelder.abfragen(); Rauchmelder.rücksetzen(); Rauchmelder.abschalten(); if (Rauchmelder.abgefragt()) { ... }

Stefan

Ein wenig mehr ist es schon :-) Ich bin zwar nicht der absolute Verfechter von Forth wie Wolfgang, aber ist schon eine faszinierende Sprache. Ist aber wie auch bei vielen anderen Dingen im Leben: Man kann viel andere darüber reden hören, glaubt aber nicht so recht, daß es was besonderes ist (Enfield fahren, Kunstmalerei usw.), bis man es selbst erlebt hat. Forth mal auszuprobieren hat sich für mich gelohnt und ich kann mir gut vorstellen, es wieder einzusetzen.

Moin!

Ist das ein Forth-Programm? :-)

Nun ja, ein paar Oder-Gatter (für Jörg: Dioden) hätten die Zweck vermutlich auch erfüllt.

Gruß, Michael.

Wenn mal jemand auf die Idee kommt, mich (gegen Honorar) eine interessante Aufgabe lösen zu lassen und Forth fordert, werde ich bestimmt nicht Nein sagen.

Bis dahin "bleibe ich bei meinem Leisten", php, perl, C und, gegen Schmerzensgeld, Assembler.

Falk

Was muß der Anwender überhaupt sehen? Im Grunde reicht die Rechnung auf der steht "Systementwicklung Feuermelder auf 8051System incl. Source, Dokumentation und Bedienungsanleitung. 1Tag Arbeit und 24/7 Support für

Ob das Dingen funktioniert erfährt er von der Feuerwache nachdem er 1 Zigartette angezündet hat.

IGITT!

Am Anfang war der Stack und der Stack war am Anfang. Dann wurden Sprachen erfunden, die das Gefrickel seiner Verwaltung übernehmen...

Nö, Du hast völlig daneben getippt! 0 ist eine richtige Addresse, die bitter benötigt wird. s.u. Die Routine war nötig in einem Emulator/Simulator Weis nicht mehr genau, nur die Routine hab ich gebunkert. Sie wurde sicher nicht von Schwachköppen geschrieben.

Wie Du gerade unfreiwillig bewiesen hast, ist C wohl eine write only language :-)

Mach Dir nichts draus, ich gebe ja zu, dass es ein schlimmes Ding ist. Und ich hab auch erst eine Erklärung für das Gewürge mit den Klammern gebraucht :-P

Dirk hat es richtig erkannt, ist die Simulation eines Reset, In Assembler könnte man einfach schreiben JMP 0. IIRC war das für einen Z80.

In Forth könnte man

0 EXECUTE sollte auch gehen, das wäre vermutlich die sauberste Lösung, die dann auch jeder(?) ohne Kommentar versteht.

Gibt sicher noch viele andere Möglichkeiten.

Saludos Wolfgang

Und ihn vor allem, wann immer möglich, ganz in Ruhe lassen. Wozu gibt's schließlich Register?

Falk Willberg : [hat von W.A. übernommen:]

Aber in dem Zusammenhang so nur wenn der Compiler vorher in den Kopf hineinkompilieren durfte. Nach Sprachlogik, alleine, ist das letztere Unsinn. Das ist hier der Unterschied. Der Rauchmelder weiter oben ist zwar überspitzt, trifft aber den Kern der Darstellungsweise.

Forth ist viel eher mit elementarer Logik verknüpft und erledigt Mathematisches dann nebenbei. Damit weicht die Herangehensweise fundamental von dem ab, wie sie mit der algebraischen Notation gepflegt wird. Die gibt vom kategorialen Ansatz etwas vor, was man garnicht streng nachprüfen darf, als da man sich hernach auf ontologischem Glatteis wiederfindet, mit einer schrägen Überziehung von Allegorien in Permanenz. Im Gegensatz hierzu muss man mit Forth als Werkzeug keinesfalls ständig irgendwie so tun, als ob - man greift einfach an, und gut ist.

Bei soviel Einfachheit des Werkzeugs ist in der Folge die Produktivität stattdessen freigesetzt, die abstrakten Schichten so einzupflanzen, wie es für eine Problemstellung erforderlich ist.

Natürlich darf man zwischendurch algebraisch notieren, warum nicht. Eine Compiler-Erweiterung ist nicht die Welt, zu einem kleinen Sonderstatus, der dann wieder verlassen werden kann.

Die wichtige Beobachtung an diesem Punkt ist jedenfalls, dass man nicht gegen so manche hartkodierte Windmühlen kämpfen muss.

Ich finde immer noch diese Charakterisierung treffend: Mit Forth kompiliert man nicht direkt, sondern man besorgt eine angemessene Kunstsprache für ein Problem, mit deren Anwendung sich dann das Problem leicht angehen lässt. Irgendwo muss noch ein in Forth geschriebener Basic-Interpreter herumliegen, als Compilererweiterung, um hernach in Basic weiterzuschreiben - das verdeutlicht die Charakterisierung. Sicherlich häufig in Verwendung war immer wieder der angeführte Interpreter für vorübergehende algebraische Notation.

Das eröffnet ganz andere Dimensionen des gedanklichen Zugriffs, als wenn die Gedanken immer nur um "der Compiler!" kreisen. Der Compiler ist in diesem Fall überraschenderweise höchst trivial! Im Gegenzug aber ist das, was man dann daraus machen kann ein ganzer Abgrund von Möglichkeiten, wo man erstmal ins Reine kommen muss, wie man das am besten nutzen soll.

Die Frage "wie muss ich notieren, dass es kompiliert wird" ist viel nebensächlicher, von Grund auf, beim alltäglichen Gebrauch. So eine Zwangsjacke eines gekünstelten Rituals, dass algorithmische Gedankengänge in erster Linie als Folgen von Zuweisungen notiert werden, kann einem unmittelbarer als Absurdität einleuchten, wenn man davon mal eine Zeitlang befreit war.

Zur Realisierung sei noch das Detail angefügt, dass Forth definitiv eine Maschine mit zwei Stacks ist (es dürfen fallweise auch mehr sein). Das macht dann eine Hürde aus, wenn mit dem Mainstream direkt interagiert wird. Diese Hürde wird immer wieder auch übersprungen! C-Code (als "Mitte des Mainstreams") wird auf eine Maschine mit einem Stack abgebildet - es reicht also, dass die Forth-Maschine ein massives Inventar zur Bändigung des Returnstacks hat (dort sollte der Dataflow vom Mainstream landen).

Dass also "Libraries nicht einzubinden" seien, kann man so einfach nicht sagen.

Anekdotisch lässt sich auch noch erweitern, dass Java zwar in unmittelbarer Nachbarschaft der nachmaligen Open-Boot-Umgebung entstand (das ausdrücklich ein Forth ist), bei Sun, kurz nacheinanader, leider aber hat man das Konzept einer Maschine mit grundlegend zwei Stacks nicht übernommen.

Man sollte vielleicht dem Gedanken Raum gönnen, dass der Umgang mit solcher Programmierumgebung, die eine angemessene Freiheit der Formulierung fördert, gewiss nicht der erste Fall dafür wäre, einen anspruchsvollen Arbeitsstil angemessen zu koordinieren. Darauf wird meistens vergessen, fürchte ich.

Der Knackpunkt liegt vielleicht in dem unsinnigen, zugleich leider aber naheliegenden Vorurteil, wie es sich aus alltäglicher Arbeit mit der algebraischen Notation übersetzt, wonach sich ein Programmieren in der Ausführung prinzipiell in recht engen Denkschablonen abzuspielen habe.

Stefan Reuther :

Normalsprachlich kann so eine Unschärfe leicht mit der passenden Redundanz erschlagen werden. Die Ungewissheit ist keine sprachliche sondern eine zwischenmenschliche, wenn man bei Weglassungen nicht sagen kann, ob gerade ein Schlitzohr für seine Zwecke besonders passend jongliert.

ich habe a, und ich habe b oder auch c. ich habe a und dazu b, oder ich habe c, oder auch alle drei.

Die Überlogiker, die so billig auf der Sprache herumdreschen, sollten sich besser in der Linguistik umschauen.

Und dann waren da noch die putzigen UND/ODER-Kandidaten! (Wie wäre es mit ... und auch, ... oder auch?) Und dann noch die IF-AND-ONLY-IF-is-IFF-Soldaten.

Vielleicht hülfe es, die Ohren durchzuputzen und den Leuten einmal zuzuhören, bevor man sich selbst auf den Sockel stellt.

Aber irgendwie hat sich das wieder gelegt. Das war eine eigenartige Zuspitzung, die mir ziemlich auf die Nerven ging. Vielleicht lässt sich an der zeitweiligen Marotte ablesen, dass irgendetwas umgeschlagen ist, zu der Zeit, als das so massiv unter die Leute gebracht wurde - zumindest war es wohl der Übergang von irren Projektionen auf die mögliche Zukunft von Rechenknechten (da in der Ecke ist wohl auch die unbedingte Fixierung auf eine algebraische Notierung von Quelltexten zuhause) und hernach das allmähliche tatsächliche Einsickern der Rechnerei in alltägliche Gewohnheiten.