jorkingit

A CRT - to name one - is a device whose actual understanding will challenge people in profound ways. To ask “how does a screen even work?” and to begin to answer this question will require a bit more than a stack of books of “the experiments and expectations and failures and theories as to why and how”. The history of this discovery is all of history leading up until that point and in and of itself is fascinating - the sociopolitical conditions and details of every single person's life and their astrological charts as to why and now. I suppose I just expect more of the site. Oh and my moniker is not a coincidence.

I was wondering how they managed to reflect the names of struct fields: looks like https://stackoverflow.com/a/77464529 explains the general idea. Where there's a will, I guess...

Smalltalk does the same thing!

Great work! Just an FYI, you might want to limit the dynamic allocation size in the bencode decoder: since it's untrusted input (either from torrent or announce), a malicious input could DoS the client by requesting extremely large allocations during string parsing. A good upper bound could be the remaining length of the input, as a well formed torrent can't contain a string longer than the rest of the file.

I suspect the answer is 3: SKI combinator calculus is Turing complete and you need 3 de Bruijn indices to define S.

Good call! I got rid of all numbers above 2, I can't count that high anyway ;-)

I did take some inspiration from Unlambda: the prefix application syntax is cool! I/O in Unlambda is super weird though! You get a read character instruction that puts it into a character register where the only thing you can do is compare it or print it out again; I don't think you can actually do any arithmetic on it.

I'm not sure if I would characterize Brainfuck as a stack language, but I suppose if you considered all the operators to be unary stack operations I could see it!

I saw this the other day! I salute you, it's so much more evil :-)

And yup, the order of evaluation is leftmost innermost.

  ``\\0`,.`,.

with stdin "hi" will print "hi".

It should be! e.g. if every function takes a continuation as its final argument, then:

  call/cc& = \f. \k. f k k

Then in f you can invoke the continuation k as many times as you want, but that does involve a whole program transformation to CPS.

You can always write it in continuation-passing style if you really want continuations! It's not pleasant but none of this is supposed to be ;-)

Agreed on having too many characters though, I don't like that having numerical indices makes the syntax whitespace-sensitive, too.

And once I figure out how to write hello world, those character literals are gone!

getchar does take a continuation of sorts (as in continuation passing) which is passed the input. In one my initial drafts, getchar was a special form that would accept input at the point of evaluation, which was really funny and unpredictable.

putchar I feel kind of weird about, it acting as an identity function with a side effect is kind of weird; I'm not sure changing it to take a second argument as a continuation would make it better or worse.

Regarding the de Bruijn indices, I don't think there's a huge distinction between writing 3 vs writing ---: it would still form a single lexical token, so I feel like --- is just more noise.

Perhaps a de Bruijn index register you could move around and dereference? e.g. from index 1, index 3 is >>*, then index 2 from there is <*. But that feels less functional, because you're now imperatively manipulating some hidden state.

Thanks! I'm torn on having the character literals actually; they're definitely syntactical sugar, but I was struggling to write programs that printed anything without them getting super unwieldy! If someone smarter than me can write a compact-looking enough Hello World program then consider them gone ;-)

Hello world should be:

  ``\\1`.'h``\\1`.'e``\\1`.'l``\\1`.'l``\\1`.'o``\\1`.' ``\\1`.'w``\\1`.'o``\\1`.'r``\\1`.'l``\\1`.'d`.'!