<lampilelo>it would be possible to create a system on top of srfi-37 for that, use a swappable dispatch in option processors and switch states, you'll have a layer of indirection and some options in some state could throw errors while others would behave differently depending on the state <lampilelo>or you could just (let ((var #f)) (args-fold ...)) and set the var to whatever and use that in the processor for some other option if that's what you want <stikonas>RhodiumToad: figured out my problem, turns out I had to adjust boehm gc CFLAGS for musl libc... ***iskarian is now known as Guest5039
<apteryx>lampilelo: indeed; the fold-args seem like it'd provide the most flexibility. Thanks for the hintsights. <apteryx>how can I get the keyword value from a list? (assoc-ref '(#:something value1 #:more value2) #:more) doesn't return 'value2 <apteryx>hm,m not assoc-ref because it's a plist, not a alist <daviid>apteryx: get-keyword, from (oop goops) <daviid>apteryx youmay just importthat proc if you don't want to import the all (oop goops) module <flatwhatson>apteryx: memq returns the pair, so you could (memq elem plist) and then car is key, cadr is value <apteryx>right, (and=> (member #:my-key the-list) second) would work too <leoprikler>note that (let-keywords ) and lambda* are probably a better idea most of the times <sarna>hey, will artanis work with guile 3? <ft>Isn't that page based upon the packages in gnu guix? <ft>And the guix package still depends on guile 2.2; so probably that. <leoprikler>so we ought to get guile-artanis bumped to the 3.0 version :) <sarna>oh! hmm. no idea what the workflow is here haha ***dekenevs is now known as kitzman
<xiews>sarna: there is a branch for guile 3.0 in artais. <manumanumanu>I believe I saw your name in the old R6RS mailing lists, and given your current position it seems like it could be directed towards you and ludo. <sneek>lloda?, pretty sure was seen in #guile 4 days ago, saying: erc didn't tell me anything, my chat window looked as if the messages were getting through, but they weren't. <sneek>I last saw civodul in #guix 15 hours ago, saying: nope. <sarna>which revision does guile support by default? r6rs? <RhodiumToad>it's not quite compatible with either r6rs or r7rs by default <RhodiumToad>there are options --r6rs and --r7rs that switch various defaults to be as close as possible to the specified revision, but not all features are implemented <sarna>RhodiumToad: what would you suggest for a beginner to stuck with? the default? <sarna>then I'd need to be reading r5rs docs, I've been reading r6rs - hmm.. <sarna>oh, okay. makes sense, thanks! ***ays1 is now known as ays
<manumanumanu>sarna: guile is pretty compatible with most r6rs code out of the box. <manumanumanu>i had a bunch of pure r6rs modules before starting guile, and they all ran without problem <manumanumanu>however, guile code is not r6rs-compatible by default. You have to limit yourself to r6rs, either usirg --r6rs at the command line or (install-r6rs!). <rlb>(and the discussion of equality, etc.) <taylan>rlb: yeah, I know about it. if I'm not mistaken, nothing in it contradicts the idea that #nil could be made equal? to () in Scheme to make sure equal? works for comparing Elisp and Scheme lists. <taylan>it would however cause the weird situation that a false object is equal? to a true object, and I guess that would be very surprising. <taylan>although as surprising as it seems, I'm not sure whether it would cause any issues in practice. <rlb>Would it break transitivity? If so, that might be a hard restriction. <rlb>i.e. that's what the info page seems to imply? <rlb>I can consider it more carefully later... <taylan>rlb: if you make #nil equal? to both () and #f, but not make () and #f equal?, then it breaks transitiveness. if you make #nil only equal? to (), then it doesn't break it. <rlb>Yeah, I was thinking more about "truthiness" than equality, and agreed, having two things be equal? but one "false" and the other "true" doesn't, offhand, seem plausible to me. <sarna>thanks manumanumanu! "mostly compatible" sounds good enough for me haha <rlb>wingo: hmm, I just tested against current main (i.e. past 3.0.7), and I'm not sure, but it's looking like whatever has changed since then may have fixed the #nil issue with lokke. If so, we may be able to ignore and/or close that bug I filed. However, now it's crashing further on, when trying to compile a clojure file: <rlb> ice-9/boot-9.scm:1685:16: In procedure raise-exception: <rlb> Unbound variable: make-struct/no-tail <rlb>...I just randomly wondered if there's any chance that might be because the lokke namspaces are #:pure.