[Projekt] Type Research Programming Language

Hier könnt ihr euch selbst, eure Homepage, euren Entwicklerstammtisch, Termine oder eure Projekte vorstellen.
Forumsregeln
Bitte Präfixe benutzen. Das Präfix "[Projekt]" bewirkt die Aufnahme von Bildern aus den Beiträgen des Themenerstellers in den Showroom. Alle Bilder aus dem Thema Showroom erscheinen ebenfalls im Showroom auf der Frontpage. Es werden nur Bilder berücksichtigt, die entweder mit dem attachement- oder dem img-BBCode im Beitrag angezeigt werden.

Die Bildersammelfunktion muss manuell ausgeführt werden, die URL dazu und weitere Details zum Showroom sind hier zu finden.

This forum is primarily intended for German-language video game developers. Please don't post promotional information targeted at end users.
Benutzeravatar
Lord Delvin
Establishment
Beiträge: 573
Registriert: 05.07.2003, 11:17

Re: [Projekt] Type Research Programming Language

Beitrag von Lord Delvin »

Chromanoid hat geschrieben: 21.08.2022, 21:14 Zu Closures:
Ich mag fn, fun und Co. überhaupt nicht. Da finde ich es in Typescript schöner: type TaxCalculator = (amount: number) => number;.Nur whitespaces und Wörter als Trenner kommt mir immer irgendwie komisch vor, weil sich dadurch meist keine schöne "natürliche" Weise ergibt, wie Linebreaks und Einrichtungen zu laufen haben.
Eigentlich ging es um Funktionstypen, Typescript verwendet dieselbe Syntax aber für beides. Das wäre bei mir nicht möglich, weil ein Typ ein Wert ist und bei gleicher Syntax kein Mensch mehr verstehen würde, was gemeint ist. Eigentlich hat mich TypeScript jetzt final davon überzeugt, dass ich das mit den Namen doch gleich einbaue und dafür aber die Syntax mit dem "def" nehme, weil es für nichttriviale Typen am lesbarsten ist.
XML/JSON/EMF in schnell: OGSS
Keine Lust mehr auf C++? Versuche Tyr: Get & Get started
Benutzeravatar
Lord Delvin
Establishment
Beiträge: 573
Registriert: 05.07.2003, 11:17

Re: [Projekt] Type Research Programming Language

Beitrag von Lord Delvin »

Alexander Kornrumpf hat geschrieben: 19.08.2022, 12:43 Ehrlich gesagt, ich verstehe das Beispiel und deine Ausführungen dazu nicht. Ich denke dass Leute die schonmal mit Java oder JavaScript gearbeitet haben, erwarten dass sie sowas machen können (Pseudocode)

Code: Alles auswählen

collection.removeIf(element -> element.property > someQuasiConstantFromOuterScope)
Hab' da mal was vorbereitet :)

Code: Alles auswählen

var buff = "HÖLLä".chars().toBuffer()
buff.removeIf c do (c > 'L')
"HLL".chars().sameElements[character.`==`](buff.iterator())
Das removeIf bindet eine lokale Variable c und einen Ausdruck in () oder {} und wendet ihn auf jedes element in buff an.
Ausführlichere Tests: https://github.com/tyr-lang/stdlib/blob ... Buffer.tyr
Und die Implementierung: https://github.com/tyr-lang/stdlib/blob ... r.tyr#L142

Hab' jetzt die Funktionstypliterale, Funktionstemplates, ein paar Bugs gefixt und leider auch teilweise eine neu Templatetyptheorie. Wird wohl mit Generics weitergehen :)
XML/JSON/EMF in schnell: OGSS
Keine Lust mehr auf C++? Versuche Tyr: Get & Get started
Benutzeravatar
Lord Delvin
Establishment
Beiträge: 573
Registriert: 05.07.2003, 11:17

Re: [Projekt] Type Research Programming Language

Beitrag von Lord Delvin »

Hatte irgendwann Abends nebenher mal angefangen eine ArrayDeque zu implementieren. Tat in ein paar Tests, aber irgendwie nicht in einem mit 100 Elementen. Weil ich immer nur mit Compilerbugs konfrontiert bin, dachte ich aber irgendwie, der Code sei ok und der Compiler hat eine Macke. Gibt schon länger valgrind-Integration. Also valgrind angeschaut; sagt irgendwas von write. Ratlos gesucht, nichts gefunden, was auf einen Bug hindeutet. Naja wenn man sich das anschaut, sieht das so aus:

