DGL
https://delphigl.com/forum/

@BTCC | ehemals: Spass mit F#
https://delphigl.com/forum/viewtopic.php?f=14&t=11383		 Seite 1 von 2
Autor:  yunharla [ Do Jun 04, 2015 09:46 ]
Betreff des Beitrags:  @BTCC | ehemals: Spass mit F#
Hi Leute,

Ich wollte euch mal nach euren Wuenschen bzw. Vorstellungen fuer eine moderne
Programmiersprache bitten:

Ich hatte es ja schon an anderer Stelle erwaehnt das ich zur Zeit gerade an einen kleinen
“Compiler” in F# bastel. Das Ganze soll meinen Code nehmen und diesen dann nach C
umwandeln und durch den richtigen Compiler schicken. Also im Prinzip genau das gleiche
wie die alten C++ Compiler.

Ich will damit eine Semi-Funktionale Sprache entwickeln die sich starker am C-Syntax
orientiert. Hintergrund ist naemlich das mir OCaml, Scala und co viel zu kompliziert
sind :-)

Zur Zeit gibt es schon richtig komplexe Expressions mit denen man schon fast
vollstaendige Programme schreiben kann. Natuerlich mit Fehlermeldungen und allen
drum und dran. Jetzt fehlt also noch ein Weg fuer Deklarationen und Compound-Geschichte.
Und genau da liegt der Knackpunkt. Denn ich finde die meisten Funktionalen Sprachen machen
genau das Falsch.

Hier einmal ein kurzes Beispiel fuer eine Expression:

Code:
  1.  
  2.         switch (union {
  3.                 struct {
  4.                     (a->b->c->d)[1024 * 512 + -(-445)],
  5.                     ((a->b->c->d)[1024 * 512 + -(-445)])()
  6.                 },
  7.                 false //false
  8.             }) {
  9.             case void:
  10.                 printf("" void was returned "")
  11.             default:
  12.                 printf("" struct is not null "")
  13.         }
  14.  


Und hier der AST (Abstract Syntax Tree) fuer die Expressions:
Code:
  1.  
  2. type Identifier = string //names
  3. type Constant = string //numbers
  4. type StringLiteral = string //"string"
  5. //almost normal C-Style Expressions, except for some
  6. //additional braces during postfix and unary expressions
  7. type PrimaryExpression =
  8.     | Constant          of Constant
  9.     | StringLiteral     of StringLiteral
  10.     | Identifier        of Identifier
  11.     | Expression        of Expression
  12. and PostfixExpression =
  13.     | None
  14.     | ArrayExpression   of PrimaryExpression * Expression list
  15.     | CallExpression    of PrimaryExpression * Expression list
  16.     | MemberExpression  of PrimaryExpression * Identifier list //we dont want braces when chaining member expressions
  17.     | PostIncrement     of PrimaryExpression
  18.     | PostDecrement     of PrimaryExpression
  19. and UnaryExpression =
  20.     | None
  21.     | Increment         of PrimaryExpression
  22.     | Decrement         of PrimaryExpression
  23.     | SizeOf            of PrimaryExpression
  24.     | TypeOf            of PrimaryExpression
  25.     | Minus             of PrimaryExpression
  26.     | Not               of PrimaryExpression
  27.     | Invert            of PrimaryExpression
  28. and BinaryExpression =
  29.     | None
  30.     | Multiply          of Expression * Expression
  31.     | Divide            of Expression * Expression
  32.     | Modulo            of Expression * Expression
  33.     | Add               of Expression * Expression
  34.     | Sub               of Expression * Expression
  35.     | Left              of Expression * Expression
  36.     | Right             of Expression * Expression
  37.     | Less              of Expression * Expression
  38.     | Greater           of Expression * Expression
  39.     | LEqual            of Expression * Expression
  40.     | GEqual            of Expression * Expression
  41.     | Equal             of Expression * Expression
  42.     | NEqual            of Expression * Expression
  43.     | And               of Expression * Expression
  44.     | Xor               of Expression * Expression
  45.     | Or                of Expression * Expression
  46.     | LogicalAnd        of Expression * Expression
  47.     | LogicalOr         of Expression * Expression
  48. and Expression =
  49.     | PrimaryExpression of PrimaryExpression
  50.     | UnaryExpression   of UnaryExpression
  51.     | PostfixExpression of PostfixExpression
  52.     | BinaryExpression  of BinaryExpression
  53.     | TupleExpression   of TupleSpecifier * Expression list //constructs anonymous union or struct
  54.     | StatementExpression of Statement
  55. and TupleSpecifier =
  56.     | Struct //when struct everything works as expected
  57.     | Union //when union the first valid expression is used (similar to try catch)
  58. and Statement =
  59.     | If                of PrimaryExpression * Expression //if ( [Expression] ) [Expression], please note that braces are forced on complex stuff
  60.     | IfElse            of PrimaryExpression * Expression * Expression //same as if but also wraps the else path
  61.     | While             of PrimaryExpression * Expression   //while ( [Expression] ) [Expression]
  62.     | Switch            of PrimaryExpression * SwitchExpression list //Switch (Expression) { Cases }
  63.     | Expression        of Expression   //used when doing declarations
  64. and SwitchExpression =
  65.     | Case              of PrimaryExpression * Expression //case [Expression] : [Expression]
  66.     | Default           of Expression //default : [Expression]
  67.  
