ZFX + Developia

Verfasst: **22.08.2022, 17:32**

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.

Verfasst: **31.10.2022, 22:06**

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 :)

Verfasst: **18.03.2023, 10:37**

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.

Verfasst: **28.05.2023, 10:23**

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 :)

ZFX + Developia

[Projekt] Type Research Programming Language

Re: [Projekt] Type Research Programming Language

Re: [Projekt] Type Research Programming Language

Re: [Projekt] Type Research Programming Language

Re: [Projekt] Type Research Programming Language