IRC channel logs
2026-02-18.log
back to list of logs
<rlb>I think that might be useful on the C side for cleanup in cases where we don't want a full unwind handler. I'm pretty sure I'd want to use it in the utf-8 work. <rlb>I guess what we'd really end up wanting is probably just a "defer" feature requirement with suitable configure.ac detection --- *if* we decide we're interested. And not sure whether that would effectively mean "just gcc/clang" for now. <dsmith>rlb, Would that also be a required compiler for the c-must-have-real-prototypes-no-more-K&R-empty-ones patch? <rlb>I'm guessing not? I don't know if we have other restrictions, but I think the main one right now might just be c99? <rlb>I suppose I don't know, but for the current incompatibility I think maybe all we need is C23 (gnu23) support? <dsmith>ACTION is not up-to-date on recent C standards <rlb>defer's "separate", not part of a CNN standard afaik <rlb>That article does suggest it's part of a spec now, though... <dsmith>It looked similar to something in that no-empty-args change <rlb>I assume we'd mostly use it for error handling/cleanup, but might be handy for that e.g. { defer if (something) free/unlock/whatever(x); }. <identity>we can just wait 5 years for POSIX.1-2031 (or something) to release that will have a recent C standard attached <jab>I'm still on the functional programming paradigm thought train...are there any notable examples of programs that use functional programming? I know that guix does when interacting with the store. I'm starting to think that functional programming is not worth it... <jab>mainly because I see soo few examples of people using it. <ekaitz>jab`: guix tries to be functional <sneek>Welcome back ekaitz, you have 1 message! <sneek>ekaitz, efraim says: it is a shame about non-inclusive language in the Spanish translation. I remember we once had someone come in an complain about the inclusive language there and said it was off-putting for them. My wife and I still joke about needing "manly-man" translations and things <old>sneek: later tell jab that the BLUE build system tries to be purely functionnal as much as possible <old>sneek: later tell jab that BLUE wents a to great extent to be able to represent stateful data in a purely manner with delayed expressions. This allows changing the states in the REPL for example without doing any mutation <old>sneek: later tell jab, for example, you can change where something will be installed, without having to mutating the object itself <old>hope sneek has a stack <dsmith>old, They are delivered in order <jab>old: I didn't realize that BLUE was using functional programming. That's fairly cool. <dthompson>guile's compiler uses a lot of functional programming <dthompson>if you look around, you'll see functional programming in many places <rlb>jab: as mentioned many clojure programs/servers/etc. are "much" functional --- often, for example, much of the state is just one or more persistent maps, updated atomically either via recursion, or via (mutable) atomic swaps. <rlb>(agents (and transactions / stm) tend to be rarer I think) <rlb>You can implement that sort of thing in guile, though you'd also need the persistent maps (or similar) for it to be as natural (without expensive deep copying) <rlb>lokke builds atoms on guile's atomic boxes (compare and swap, etc).