Autor:  sharkman [ Do Jun 04, 2015 19:17 ]
Betreff des Beitrags:  Re: Spass mit F#
Zitat:
Ich will damit eine Semi-Funktionale Sprache entwickeln die sich starker am C-Syntax
orientiert. Hintergrund ist naemlich das mir OCaml, Scala und co viel zu kompliziert
sind
Ich kenne OCaml nicht und scala nicht besonders gut, aber c-syntax als vereinfachung?

Wenn du vereinfachen willst, würde ich persönlich zuerst damit anfangen, die Regeln für infix-operatoren zu vereinfachen: weg mit punkt-vor-strich, und-vor-oder etc, und einfach entweder von links nach rechts oder von rechts nach links lesen. Ich persönlich habe mir sowieso noch bei keiner Sprache gemerkt, welcher Operator wann kommt, und je mehr operatoren, desto mehr geht es auf die Nerven, unmengen möglicherweise überflüssige Klammern zu schreiben, die dann beim Lesen stören.

eventuell wäre als Ersatz geeignet, dass whitespace von Bedeutung ist, etwa so
Code:
  1. a+b / c-d
  2. //parses (a+b)/(c-d)
  3.  
  4. a + b/c - d
  5. //parses a+(b/c)-d
  6.  
  7. a+(b / c)-d
  8. parses a+(b/c)-d of course
  9.  
  10. a+b/c-d
  11. //parses either (((a+b)/c)-d) or (a+(b/(c-d)))
andererseits geht das natürlich schlecht mit c-syntax, da die Erwartung ist, dass c whitespace ignoriert.
Autor:  yunharla [ Do Jun 04, 2015 20:15 ]
Betreff des Beitrags:  Re: Spass mit F#
Hey, keine Sorge ich meinte mit C-ähnlich so viel wie geschweifte Klammern und co. :)

Und zum Thema Operatoren habe ich nur bei den Prefix und Postfix Operatoren etwas getan. Dort muss man wirklich Klammern setzen:
Code:
  1.  
  2. ++a->b //falsch
  3. (++a)->b // korrekt
  4. ++(a->b) // richtig
  5. a++ < b //falsch
  6. (a++) < b //richtig
  7.  

Bei solchen Sachen wie Vergleich, Shift, Logik und Bit Operatoren, denke ich man könnte da durchaus
von Links nach Recht evaluieren oder so. Man sollte halt bloß die Mathematischen Sachen davon dann trennen.
Punkt-vor-Strich erwartet wohl jeder das so etwas klapp :)

Solche Sachen wie Whitespace oder Komma als Operatoren ist übrigens eine der Sachen die mich richtig nervt. Da endet man sehr oft mit
einen Tuple über einen partiellen Aufruf oder so einer Scheiße, ohne das es gewollt ist.

