Das deutsche Python-Forum

Da bei Python die Schlüsselwörter "class" oder "def" jeweils eine Definition einer Klasse bzw. Funktion (oder Methode) einleiten, würde ich auch für Variablen ein Schlüsselwort erwarten. Das macht den Parser wesentlich einfacher als zu erkennen, das etwas, das wie ein Ausdruck oder eine Zuweisung aussieht, stattdessen eine Variable definiert. Man kann hier ebenfalls "def" benutzen: Man könnte statt einem wenig sagenden "def" auch "var" und "fun" benutzen. Fände ich vielleicht sogar besser.

Um den Speichertyp zu definieren, würde ich folgendes machen: Also: Eine alternative wäre, die Speicherklasse explizit ähnlich wie eine Klasse zu definieren: Stefan

Die letzte Idee gefällt mir. Statt def würde ich aber var bzw const bevorzugen, da die Typen im Flash eigentlich Konstanten sind und damit man beim Lesen von Code zwischen Variablen und Funktionen unterscheiden kann.

Man könnte auch den Typ weglassen und einen Default Typ verwenden. Das muss der Programmierer aber beachten, da ich C ähnliche Typen benötige, also eine Unterscheidung zwischen char, int und long sowie signed und unsigned.

also var a = 0 wäre dann per Default ein unsigned Integer, var a = 1.0 wird zu float. Will man was anderes muss man es angeben.

Dann werde ich mich mal Schritt für Schritt mit dem Grammar befassen

burli hat geschrieben:Man könnte auch den Typ weglassen und einen Default Typ verwenden. Das muss der Programmierer aber beachten, da ich C ähnliche Typen benötige, also eine Unterscheidung zwischen char, int und long sowie signed und unsigned.

Dann verliert dein Python-Dialekt aber viel von seiner Unschuld. Warum brauchst du diese ganzen Typen? Um mit Betriebssystemfunktionen zu interagieren? Kannst du nicht (wie JavaScript es vormacht) mit einem Typ für Zahlen und einem für Zeichenketten auskommen und dann nur bei Aufrufen dieser Funktionen die beiden konvertieren?

Stefan

PS: Wäre nicht eigentlich Cython genau das, was du suchst?

@sma: Ich glaube, burlis primäres Ziel ist der Einsatz dieser Sprache zur Programmierung von Mikrocontrollern. cython lässt sich dafür nicht verwenden, ohne vorher die nötige CPython-Laufzeitumgebung auf den Controller zu portieren.

Mithin kann er wohl auch nicht auf verschiedene Zahlentypen verzichten, da diese gerade bei Mikrocontrollern wichtig sind. Eher weniger zur Interaktion mit Betriebssystemfunktionen, denn auf kleinen Mikrocontrollern gibt es das gar nicht. Dort ist direkte Interaktion mit der Hardware nötig, so dass Größe, Vorzeichen und allgemein Binärdarstellung eines Zahlentypen durchaus sehr wichtig sind.

burli möchte wohl eine ebenso primitive Sprache wie C, allerdings mit schönerer und ausdrucksstärkerer Syntax und ohne dessen semantische Tücken.

sma hat geschrieben:Dann verliert dein Python-Dialekt aber viel von seiner Unschuld. Warum brauchst du diese ganzen Typen? Um mit Betriebssystemfunktionen zu interagieren? Kannst du nicht (wie JavaScript es vormacht) mit einem Typ für Zahlen und einem für Zeichenketten auskommen und dann nur bei Aufrufen dieser Funktionen die beiden konvertieren?

Nein, die Zielplattform ist in den Ressourcen recht eingeschränkt (8 Bit Mikrocontroller). Ein 8 Bit Datentyp ist da zwingend nötig. Zum einen, weil die meisten Register 8 Bit groß sind und zum anderen, weil es Ressourcenverschwendung wäre, unnötige Operationen mit 16 oder gar 32 Bit auszuführen.

sma hat geschrieben:PS: Wäre nicht eigentlich Cython genau das, was du suchst?

Nein, wenn sich das überhaupt anpassen ließe hätte ich vermutlich die gleichen Probleme wie jetzt mit dem C Compiler. Da der GCC nicht für das Zielsystem entworfen wurde muss man ihm viele Dinge mühsam beibringen, mit allen daraus resultierenden Konsequenzen.

