IRC channel logs
2025-04-15.log
back to list of logs
<trannus_aran>what's the consensus (or at least majority opinion) on how to handle generic functions? Dispatch on keyword á la SICP Ch2.5, some CLOS-like system, some sort of dispatch on record type identity functions? I just wanna avoid a situation where I paint myself into a corner with essentially duplicate functions for each variation of parameter type combinations <ArneBab>trannus_aran: if you want variation of parameter types, GOOPS is the way forward. It does have a bit of overhead, though, if you have very many types.. <trannus_aran>hmmm I wonder if there's anything in the running for r7rs-large <trannus_aran>yeah, sounds like dispatch on record type is the most..."schemey" way <old>ArneBab: I tried the skynet benchmark on guile-parallel with a naive implementation of channel <old>ArneBab: not sure what the result meant, but 4: Result: 499999500000 in 7.796670302 seconds, speedup of 0.046859283110417205 <rlb>ieure: I suppose chain is roughly a fancier as-> <trannus_aran>I swear, call/cc is just like quantum computing in that I only understand it for about 10 seconds after I read an explanation of how it works... <trannus_aran>Like I know it sorta takes a snapshot of the current state of execution that you can then invoke later to come back to, but I can never remember how the API works <lechner>Hi, does read-line! (with an exclamation mark) now require a third argument? I have to specify (current-input-port) otherwise I get https://bpa.st/GESA <ArneBab>old: that result would show that it’s about half as fast as the current implementation. *but* the skynet benchmark is a pure overhead benchmark: how much time does it take to spawn one million fibers and aggregate their results. <ArneBab>old: (though it’s not really comparable, because you have a different computer than I have, so you’d have to run both versions and compare) <ray1729>trannus_aran: I have the same problem with call/cc but I remember the coverage in "The Seasoned Schemer" being enlightening. <lechner>Hi, what's a good way to think about #:continuable? exceptions? The manual text is confusing me. Thanks! <old>lechner: When an exception is thrown, the handler can either be called after or before the stack is unwound <old>With continuable exception, the handler will resume the execution of the program at the point where the exception was raise if the stack was not unwound <old>With non-continuable exception, the handler can not resume the execution of the program even if the stack is not unwound. Trying to resume a non-continuable exception will raise a non-continuable expection from your handler <old>the first form will print ;; (foo) <old>the second will throw a non-continuable exception because we tried to return from an handler where the exception was non-continuable