IRC channel logs

<oriansj>hmmm, pattern matching on types brings about an interesting question on behavior regarding immediates in a calculation.

<oriansj> https://paste.debian.net/1309900/ on one hand it enables no internal information about architectures in the compiler

<oriansj>on the other hand, the compiler becomes a simple pattern matcher which only needs you to resolve the types for (set! e (add (sub a b) (sub c d))) It is easy to figure out a->e's types; the problem is what type should the subs return as there are multiple return options available.

<oriansj>if I require the user to provide the types via (set! e (add (sub :UINT_32 a b) (sub :INT_8 c d))) it looks a little ugly but it does make it trivial for the programer to reason about rounding, truncation and other behaviors that might occur. [As the sub function used would be the only one which matches the name and all of the types]

<oriansj>the reader atleast is simple: https://git.sr.ht/~oriansj/bishop/tree/main/item/read.c

<oriansj>so should doable in only 200ish lines of assembly

<stikonas_>oriansj: is this to replace cc_* compilers?

<oriansj>stikonas: only if the result is worth the effort.

<oriansj>mostly an experiment in typed s-expression bootstrapping. What is the most powerful language we can implement with the least functionality needing to be written in assembly

IRC channel logs

2024-03-08.log