Ich möchte einfach eine Sprache, die selbst schon auf die Zielplattform angepasst ist. Eine vorhandene Sprache samt Compiler, die beide nicht dafür gedacht sind, daran anpassen führt in meinen Augen zu Murks.

burli möchte wohl eine ebenso primitive Sprache wie C, allerdings mit schönerer und ausdrucksstärkerer Syntax und ohne dessen semantische Tücken.

Das trifft den Nagel auf den Kopf

Ich habe mal ein paar Gedanken zusammengefasst.

http://ubuntuone.com/p/1Efz/

Die Datei wird immer wieder mal aktualisiert. Vorschläge sind willkommen.

Schreib den Typnamen doch besser vor die Variable. Dieses `as` ist IMHO unnötig "noisy".

snafu hat geschrieben:Schreib den Typnamen doch besser vor die Variable. Dieses `as` ist IMHO unnötig "noisy".

Ich denke, es ist Geschmackssache. Ich finde eine etwas ausführlichere Syntax eigentlich schöner. Sei lieber froh, dass ich nicht noch ein "Dim" davor schreibe

Nutze vielleicht auch besser aussagekräftige Typnamen, aus denen die Größe des Typen hervorgeht (z.B. "uint8", "uint32", usw.). Du willst ja gerade kein C, also sollten Deine Typen auch kein C-Wissen voraussetzen

+1 für lunar's Vorschlag. Ich verwende bei C die Typdefinitionen aus ``inttypes.h`` wo es Sinn macht. Insbesondere bei sehr eingeschränkten Zielsystemen ist es schön mehr Kontrolle über die Grössen zu haben, den Code zu Testzwecken aber trotzdem zumindest teilweise auf dem PC zu kompilieren und dabei nicht in die Falle zu laufen, dass die „traditionellen” Typen dort sonst einen anderen Wertebereich haben. Mittels ``inttypes.h`` lassen sich solche Typen aus Deiner Sprache ja auch ziemlich einfach, portabel auf C-Typen abbilden.

lunar hat geschrieben:Nutze vielleicht auch besser aussagekräftige Typnamen, aus denen die Größe des Typen hervorgeht (z.B. "uint8", "uint32", usw.). Du willst ja gerade kein C, also sollten Deine Typen auch kein C-Wissen voraussetzen

Ich mag eigentlich die Typenbezeichnungen von Pascal oder Basic. Man könnte auch Byte, Word und Long verwenden und für unsigned das ganze noch mit einem vorgestellten U

int8/16/32 bzw uint8/16/32 sind zugegeben eindeutiger, bedeuten aber das selbe. Jede Sprache definiert es anders. Aber da lasse ich mit mir reden.

burli hat geschrieben:int8/16/32 bzw uint8/16/32 sind zugegeben eindeutiger, bedeuten aber das selbe.

@burli: Sie bedeuten eben nicht dasselbe. Byte, Word und Long sind architekturabhängige Größen, int8, int16 und int32 dagegen nicht. Wie Du sagst, jede Sprache definiert es eben anderes ... insofern während portable gerade bei Mikrocontrollern wünschenswert.

burli hat geschrieben:Nein, die Zielplattform ist in den Ressourcen recht eingeschränkt (8 Bit Mikrocontroller). Ein 8 Bit Datentyp ist da zwingend nötig. Zum einen, weil die meisten Register 8 Bit groß sind und zum anderen, weil es Ressourcenverschwendung wäre, unnötige Operationen mit 16 oder gar 32 Bit auszuführen.

8 Bit? So etwas gibt es noch? Ich hätte gedacht, das heutzutage die 32-bit und hunderte von MB RAM auch bei Mikrocontrollern bereits üblich sind. Haben nicht selbst schon die Telefon-USIMs 32-Bit-Prozessoren? Na jedenfalls kann man sie in Java mit den ganz normalen Datentypen programmieren.

