IRC channel logs


back to list of logs

<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
<vijaymarupudi>Whoops, sorry about that
<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
<apteryx>OK, neat. Thanks.
<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
<apteryx>but get-keyword is to the point :-)
<leoprikler>note that (let-keywords ) and lambda* are probably a better idea most of the times
<sarna>hey, will artanis work with guile 3?
<lampilelo>sarna: based on the title of this commit, yes:
<sarna>lampilelo: woo, great! who to ping so it's changed here?
<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>wingo: I don't know if you saw this, but if it gets some traction it could potentially be interesting:
<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.
<manumanumanu>sneek: seen 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.
<manumanumanu>sneek: seen civodul
<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>the docs claim it complies fully with r5rs
<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..
<flatwhatson>stick to the guile manual
<sarna>oh, okay. makes sense, thanks!
***ays1 is now known as ays
<rlb>info guile
<rlb>Heh, oops.
<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>taylan: I haven't caught up on all the nil related discussion, but though I'd mention this to make sure you'd seen it.
<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 only skimmed.
<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.