Code: Alles auswählen

==55238== Command: ./main.1.tests
==55238== 
==55238== Invalid write of size 8
==55238==    at 0x401301: ??? (tyr.container/ArrayDeque.tyr:112)
==55238==    by 0x404701: main.T test loop (main/main.tyr:15)
==55238==    by 0x404701: main (unkown:0)
==55238==  Address 0x4a5d0f8 is 8 bytes after a block of size 64 alloc'd
==55238==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==55238==    by 0x4046D1: tyr.container.ArrayDeque[tyr.lang.String].new(tyr.container.ArrayDeque[tyr.lang.String],tyr.lang.container.index_t):tyr.lang.void (tyr.container/ArrayDeque.tyr:52)
==55238==    by 0x4046D1: main.T test loop (main/main.tyr:9)
==55238==    by 0x4046D1: main (unkown:0)
==55238== 
==55238== Invalid write of size 8
==55238==    at 0x401301: ??? (tyr.container/ArrayDeque.tyr:112)
==55238==    by 0x40470F: main.T test loop (main/main.tyr:16)
==55238==    by 0x40470F: main (unkown:0)
==55238==  Address 0x4a5d100 is 16 bytes after a block of size 64 alloc'd
==55238==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==55238==    by 0x4046D1: tyr.container.ArrayDeque[tyr.lang.String].new(tyr.container.ArrayDeque[tyr.lang.String],tyr.lang.container.index_t):tyr.lang.void (tyr.container/ArrayDeque.tyr:52)
==55238==    by 0x4046D1: main.T test loop (main/main.tyr:9)
==55238==    by 0x4046D1: main (unkown:0)
==55238== 
whob==55238== 
==55238== HEAP SUMMARY:
==55238==     in use at exit: 0 bytes in 0 blocks
==55238==   total heap usage: 3 allocs, 3 frees, 1,128 bytes allocated
==55238== 
==55238== All heap blocks were freed -- no leaks are possible
Wenn man jetzt einen Schritt zurücktritt stellt man natürlich fest, dass ich in den ArrayDeques das Problem habe, dass die validen Elemente über den Rand des backing Arrays hinaus an den Anfang wrappen. D.h. einfach data(end++) ist jetzt *nicht direkt* die richtige Implementierung für ein append.

Ich muss einfach mehr an mich und meine Tools glauben :-/

Was ich ehrlich gesagt nicht ganz verstehe, ist, warum der clang memory sanitizer nichts sinnvolles beizutragen hatte. Letztlich bedeutet das für das Projekt aber, dass ich die Check-Bounds-Optionen spätestens mit 0.9 reinbauen werde. Brauch dafür aber erstmal Exceptions. Und vielleicht freie Variablen in der Templatetyptheorie; muss ich mal schauen.
XML/JSON/EMF in schnell: OGSS
Keine Lust mehr auf C++? Versuche Tyr: Get & Get started
Benutzeravatar
Lord Delvin
Establishment
Beiträge: 573
Registriert: 05.07.2003, 11:17

Re: [Projekt] Type Research Programming Language

Beitrag von Lord Delvin »

Hatte in letzter Zeit wenig zu erzählen, weil ich entweder keine Zeit hatte oder nur an Dingen gearbeitet habe, die mir wenig erwähnenswert erschienen. Jetzt bin ich an einem Punkt, an dem ich mal wieder was entscheiden muss. Hab's mal hier aufgeschrieben. Mir noch etwas unklar, was ich von der Plattform halten soll; egal.
Im Kern mache ich gerade mit mir selbst aus, wie ich switch über den Typ des Ziels implementieren soll. Also grob etwas um schreiben zu können:

Code: Alles auswählen

switch e := nextEvent() {
  if MouseEvent { ... }
  if KeyBoardEvent { ... }
  else { ... }
}
Und e soll natürlich den Typ haben, den das if testet, wenn man es verwendet. Bin gespannt, wie sich das anfühlt, wenn ich's gebaut habe :)
XML/JSON/EMF in schnell: OGSS
Keine Lust mehr auf C++? Versuche Tyr: Get & Get started
Benutzeravatar
Lord Delvin
Establishment
Beiträge: 573
Registriert: 05.07.2003, 11:17