[edit]
Bei Operatoren will ich aber lieber Vorsichtig bleiben ... nicht das da nachher noch ein Fanboy vor meiner Tür steht und mit
dem Baseballschläger winkt :D
Autor:  Sascha Willems [ Fr Jun 05, 2015 20:41 ]
Betreff des Beitrags:  Re: Spass mit F#
Warum kein C++17? Da steckt ja schon ganz viel modernes drin, auch was funktionale Programmierung angeht. Ich nutze momentan schon einige C++11 (Lambdas sind sehr schick :)) /C++14 Features, und finde das richtig toll, grade im Gegensatz zu sowas altbackenem wie Delphi ;)

Jonathan Blow (Entwickelt afaik grade "The witness" für PS4) entwickelt auch grade ne moderne Sprache (v.a. für Gamedev). Dazu gibts dann regelmäßig auf Twtitch Livesessions in denen man ihm beim Entwickeln der neuen Sprache zuschauen kann. Die ganzen Talks kann man auch bei YouTube sehen (https://www.youtube.com/user/jblow888).
Autor:  yunharla [ Fr Jun 05, 2015 21:20 ]
Betreff des Beitrags:  Re: Spass mit F#
Hi, danke für den Link. Sieht echt cool aus was der Junge da macht. Ich werde es mir mal die nächsten Tage etwas genauer
anschauen was dort abgeht. Ich denke da kann man sich bestimmt ein paar Ideen mopsen.

Bezüglich C++, meine Meinung dazu sollte ja hinreichend bekannt sein :)

[edit]

gerade dabei Typennamen zu bauen.
Autor:  yunharla [ Mo Jun 08, 2015 21:06 ]
Betreff des Beitrags:  Re: Spass mit F#
Ah ich mach einfach mal ein Doppelpost:

Ich habe jetzt das Grundlegende Gerüst für Type-Namen fertig. Das Ganze orientiert sich stark
an Sprachen wie C#, wo halt der Typename selbstständig ist. Man braucht also keinen Identifier um
ein Array zu deklarieren oder so etwas. Außerdem gibt es auch hier wieder zusätzliche Klammern
um solche Probleme wie folgendes zu erschlagen:
Code:
  1.  
  2. const (const int[12,24])(int)
  3.  


Fragt sich nur wie ich dabei jetzt noch Generics und Pointer unterbringe :mrgreen:
Autor:  Lord Horazont [ Di Jun 09, 2015 14:31 ]
Betreff des Beitrags:  Re: Spass mit F#
Du könntest einen Projektthread aufmachen.
Autor:  sharkman [ Di Jun 09, 2015 16:47 ]
Betreff des Beitrags:  Re: Spass mit F#
Zitat:
Fragt sich nur wie ich dabei jetzt noch Generics und Pointer unterbringe
wenn du c-artige syntax haben willst, sehen generics so aus
Code:
  1. vector<int> ivec
;) Wie du das in deinen Parse-tree reinbringst, kann ich dir leider nicht sagen.
aber was du mit pointern willst, in einer „semi-funktionalen“ Sprache, erschließt sich mir nicht, zumal mit pointern GC recht schwierig zu implementieren sein dürfte (da alles, was ein int sein könnte - oder eben ein pointer - das dir irgendwo in deinen Speicher zeigt, bedeutet, dass du das, was da im Speicher steht, nicht löschen kannst; und verschieben kannst du auch nichts, weil du sonst den int kaputt machst, der nur zufällig in deinen Speicher zeigt). Und ohne funktionierenden GC kannst du den funktionalen Teil gleich wieder vergessen.
(der letzte Absatz gilt nicht wenn besagte pointer in Wahrheit shared_ptr, etc sind)
Autor:  yunharla [ Di Jun 09, 2015 18:26 ]
Betreff des Beitrags:  Re: Spass mit F#
So habe noch ein bissel am Syntax gewerkelt. Der youtube channel weiter oben ist da eine echt gute Quelle für Ideen.
Typen haben jetzt nur noch einen Primären Teil und Prefix-Attribute. Daraus ergibt sich dann ein
schönes Links-nach-Recht:
Code:
  1.  
  2. const ptr [] const (int,int) -> const ptr int
  3.  

Also eine konstante Pointer zu einen Array aus konstanten Funktionen die Int und Int nehmen und eine konstante Pointer auf einen Integer zurückgeben :)

