<dsmith>emestee: As in, not yet provided by a C library? Not sure. <dsmith>However A C prog might do it could possibly be done though through the ffi. Not sure. <flatwhatson>hmm, i can't seem to convince it to emit the SYS_ defines <tohoyn>xeno: could you explain the example to me, too? <tohoyn>xeno: I think I got it. The key is the continuation of the call/cc expression. <tohoyn>wingo: the corrected cumulative time counting in statprof seems to get some times wrong. I have a situation where procedure A calls procedure B but the cumulative time of A is smaller that the cumulative time of B. could you look at the code? <tohoyn>wingo: I also filed a bug about statprof not displaying call counts <wingo>could it be that B is ever called by not A? <wingo>or that A sometimes calls B in tail position and sometimes not? <tohoyn>wingo: if the body of the procedure A is (if B var1 (C ...)) is the call of B in tail position? <wingo>tohoyn: not in tail position <tohoyn>wingo: is it so that guile optimizes the tail position calls so that they do not have a stack frame? <wingo>yes, as required by the scheme semantics <tohoyn>wingo: it might be useful to be able to switch this feature off <wingo>unlikely to change in the near future fwiw, and in any case it is probably more useful to update your mental model of how scheme runs to incorporate tail calls <wingo>after all, you wouldn't want a backtract to include every loop iteration, and those are tail calls <dsmith>Scheme doesn't have "TCO". In Scheme *ALL* calls are actually jumps. However there *are* some exceptions, like when needing the return value, or in a sequence. <RhodiumToad>scheme explicitly distinguishes where tail position is and makes specific requirements about tail calls <leoprikler>yup, IIRC TCO stems from observations made in FP first <leoprikler>It's semantic in Scheme, it's not semantic in C/C++. <RhodiumToad>the specific requirement as stated in r7rs is that the number of active tail calls must be unbounded <RhodiumToad>that is to say, if you implement a loop via tail calls, it should not terminate unless something within the loop stops it for whatever reason <leoprikler>But C/C++ compilers will look for instances in which similar semantics are used to perform so-called "tail call optimization". <RhodiumToad>yes, if a function ends with return otherfunc(); then the emitted code may drop the current function's stack frame and jump to otherfunc <RhodiumToad>but this is not required by the language so it's up to the compiler whether it happens or not <topoi>What is the combinatoric problem called where you pick k from n elements in a list? <topoi>I could cut and filter permutations but this is profanely inefficient. <topoi>Ahh, it's called "k-permutations"? : ) <topoi>I often like to reimplement basic functions, but sometimes it's exhausting. : / <topoi>RhodiumToad: but without repetition resp. without put back. <lloda>variations (variaciones) is actually the name i'm familiar with <topoi>lloda: How familiar are you with them? :3 <topoi>I'm so desperate, I'll construct them soon from power-sets. :P ***dsmith-w` is now known as dsmith-work
<manumanumanu>topoi: I have some code that generates lexicographical permutations <manumanumanu>Maybe we should have some library collecting efficient versions of some maths procedures like that. We could model it after racket/math.