<Formbi>why isn't the default map tail-recursive? <civodul>Formbi: mostly because it's unnecessary with expansible stacks <civodul>they achieve the same thing as having an explicit accumulator <civodul>the downside is that backtraces with 'map1' are a bit ugly <chrislck>more memory in the stack, less memory in accumulator <Formbi>hmm, I think the memory consumptions should be compared <chrislck>plus, the accumulator will need to be reversed when completed. not so when using the stack. ***apteryx_ is now known as apteryx
***overclucker_ is now known as overclucker
*wingo has a design for cross-module inlining, whee <sneek>Welcome back davexunit, you have 1 message! <sneek>davexunit, manumanumanu says: I have been working on a wrapper around srfi-64 that implements a large chunk of (chibi test)... <leoprikler>Am I the only one, who finds it funny, that the reference implementation of SRFI 223 contains exactly the kind of bug they were supposed to defend against? <rlb>I'm wondering why something like string-append has to scm_remember_upto_here_1 the individual strings, i.e. how could we lose track of them if they're in the argument rest list? <rlb>(Asking because preserving that wrt utf8 strings might be a little more work.) <manumanumanu>leoprikler: It has been a long time since I implemented a binary tree (I have two implementations I wrote about 11 years ago; one functional and one imperative). Should it floor? Shold it add 1? I don't remember. <leoprikler>manumanumanu: (low + high) can overflow. This is typically not an issue in Scheme, because it just gets promoted to bignum, but the key is, that it shouldn't need to be promoted <leoprikler>rlb: the rest list itself – or at least parts of it – could be discarded as you iterate <rlb>I thought anything that was a C side argument was preserved throughout the call. <rlb>i.e. if we have foo (SCM x) { ... } anything referred to by x will persist until foo returns? <rlb>And since it's a rest list, no one should be able to destructively modify it to drop refs? <leoprikler>you can drop x if it's no longer on the stack at any point <rlb>At least in our docs: "Guile's garbage collector will automatically discover references to 'SCM' objects that originate in global variables, static data sections, function arguments or local variables on the C and Scheme stacks, and values in machine registers." <rlb>SCM is "function argument" in this case. <leoprikler>if you pass arguments through registers and the compiler decides that the argument is no longer used → boom <leoprikler>why else would the example have scm_remember_upto_here_1 (file); // file is an argument <leoprikler>the manual explicitly tells you, that this can happen <RhodiumToad>personally I'm not convinced that the gc can actually operate correctly in all cases, given the amount of freedom the compiler has <RhodiumToad>in particular the compiler can (and modern optimizers actually do) represent a pointer value by means of some offset <rlb>Yeah, I wasn't looking at that page -- and clearly I've misremembered part of the requirements. Though I still wonder about a rest list to a SCM_DEFINE, i.e. I'd have assumed that pointer is held on to throughout the call by the caller. <rlb>i.e. the code that constructed the rest list, but that might also just have been a vague incorrect guess. <rlb>Is it at least a safe assumption that a rest list can't be modified (from outside) during a call? <rlb>(I *think* that's probably true?) <RhodiumToad>you should probably assume that the compiler and optimizer will actively break things, and be as defensive as possible about it <rlb>because with utf8 strings, it'd be more efficient if we can compute the strinbuf offsets (start and end) for each string as we make the first pass in string-append and then use those to build the final result, than if we have to do that twice (if we can't assume things won't change) <rlb>(we have to compute the offsets in the first pass to get the total byte count -- similar to the approach for current strings) <leoprikler>how can you be sure that the strings themselves won't change between computing the offset and concatenating the strings? <rlb>Yeah, that's what I'm working on -- one option I was thinking of was to capture the stringbufs and offsets up front, and then traverse that. Since the stringbufs are immutable. <rlb>Of course if I do that, then some aspects of my other questions don't matter. <pkill9>dustyweb: how can I add a list metadata? with a quote? e.g. '("listitem1" "listitem2") ? <pkill9>hmm actually the nicest would be yaml