Das ist doch mal wunderbar :)



sharkman hat geschrieben:
Zitat:
Fragt sich nur wie ich dabei jetzt noch Generics und Pointer unterbringe
wenn du c-artige syntax haben willst, sehen generics so aus
Code:
  1. vector<int> ivec
;) Wie du das in deinen Parse-tree reinbringst, kann ich dir leider nicht sagen.
aber was du mit pointern willst, in einer „semi-funktionalen“ Sprache, erschließt sich mir nicht, zumal mit pointern GC recht schwierig zu implementieren sein dürfte (da alles, was ein int sein könnte - oder eben ein pointer - das dir irgendwo in deinen Speicher zeigt, bedeutet, dass du das, was da im Speicher steht, nicht löschen kannst; und verschieben kannst du auch nichts, weil du sonst den int kaputt machst, der nur zufällig in deinen Speicher zeigt). Und ohne funktionierenden GC kannst du den funktionalen Teil gleich wieder vergessen.
(der letzte Absatz gilt nicht wenn besagte pointer in Wahrheit shared_ptr, etc sind)


Nun bei der Sache mit dem GC kann ich dich beruhigen. Da bekommst du schon Quake & Dirty mehr hin als alles was Smartpointer können. Als Compiler weiß man halt einfach mehr. Falls es aber doch nötig wird kann man immer
noch auf solche Sachen wie Boehm GC zurückgreifen oder den MiniCollector mal zum laufen bringen (*hust*).

Was allerdings die Pointer an sich angeht: Ja da bin ich am überlegen ob man diese vielleicht, wie etwa beim "ref" von C#, besser Wrappen sollte oder so. Weiß ich noch nicht wie ich das genau implementieren werde. Aber man darf halt nicht vergessen das man ja schließlich gegen C-Bibliotheken linken tut.



Lord Horazont hat geschrieben:
Du könntest einen Projektthread aufmachen.


Mir ist noch kein Name eingefallen :P
Autor:  yunharla [ So Jun 14, 2015 18:51 ]
Betreff des Beitrags:  Re: Spass mit F#
Hallo Allerseits,

hier einmal das letzte Update bevor ich einen Projektthread starte:

Ich habe jetzt auch Deklarationen und Statements fertig. Anbei mal ein kurzes Beispiel das die Sachen zeigt:

Code:
  1.  
  2.  
  3. static say_hello : () { //Deklarationen sind StorageClass + Name + Type + Compound
  4.     printf("hallo world");
  5. }
  6. main : (argc : int, argv : ptr ptr char) -> int { //wobei StorageClass optional ist
  7.     makefive : const (i: int) -> int = 5; //und auch Expressions gehen :-)
  8.     say_hello();
  9.     for(x := makefive(12); x < 10; x++) { //den Type kann man natürlich auch weglassen um diesen automatisch zu bekommen.
  10.          //for schleifen waren ein Alptraum....
  11.          x+=12; //Assignments sind übrigens ein Statement und keine Expression
  12.     }
  13.     do {
  14.         test : ptr const char = "hallo world";
  15.         testb := test;
  16.         if(testb) {
  17.             switch(test) {
  18.                 case copy(testb): //switch soll später alle Expressions nehmen können
  19.                     printf("copy seems to work",testb);
  20.                 case testb: //natürlich gibt es auch wieder fallthrough
  21.                     printf("%s equals %s",test,testb);
  22.                     return 1;
  23.                 default:
  24.                     printf("%s does not equal %s",test,testb);
  25.                     break;
  26.             }
  27.             break;
  28.         } else {
  29.             continue;
  30.         }
  31.     } while(false);
  32.     return 0;
  33. }
  34.  
  35.  
  36.  


Zur Zeit fehlen noch:
- Initializer für Structs, Union und Array
- ein Mechanismus für "#include".
- Konstruktorfunktionen für Typen
- "Extend" / Vererbung für Typen

Im Projektthread möchte ich mich dann auf die Semantik und die Umwandlung nach C konzentrieren.
Autor:  yunharla [ Fr Jun 19, 2015 15:54 ]
Betreff des Beitrags:  Re: Spass mit F#
Kann einer der Mods den Thread zu den Meinungen zum BTCC Projekt verschieben?