Re: [Projekt] Type Research Programming Language

Beitrag von Lord Delvin »

Bin gerade mal wieder in der Hölle der impliziten Casts am Aufräumen. Weil sich bei mir gerade einige Flexibilisierungen ergeben würden, die mir teilweise unplausibel erscheinen, wollte ich mal wissen, was C++ macht. Da gilt "Conversion functions can be inherited and can be virtual, but cannot be static. A conversion function in the derived class does not hide a conversion function in the base class unless they are converting to the same type.", was mich sehr irritiert, weil es bei mir bis jetzt immer andersrum war. Hat jemand eine Idee, was deren Problem mit static ist?
Ich frage mich gerade ernsthaft, ob ich mir gerade sehr hart in den Fuß schieße oder ob das einfach aus meiner "representational transparency" kommt.
XML/JSON/EMF in schnell: OGSS
Keine Lust mehr auf C++? Versuche Tyr: Get & Get started
Benutzeravatar
Lord Delvin
Establishment
Beiträge: 573
Registriert: 05.07.2003, 11:17

Re: [Projekt] Type Research Programming Language

Beitrag von Lord Delvin »

Hab' mal wieder versucht, das was ich mache und die Hintergründe in einem Artikel zu beschreiben: https://medium.com/@feldentm/tyr-2-towa ... 723a25d4ac

Diesmal gehts um Call Operator und was da so alles dran hängt.
XML/JSON/EMF in schnell: OGSS
Keine Lust mehr auf C++? Versuche Tyr: Get & Get started
Benutzeravatar
Lord Delvin
Establishment
Beiträge: 573
Registriert: 05.07.2003, 11:17

Re: [Projekt] Type Research Programming Language

Beitrag von Lord Delvin »

Und noch was habe ich aufgeschrieben: https://medium.com/@feldentm/tyr-3-elab ... 0e6dcce64b

Diesmal geht's um Konsequenzen mit denen man Leben muss, wenn man alle Vorwärtsdeklarationen automatisch vom Compiler machen lässt.
XML/JSON/EMF in schnell: OGSS
Keine Lust mehr auf C++? Versuche Tyr: Get & Get started
Benutzeravatar
Lord Delvin
Establishment
Beiträge: 573
Registriert: 05.07.2003, 11:17

Re: [Projekt] Type Research Programming Language

Beitrag von Lord Delvin »

Habe gerade geprüft, wie gut LLVM meinen switch class code optimieren kann. Es stellt sich raus, dass der test

Code: Alles auswählen

var r = ""
switch class r {
  if String false
  if StringLiteral true
  else false
}
einfach komplett rausoptimiert wird. Wenn man ihn kaputt macht, z.B. indem man r mit null initialisiert, dann wird er zu false rausoptimiert. Genau so, wie ich mir das gewünscht habe. Zeigt einmal mehr, wie sehr man auch i.A. LTO haben will :)
XML/JSON/EMF in schnell: OGSS
Keine Lust mehr auf C++? Versuche Tyr: Get & Get started
Benutzeravatar
Lord Delvin
Establishment
Beiträge: 573
Registriert: 05.07.2003, 11:17

Re: [Projekt] Type Research Programming Language

Beitrag von Lord Delvin »

Habe die letzten Tage gelernt, dass break und continue einfach doch eine ganze Ecke komplizierter sind, als man eigentlich denken würde und einen Artikel dazu geschrieben. Ich hatte ja am Anfang des Projekts gesagt, dass man für brauchbare Forschungsergebnisse aus dieser Spielzeugsprachenecke raus muss. Ist tatsächlich so und liefert manchmal sehr verblüffende Erkentnisse. Am Ende hatte ich tatsächlich ziemlich viel Spaß damit die ganzen verrückten Sachen wie do while über Funktionszeiger zu testen und zu sehen, dass es jetzt alles zusammenpasst :)
XML/JSON/EMF in schnell: OGSS
Keine Lust mehr auf C++? Versuche Tyr: Get & Get started
Antworten