[Projekt] Type Research Programming Language

[Lord Delvin]

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.

[Lord Delvin]

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

[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.

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

[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.

[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.

[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.

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

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

[Lord Delvin]

Weil ich immer wieder Diskussionen führe, wie man Software testet, habe ich einen Artikel geschrieben, in dem ich einen Schritt vor dem Release beleuchte, bei dem man sich die Coverage anschaut und versucht darauf basierend Beispiele zu finden. Im Kern Whitebox-Integrationstests. Keine Ahnung ob es jemandem wirklich hilft. Habe ein paar Beispiele reingepackt; teilweise finde ich's erschreckend, teilweise sind es nur obskure Randfälle, die eh keinen getroffen hätten.

Das Release ist jetzt auch fertig. Screenshots mit einem SDL/OpenGL Dreieck hatte ich glaube ich schon gezeigt. Langsam muss man da echt einfach mal Content hinstellen, damit Leute sehen, dass es wirklich brauchbar ist.

Erkenntnis für die Community hier ist vermutlich, dass zwei Jahre schon ein grenzwertig weiter Schritt ist. Ungeachtet der Motivation. Und was am Ende unerlässlich ist, ist sehr viel Disziplin auch unangenehme Sachen zu machen, wie sechs Monate Refactoring, um Architekturprobleme zu beseitigen, intensives Testen und eben einfach Bugs fixen. Das gilt natürlich genauso für irgendwelche Spiele, die ich darauf aufbauen würde, weil man da genauso erreichen muss, dass es beim Release irgendwie Sinn ergibt und lustig ist und nicht einfach crasht. Feinschliff ist immer Aufwand.

[NytroX]

Glückwunsch zum Release! :-)

was am Ende unerlässlich ist, ist sehr viel Disziplin auch unangenehme Sachen zu machen

Ich glaube das ist der Nummer 1 Grund warum Hobbyprojekte nicht fertig werden. Inklusive meiner.
Man muss sich halt echt Zeit nehmen, Tests schreiben, Coverage durchgehen usw. damit da ein gutes Produkt draus wird.

[Lord Delvin]

Das intern über Status/Either/Error zu machen verursacht halt im regulären Code verteilte Kosten

Ja, stimmt. Das ist das größte Problem daran. Allerdings verursachen Exceptions das auch - einfach weil der Compiler plötzlich aufhört, Cross-Function Optimierungen zu machen.
Für mich sieht ein
int f(int a, int b) throws c halt immer automatisch aus wie
void f(int* ret, c* ex, int a, int b)
Das macht übrigens auch die Rückgabe schneller als ein Rückgabewert. Aber der Compiler macht das meist schon alleine, und muss es in einigen Situationen auch tun nach dem neuen C++ Standard. Jai macht das auch so, weil schneller.
Nachteil ist aber hier: mehr Argumente bedeutet ggf. mehr Register Usage beim Aufruf - und damit ggf. auch auslagern auf den Stack, was es dann wieder langsamer macht.

Also wie mans macht, es hilft alles nichts. Irgendwie muss man die Fehler mitbekommen und behandeln, die perfekte Lösung ist noch nicht gefunden :-)

https://www.open-std.org/jtc1/sc22/wg21 ... 1947r0.pdf

Da drin wurde der Sache schonmal auf den Grund gegangen. Ein paar interessante Auszüge:

Schemes that consider an exception throw as just an alternative return path was considered different: not C++ exception handling

=> Dummer Kommentar von mir: ÄÄh, warum? ;-P

simply demonstrating that a throw is slower than a return does not demonstrate a violation [of the zero-overhead principle]

=> returns sind also schneller

Alternative schemes based on “markers” in stack frames were tried early on, but their performance was deemed inferior

=> Tabellen-basierte Abarbeitung ist also relativ optimal für Exceptions ohne Rückgabewerte.

In Summe ist das soweit ich weiß immer noch Stand der Dinge.
Siehe auch hier der Talk von Herb Sutter: https://www.youtube.com/watch?v=ARYP83yNAWk&t=1200s

Wenn ich also eine Programmier-Sprache entwerfen würde, dann würde ich die schnellste aktuell bekannte Methode verwenden, die auch die Compiler noch gut optimieren -> Rückgabewerte (bzw. mit Syntactic Sugar).
Natürlich kannst du auch neue Wege gehen - im Paper steht auch dass es für den tabellenbasierten Ansatz durchaus noch Optimierungspotenzial gibt.

Würde mich auf jeden Fall interessieren wie es am Ende bei dir aussieht :-)
Zu den versteckten Kosten auch, finde ich super spannend was du da findest :-)

Mal schauen ob ich die Diskussion hierher verlegen kann.
Danke auf jeden Fall für den Link; sollte ich vielleicht auch nochmal spezifisch drauf eingehen. Irgendwie isses aber zu warm um klar zu denken, was zu schreiben oder weiter zu programmieren. Für Haus mit Klimaanlage verdiene ich zu wenig :-/