Danke schon einmal im Voraus :)
Autor:  TAK2004 [ Do Jun 25, 2015 14:19 ]
Betreff des Beitrags:  Re: @BTCC | ehemals: Spass mit F#
Ist das Experimenteller Natur oder willst du es konkret für ein Projekt einsetzen ?

Hast du schon überlegt die AST lib von Clang zu benutzen http://clang.llvm.org/docs/IntroductionToTheClangAST.html ?
Ich hab da mal 1-2 Tage mit rum gespielt und die ist recht klein und einfach zu bedienen.
Der Vorteil ist, mann kann dann mit dem AST Code und clang in alle unterstützten Sprachen exportieren bzw. dann auch kompilieren.
Unity3D hat an sowas experimentiert(ka ob es schon produktiv im Einsatz ist), die kompilieren den C# Code in AST, konvertieren nach c++ und jagen es dann durch den C++ compiler, damit das ganze kleiner und schneller ist. Das ganze ist als Produktiv Feature geplant und war in der Experimentierphase schon deutlich besser als normal mit C# kompilieren.
Das haben die Angefangen, als die Emscripten mit HTML5/WebGL export implementiert haben(das ist schon produktiv nutzbar).
Autor:  yunharla [ Do Jun 25, 2015 17:55 ]
Betreff des Beitrags:  Re: @BTCC | ehemals: Spass mit F#
Nein ich denke nicht das es richtig wäre Clang direkt einzubauen. Das Tool selbst ist eine .NET Bibliothek, welche
du auch unter Mono bauen kannst. Diese gibt dir sozusagen eine bessere Symbol-Tabelle mit Typen, Variablen, Funktionen
und eine Art Mini Assembler (vielleicht sogar direkt CIL-Objekte?). Das Ganze sind zur Zeit 3 Dictionaries, wobei bei Variablen
und Funktionen zur Zeit noch der Initializer mit dem Assembler fehlt (und damit natürlich auch noch Type-Inference).

Mein Plan ist jetzt erst einmal die Initializer abzuschließen. Vorzugsweise bevor ich mein Haus in besitz nehme.

Ich denke man sollte dann erst einmal einen Zwischenrelease machen und Bugs beheben. Einfach damit die Leute
Live sehen "aha hier ist mein Code, das kommt raus, das und das muss eingebaut werden". Wer weiß vielleicht möchte
der eine dann lieber einen Interpreter bauen, der nächste will C++, der nächste will C# ....

Da es ja zur Zeit nur eine "bessere" Form von C ist, welche Type-Inference und Overloads unterstützt, kann dann also
relativ schnell (vielleicht 1-2 Stunden) etwas zusammenbauen.

Ich selbst werde wahrscheinlich C und dann später Managed C++ implementieren. Ganz einfach weil ich hier viele meiner
Kollegen sehe die in letzter Zeit an die Grenzen von C# kommen und denen C++ zu kompliziert ist.


Wie gesagt zur Zeit fehlen noch die Initializer. Die sind schon zu ungefähr 60% fertig (Type-Inference für Expressions) aber es
fehlen dort dann noch die ganzen Statements und die konkrete Umwandlung nach Assembler. Da sind allerdings noch 1,2 kleine Sachen
auf die ich noch keine Lösung außer Bruteforce habe...
Autor:  TAK2004 [ Do Jun 25, 2015 18:16 ]
Betreff des Beitrags:  Re: @BTCC | ehemals: Spass mit F#
Du hast mich missverstanden, ich meinte nicht, dass du clang einbauen sollst, sondern die AST lib von clang.
Die ist eine eigenständige Bibliothek, mit der ich z.B. in meinem RadonFramework unter VS2013 C++ gespielt hab.
Die Bibliothek ist grob gesagt Spezifikation in Codeform.
Man erzeugt ein Baum, packt die verfügbaren Symbole rein und am Ende kann man den Baum in eine Datei schreiben und clang würde ihn verstehen.
Neben CLang verstehen ihn auch andere Compiler und Tools, die auf den pseudo Standard bauen, z.B. Khronos SPIR, Mono und Intel SPMD.
Autor:  yunharla [ Do Jun 25, 2015 21:08 ]
Betreff des Beitrags:  Re: @BTCC | ehemals: Spass mit F#
TAK2004 hat geschrieben:
Du hast mich missverstanden, ich meinte nicht, dass du clang einbauen sollst, sondern die AST lib von clang.
Die ist eine eigenständige Bibliothek, mit der ich z.B. in meinem RadonFramework unter VS2013 C++ gespielt hab.
Die Bibliothek ist grob gesagt Spezifikation in Codeform.
Man erzeugt ein Baum, packt die verfügbaren Symbole rein und am Ende kann man den Baum in eine Datei schreiben und clang würde ihn verstehen.
Neben CLang verstehen ihn auch andere Compiler und Tools, die auf den pseudo Standard bauen, z.B. Khronos SPIR, Mono und Intel SPMD.


