IRC channel logs
2026-04-19.log
back to list of logs
<rlb>old: if we haven't already I do think we should formalize a "private" syntax for perhaps both bindings and modules, e.g. maybe any %_* binding is subject to change or removal without being considered a backward incompatibility, and any module whose leaf name starts with %_ (or something) is also "subject to change/removal", and allows breaking changes to exports. <rlb>old: I also think that steal-bindings! trick means we can fairly easily have the module/ modules backed in part by libguile/ SCM_DEFINES that I wanted. We just need to use that to shunt the SCM_DEFINES to a (foo internal) at the end of boot-9, and then use (foo internal) from foo. <rlb>If so, I think I may wish I'd figured that out before some of the srfi-13 work :) <rlb>old: yeah, that works just fine. Added a simple SCM_DEFINE string->vector to libguile, then shunted it to (srfi srfi-152 _libguile) in that section at the end of boot-9, and re-exported it from there via (srfi srfi-152) --- nice. <old>rlb: this is great. It oughts to be a little bit more documented I think :-) <mwette>ACTION is trying to put guile extension inside the wlroots demo compositor tinywl. <lechner>Hi, is there anything that can turn a record into alist? <identity>seriously, i do not recall Guile having that built-in <lechner>identity / okay, thanks! i guess i was looking for something like hash-table->alist from SRFI-69 <rlb>old: r6rs-ports.c along with binary-port.scm also shows the cleaner way (where you just can have some of the module's functions provided by C in libguile --- without ever showing up in (guile)) via scm_c_register_extension, but iirc some cases like srfi-13 were "too early" in the boot process for that (unless I misunderstood last time). <rlb>(In any case, I'll keep all this in mind as I work on utf8.) <rlb>It seemed likely --- and note that get-string-n! is being provided from C (r6rs-ports.c). <rlb>That also made me wonder if the wrapper *is* intended, then did we mean to add scm_get_string_n_x to the pubilc C API without it. <lechner>Hi, what's a good way to avoid imported module (scheme base) overrides core binding `error' please? <rlb>You can rename it during import, or #:hide it, or switch to only #:select-ing the bindings you need. <rlb>i.e. (use-modules ((foo) #:hide (bar ...))) <rlb>(use-modules ((foo) #:select ((bar . baz) ...))) ;; renaming <rlb>(use-modules ((foo) #:prefix foo/) ...) <rlb>(These days, for anything "notable", I prefer the clj convention of never importing all symbols, i.e. roughly always use #:select. It's of course a bit more work once, but more than worth it to me for the longer-term visibility and insulation from any future additions.) <jcowan>I agree within limits. In Scheme, if something is part of a library required by the standard, I'll import it wholesale, but from an implementation or 3rd-party library I'll only import what I need. <rlb>Oh sure, it still "depends" (e.g. on whether I think the bindings are "fixed" -- presumably srfis(?)), though my bar's pretty high these days since I just don't mind it that much, and regularly appreciate the benefits. <rlb>I suppose I'll propose a patch adding those rnrs wrappers for consideration either for main or in utf8. <rlb>I noticed them while trying to sort out all our various read-string/get-string-* functions across several modules, while trying to adapt them for the "avoid string-set!" regime. <rlb>Also trying to remove some duplication --- e.g. completely parallel implementation of read-string in (ice-9 rdelim). <rlb>The semantics are only a tiny bit different, and so one of those should be based on the other, and that one should be efficient. <rlb>Probably said this before, but as often as I've been running the tests, I'd be quite happy if someone were motivated to make web-uri.test faster (if possible). <rlb>(Hmm, suppose I could just remove it locally sometimes.) <rlb>I think our get-string-* have additional issues --- main one is that rn6rs-ports.c get-string-n! implements rnrs semantics (returns eof-object when there's nothing to read), but (ice-9 textual/binary-ports) returns "" for say (read-string port) and get-string-all. Since we just pass those through via (rnrs io ports), they're wrong there. <rlb>Oh, maybe I can just fix it --- I'd assumed that was historical (pre rnrs), but it looks like we document the rnrs behavior for textual-ports, so just bugs. Nice. <JohnCowan>using the inyrispecyion library will make it straightforward <rlb>hmm, don't know that <rlb>(don't know what that is) <jcowan>That's the trouble with posting from my phone, I tend to cut corners instead of looking things up.