Also erstmal, weil ich's hier noch nicht verlinkt habe: https://medium.com/@feldentm/designing- ... b54a550e7a
Mein größtes Problem ist tatsächlich erstmal das Memorymanagement, weil ich sicher nicht C++ RTTI oder RAII implementieren werde.
Hatte so schon drei drafts rumliegen, vermutlich schreibe ich aber erstmal dazu einen Kommentar, weil ich weniger drüber nachdenken muss und man direkt was spannendes sagen kann und mir auch bei meinen Begründungen Zusammenhänge klar geworden sind, die ich sonst vermutlich nicht kommuniziert hätte. Für mich ist C++-ABI-Kompatibilität natürlich kein Ziel. Mandat für mich sind derzeit POSIX, ELF, DWARF. Ob ich Itanium ABI EH nehme oder das wirklich clang oder gcc kompatibel mache entscheide ich später. Zumal ich demnächst vermutlich den vierten Ansatz implementiere, weil die cross function optimization tatsächlich für mich was kritisches ist. Habe einen Test dazu geschrieben und wenn ich's nicht optimiert bekomme, sobald da ein finally in der Standardbibliothek steht muss ich mir deutlich überlegen, ob ich nicht aufgebe. In der Größenordnung wie ich das in Tyr machen will, könnte man das in C++ höchstens als LTO implementieren. Bin mir aber nicht sicher ob man das da bezahlen will, weil ich erwarten würde, dass man die erforderlichen Informationen nochmal herleiten müsste.

Zu deinen Fragen:

1) Weil das Go-style errors sind, sich das wie in Go verhält, mit struct schon immer ging und ein komplett anderes ABI hat.

2) Return ist erstmal erheblich schneller. Goto auch. Das ist nicht der Punkt; er schreibt eigentlich ganz passende Fragen auf, die man sich an der Stelle stellen muss. Für mich, insbesondere aus der Praxis, spannend, ist die Frage nach Wurfdistanz und Wahrscheinlichkeit. Wenn du eine Konfigurationskonsistenzprüfung hast, dann ist die Wahrscheinlichkeit quasi null, du undwindest vermutlich den Großteil deines Stacks. Sein bad_alloc Beispiel finde ich auch passend. Für das allermeiste was ich in meinem Leben gesehen habe ist es vollkommen ok so einen Java-style stacktrace in dem Fall zu haben und sich dann zu überlegen, was schiefgegangen ist. Kenne auch Ecken, wo man das fangen will. Selbst wenn man das fängt und einfach durch Lastabwurf löst ist es extrem unwahrscheinlich. Da die Chance vermutlich <1:1mio. Da willst du nicht aus jedem new einen Fehlerwert rausbekommen, falls es vielleicht nicht gut lief und erst recht nicht manuell bis ans Workpackagemanagement unwinden.

3) Nein, da geht's denke ich um was anderes. Du könntest Handleraddressen in deinen Stackframe packen. Das hat aber wieder verteilte Kosten im Gutfall.

Meine persönliche Position wäre ehrlich gesagt nicht zu sagen, dass man die 1:100 kassiert, sondern eher 1:1mio. Würde früher oder später in meine Tests auch ein nothrow reinbauen, was im Prinzip deaktiviertes Exceptionhandling wäre. Vielleicht unter anderem Namen. Ich meine, 1:100 würde bedeuten, dass man sich bei 'nem Mittelgroßen ArrayBuffer einfach den Rangecheck schenkt und auf die Exception beim Überschreiten des Rands hofft. WTF?

Wo's unklarer wird ist sowas wie JSON deserialisieren, dass man von irgendwoher bekommt. Wäre meine Lebenserfahrung aber auch eher, dass man voll auf den Gutfall optimieren will. Das meiste ist dann doch Maschinenkommunikation die das richtig macht. Momentan wäre mir aber nicht mal klar, wie man das seriös benchmarkt. Zumal ich eine local throw optimization habe und das binder inlining; vermutlich muss man ne breite Menge an Fällen benchmarken und hoffen, dass man am Ende irgendwas draus schließen kann.

[Lord Delvin]

So, habe jetzt mal meine Gedanken zu dem Thema aufgeschrieben: https://medium.com/@feldentm/exception- ... 6b6d5cf4fe
Wenn ich das endlich mit in die Templates reinbekommen habe, dann kann ich aufschreiben, was ich am Ende machen will. Vorher ist es nicht sinnvoll, weil ich einfach zu viel ändere und spätestens in drei Monaten anfangen will die anderen Themen fertig zu machen, die ich für das Release haben will, weil's sonst wieder zwei Jahre dauert und nicht eins. Mal schauen; immerhin haben die Exceptions ein paar natürliche Schnittkanten, an denen man ein paar Releases abwarten kann, weils nur abstruse Randfälle sind.