Ja aber der Punkt ist doch der. F# und OCaml können solche Sachen von Haus aus sehr gut und sind dort sehr stark optimiert (Wiki sagt C/C++ Performance). Warum
sollte ich also eine zusätzliche Abhängigkeit einbauen die wahrscheinlich nur minimalen Vorteil bringt? Ich meine, der Code ist, zumindest für mich, genauso
leicht zu verstehen wie eine Yacc Datei, rein funktional und sehr schnell. Schau dir doch einfach mal einen kleinen Ausschnitt aus dem Parser / der AST-Generierung an:
Code:
  1.  
  2.     and parsePrimaryType = function
  3.         | "void" :: t -> PrimaryType.Void,t //t ist der "Rest" in der Token-Liste
  4.         | "float" :: t -> PrimaryType.Float,t
  5.         | "double" :: t -> PrimaryType.Double,t
  6.         | "char" :: t -> PrimaryType.Char,t
  7.         | "signed" :: "char" :: t -> PrimaryType.Char,t
  8.         | "unsigned" :: "char" :: t -> PrimaryType.UChar,t
  9.         | "short" :: t -> PrimaryType.Short,t
  10.         | "signed" :: "short" :: t -> PrimaryType.Short,t
  11.         | "unsigned" :: "short" :: t -> PrimaryType.UShort,t
  12.         | "int" :: t -> PrimaryType.Int,t
  13.         | "signed" :: "int" :: t -> PrimaryType.Int,t
  14.         | "unsigned" :: "int" :: t -> PrimaryType.UInt,t
  15.         | "long" :: t -> PrimaryType.Long,t
  16.         | "signed" :: "long" :: t -> PrimaryType.Long,t
  17.         | "unsigned" :: "long" :: t -> PrimaryType.ULong,t
  18.         | "bool" :: t -> PrimaryType.Bool,t
  19.         | "struct" :: "{" :: t ->
  20.             let x,xt = parseTupleArguments [] t //parseTupleArguments braucht einen Accumulator ([] = leere Sequenz) und eine Liste von Tokens
  21.             PrimaryType.Struct(x),xt //gib einen Tuple aus struct mit Liste von Argumenten und den "Rest" nach den Argumenten
  22.         | "union" :: "{" :: t ->
  23.             let x,xt = parseTupleArguments [] t
  24.             PrimaryType.Union(x),xt
  25.         | t ->
  26.             let x,xt = parseNameDeclaration t
  27.             PrimaryType.Name(x),xt
  28.         //| "enum" :: t ->
  29.  


oder hier aus der Semantischen Analyse
Code:
  1.  
  2. let isDeclarationType =
  3.     function //types cannot be imported and must be full declarations
  4.     | Declaration.Declaration(t,_,_,_) -> //uns interessiert nur die Storageclass daher "_" zum ignore
  5.         match t with
  6.         | DeclarationSpecifier.Type -> true
  7.         | _ -> false
  8.     | _ -> false
  9.  


Da versteht doch sofort jeder was dort passiert, oder nicht? (ist ein Switch auf Steroide laut MS) Plus du hast garantiert keinen Stress mit irgendwelchen Lizenzen von denen eh niemand eine Ahnung hat
und du kannst es sehr leicht auf alle möglichen Toolchains portieren :)
Seite 1 von 2 Alle Zeiten sind UTC + 1 Stunde
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/