IRC channel logs
2024-09-03.log
back to list of logs
<morenonatural>may I suggest using `filter` or `take` as an alternative to discarding items from a list? perhaps `tfilter` or `ttake` <old>gabber: is it not 1 the problem, but simply the first element <old>(delete1! 1 my-list) will return (cdr my-list) without changing my-list <old>(delete1! 2 my-list) will remove 2 from my-list by changing the cdr of the first cell, thus mutating my-list <daviid>jfred: maybe you are a guile-user ml member and follow there .. let me know <gabber>old: but that's not how i understand the documentation. i thought delete1! "deletes the first occurrence of ITEM from LST" - which does not happen in my examples. so maybe it's a documentation bug? <gabber>morenonatural: filter and take are not really a replacement for delete <gabber>i have the problem where i roll 6 dice and some of them make up a combination. then i want to separate the 6 dice from the combinations. i can not just filter the roll - maybe only 3 ones are part of the combo and not all 4 and i want to "set them aside"; so deleting them from one list and adding them to another was the most intuitive way to achieve it <gabber>old: should i prepend my initial list with some element, run delete1! and then set my-list to (cdr my-list)? this feels pretty wrong <lloda>gabber: you should use the return value from delete! and forget about the argument <lloda>srfi-1 talks a bit about what these 'destructive' functions actually do <ArneBab>gabber: to "set them aside" the most intuitive function may be partition (from srfi-1). (import (srfi :11 let-values) (srfi :1 lists)) (let-values (((taken set-aside) (partition even? '(1 2 3 4 5)))) (list taken set-aside)) <old>gabber: The documentation says this about `delete!': Caveat evaluator: Like other destructive list functions, these functions cannot modify the binding of LST, and so cannot be used to delete the first element of LST destructively. <old>If you are mutating a top-level binding, then you can do: (set! my-list (delete1! 1 my-list)) <old>note that this won't work if passing your list as a arguments to a function .. <lloda>imo the doc IS confusing. These functions are meant to consume the argument to produce the result, not to modify the argument, bc as you say, a function cannot do that in general (on top of the other reasons given in srfi-1). But the doc somewhat presents the function as something that modifies the argument, but then it doesn't work sometimes. That's no good <lloda>doc should straight say: don't reuse the argument. <old>The doc does mentionned this with acons mutation I believe <old>Like, you need to do set! + assq-set! to actually mutate a variable <old>perhaps that ought to be explained like this for delete! and family <cpli>i remember an old sbcl project that allows you to make use of simd; is there support for any form of inline assembly in guile? <cpli>correction: i would even enjoy unsupported forms. <dthompson>inline asm could come into play if guile gets native compilation someday. hoot has an inline wasm form, for example. <cpli>how does the dlopen/foreign extension jump into loaded shared objects? if i can't do it right, i'll do it cursed. <cpli>oh, i thought lightening was native comp <dthompson>if it was aot compilation then inline asm could be an option. I'm curious if guile would want to expose such a thing, though. inline wasm is different in the sense that it's not specific to a single cpu architecture. <cpli>i guess there's wasm simd at this point <cpli>so that would "solve" my problem too <dthompson>guile doesn't do anything with simd as far as I know <dthompson>even for wasm which only has a subset that is supported well enough across all major architectures <Arsen> 20:52:37 <dthompson> it is... but it's for the jit compiler <Arsen>that doesn't preclude an always-jitted fn with inline asm really.. but the whole concept seems messy <dthompson>would be nice to have simd optimizations when necessary, though. <dthompson>might need to pay someone good money to deal with that though ;) <Arsen>not if one links libgccjit in ;) <cpli>eh, i was thinking of using simd to write well-performing mesh optimization in guile, but at this point i'm thinking about maybe just using a compute shader if the mesh is large enough anyway <dthompson>I've done plenty of graphics stuff without needing simd, so you can probably go a long way too