Bei 8-Bit (und wahrscheinlich maximal 64KB RAM) ist man aber IMHO moralisch quasi verpflichtet, Forth (oder eine moderne Variante wie Factor) zu benutzen. Forth vereint wie keine andere Sprache maschinennahe und sehr abstrakte Programmierung, hat dabei auch meist noch eine REPL und kann relativ leicht in C (oder gar Maschinensprache) entwickelt werden. Das ursprüngliche Forth passte in 4 KB, inklusive "IDE" bestehend aus Editor, Compiler und Disk-Operationsystem.

Schreiben tue ich das natürlich nur, um auf mein Factor-in-Python-Tutorial hinzuweisen: https://gist.github.com/1097091

Stefan

Es gibt Forth zum Beispiel für AVR. Die Sprache gefällt mir aber nicht. Einzig UPN für Formeln wäre einfacher zu parsen als verschachtelte Klammern

lunar hat geschrieben:@burli: Sie bedeuten eben nicht dasselbe. Byte, Word und Long sind architekturabhängige Größen, int8, int16 und int32 dagegen nicht. Wie Du sagst, jede Sprache definiert es eben anderes ... insofern während portable gerade bei Mikrocontrollern wünschenswert.

Ok, bis auf Byte ist wirklich nichts festgelegt. Ich werde mal darüber nachdenken. Bin ja nicht festgelegt

Den Scanner werde ich jetzt selbst schreiben. Pyparsing scheint zwar mächtig zu sein, aber die Dokumentation ist bescheiden und einige Funktionen scheinen buggy zu sein. Bis ich da durchgestiegen bin hab ich den Scanner schon fertig.

@burli

Mit Verlaub, aber pyparsing ist eine stabile Bibliothek, die von Paul McQuire sowohl gepflegt als auch via Mailingliste supported wird. Und darum wuerde ich deine Probleme mal eher auf ISO-Layer-8 schieben. Es ist dir ja unbenommen, dich da nicht weiter mit beschaeftigen zu wollen (not invented here syndrome ist ja sicher schonmal bei dir diagnostiziert worden... ), aber einfach zu behaupten es waere buggy - da waere dann schon ein Beleg noetig.

Ich bin noch gar nicht so weit vorgedrungen, um selbst auf Bugs zu stoßen. Meine Vermutung beruht darauf, dass ich im Forum vermehrt auf immer wiederkehrende Probleme gestoßen bin, die nicht gelöst wurden.

Und wie gesagt, die Dokumentation ist (für mich) unzureichend. Es gibt zwar viele Beispiele die etwas zeigen, aber zu wenig erklären.

Außerdem ist es ja nicht verkehrt, selbst eine Lösung zu finden.

@burli: Bei allem Respekt, einer Bibliothek nur anhand einer Forendiskussionen Bugs zu unterstellen, ohne sich überhaupt näher mit dieser Bibliothek befasst zu haben, ist unverfroren.

Die Beispiele und die Dokumentation von PyParsing setzen nun mal ein gewissen Grundwissen über Grammatiken und Parser voraus. In Ermangelung dieses Grundwissen ist die Implementierung eines Scanners nicht einfach. Bei sma sieht das nur deswegen so aus, weil er die theoretischen Grundlagen dessen mal gelernt hat.

Wenn Du die lexikalische Analyse selbst implementieren möchtest, dann beginne erst einmal mit der Lektüre eines Buchs über Compilerbau.

Ich erwarte von einer Dokumentation nicht, dass sie mir die Grundlagen des jeweiligen Themas beibringt. Aber die einzelnen Funktionen sollten schon wenigstens halbwegs beschrieben werden, was die Funktion macht

Wie auch immer, ich werde auch so einen Weg finden.

So, der Scanner funktioniert schonmal nicht schlecht, auch wenn er noch nicht alles kann wie zum Beispiel Tripple Quotes, Multi Lines oder Escape Sequenzen in Strings.

http://pastebin.com/StZWMbU9

In der ersten Zeile steht jeweils der Original Code, in der zweiten die zerlegten Teile als Liste

Ich weiß, dass war der leichte Teil. Ich mache hier noch keinerlei Test sondern reines Zerlegen von Strings nach einfachen Regeln. In den Scanner werde ich nur einfache Syntax Checks machen wie fehlende Klammern oder ein Fehler beim Einrücken. Die erste Zahl in der Liste gibt die Einrücktiefe an

PS: eventuell könnte man den Thread mal in das "Ideen" Forum verschieben?