[cctmp] Okay, I was putting off translating my cotuple type into object oriented dual-time generics---until today. I was worried it wouldn't work, but it does, and it was incredibly simple to do [see images]. Image 1 - An example which calls the *cases* operator for a given cotuple value. 1/6

[cctmp] Object oriented dual time generics: This isn't an overhaul of my library, it's an addition to mitigate complexity. It should take a few days, but once added properly it'll clean up a bunch of existing application code---the type system remains the same. How to read this? [see image] 1/11

[cctmp] Today I'm brainstorming how to add my parser generator's parser table [see image] to my compile time type system. Once the parser generator is built, I can use it to create such tables, but as it doesn't yet exist I have to bootstrap the process by manually computing this one. 1/12

In my NDC Toronto talk (back in May), I mentioned it took an average of about ~9s between GCC and Clang to lex a given context free grammar (string literal) and print to screen [see images]. And now, with the same example: GCC - 1.385s Clang - 2.286s Yes. Yes, it was worth it. Thank you.

[cctmp] Today I'm translating my parser generator's lexer into the dual-time paradigm. I'm glad I put in the extra effort to create a mini-dsl to add types to concord type systems [see image]. For as tedious as this is, it is otherwise much more long winded w/ C++ generic (template) grammar. 1/3

For some reason my post is being automatically deleted.

[cctmp] I finally have my concord dsl working [see image]. It's not meant for general use, it's just for me: It's used to create concords inhabited w/ types, which then makes my library's test functions very simple to code. It's still tedious, but now I can focus on the ideas, not the C++ grammar.

Updated my firefox. When I did, I observed this [see image]. I get that they're trying to advertise their vpn, but this is excessive. This browser use to be good, but they've been making bad choice after bad choice for a long while now. I'm starting to wanna switch, but switch to what, you know?

[cctmp] Here's an example [see image] of my "auto ~ typename" correspondence which I didn't get to explain in my conference talk a few weeks ago. In C++26 there's proper reflection, but in C++17 this correspondence is it: It's mostly relevant to my continuation constructing paradigm, 1/4

I'm finally uploading some photos from the conference I attended last week. My favourite talk was this one [see image]. 1/2

[C++] In my recent talk I gave an example demonstrating the use of concepts. The code in the first image was my example. The following day I attended a talk and found out my code can be simplified to what's in the second image. Always more to learn, haha.

[cctmp] Today, as part of cleaning up my library, I've added in a small bytecode DSL to help with testing my compile time type system. Image 1 - A line within a program is determined by an instruction followed by a number. 1/6

[cctmp] After yesterday's failure, I today simplified my continuant machines to *return void* and to only accept C-style pointers. Square, sum of squares, and factorial all work properly now for both GCC and Clang, both at compile time and run time. I'm noticing that the generated assembly 1/7

[cctmp] Today I finished prototyping an overhaul of my library having to do with continuant machine ~ compile time type system interop. I reimplemented factorial. It didn't go well. It "static assert" works for both GCC and Clang, but only runtime works for Clang. 1/6

[cctmp] I'm stuck. I have something akin to writer's block. I'm still figuring out how best to add functions to my compile time type system (concord classes). In order for continuant machines to be perf compatible with concords, they as functions need to assign to memory [see image]. 1/5

In the attached image is a difference equation I solved maybe when I was 18-19. The trick is to use the simple equation (on the left) to substitute into its tail and reshape. Instead of playing the guessing game, I generalized and added an accumulator (variable m) then unfolded from there. 2/4

[cctmp] I think this is how I'll extend my meta-assembly and continuant machines [see image]. Every function is now by default an "assign" version of itself. When putting a function on the stack, there are also special instructions to convert it to a version which returns a value. 1/2

[cctmp] Creating my mini meta-compiler is a multistep process. Today I've handcoded the meta-assembly [see image] for the following functions: { identity, square, sum of squares, factorial, fibonacci } I have enough set up now I can handroll such assembly and turn that "bytecode" into 1/4

Good talk [see images; link in the following post]. Like anything, I think proof assistants need open-source competition to best serve the community as a whole, but I also recognize Lean is the popular choice right now, and *importantly* it seems to have a thriving community. 1/2

[C++] Watching a Cppcon talk titled "Practical Reflection" by Barry Revzin. This particular code limitation stood out to me [see image]. It fails to compile because "type" needs to be a constant expression. I'm wondering if my "U_store_T -> T_restore_U" TMP trick works with this. 1/4

These three. Thank you for all your commitments, hard work, and serious efforts, but also thank you for your comedy!

but I took one more day to make improvements. Why? lexing the context free grammar [see image] entirely at compile time gave horrendous perf: gcc: ~17s clang: ~12s It bothered me, so today I added in support to write concords to file to be read back in again 2/4

[cctmp] Was really hoping to have my lexer working in time for my personal February 1st deadline [see image]. My test case is the first line of the context free grammar for my parser generator: "S -> i F D : l_value ;" In the image, everything reads backwards and in reverse. It's easy 1/3

[cctmp] I'm ready to test out my lexer, So the first thing I did was add in a string literal representing the context free grammar (CFG) of my parser generator (PG) to my concord type system [see image]. The compile time on simply adding this in was horrendous: gcc: ~8s clang: ~4s 1/11

[cctmp] Today I added back the lexer transition table for my library's (LL) parser generator. Nearly 4 months of bitter work, but it's getting faster. The grammar is still tedious at this stage, but it's much easier creating data structures in my type system than ad hoc compile time C++. Hooray!

[cctmp] Stack allocate all the things! This code is proof of concept---it's honestly a mess---but otherwise it demonstrates a compile time alternative to heap based memory allocation [see image]. The notable part is the highlighted *sort_size*. 1/4

[cctmp] My type system has enough functional code (I'm sufficiently satisfied with) that I'm ready to implement an LL(1) lexer. I'm reviewing my proof of concept code [see image]. The work there is already done, it just needs to be translated. It feels weird to have finally reached this point.

[cctmp] I have my first sort algorithm! [see image] It's not a super high performance sort, because my type system is functional and so everything is lists. Even then, I optimized: I reduced the number of list reverses by alternating between the comparison (pred) and its negation [not shown]. 1/3

[cctmp] Mostly I'm taking the day off because from here on out I'm now building well known functional list algorithms for the next ~1.5 weeks. It'll be easier and more enjoyable than lower level C++. Regardless, before I continue I've been thinking over one last optimization [see image]. 1/5

[cctmp] Okay this one is exciting! [see image] I introduced an "auxiliary" paradigm to my concord type system to reduce memory usage within concords themselves (i.e. temporary memory). I've now added the ability to create compile time concords which can still generate run time auxiliaries. 1/3