03:24 <rx_> ; Discard the request header (up to blank line): (regexp-match #rx"(\r\n|^)\r\n" in)

03:24 <rx_> why is that not just \n ?

14:49 <zgrep> If I'm recursively making a list with a bunch of cons-es, just out of curiosity, how efficient does it end up being space-wise? Does it initially make build up a chain of unevaluated expressions, and then build the list as it evaluates them? Would the chain take up more space than imperatively making a list would? (Assuming I can make the list in either direction, I guess.) Or does the Racket interpreter try to do clever things in

14:49 <zgrep> certain situations?

15:30 <Don8742> I have multiple versions of Racket installed. Is there a function or setting that enables me to specify a previously installed version of racket to be the current version?

18:32 <aliasless> zgrep: that depends on the nature of your recursive function, if its using linear recursion it has to reach the base case before it evaluates, so each call of that function will take up space. rewriting it to be tail-recursive would give you the space optimization you are looking for

21:32 <zgrep> aliasless: Mmh. That's a fair point, and I'm not sure why it didn't quite register as a possibility earlier (even though that's been pointed out to me in the past).

21:36 <zgrep> Now I'm wondering if the tail-recursion benefits work across functions, say a calls b and b calls a, each in a tail-recursive fashion. I don't see a theoretical reason why it shouldn't be possible, but what happens in reality?

22:08 <aliasless> as far as I understand tail calls aren't specific to recursive functions

23:02 <ski> zgrep : yes, it's required