IRC channel logs
2026-04-20.log
back to list of logs
<rlb>So, it does look like we either have to have two not exactly the same read-string implementations, or we have to break (at least) the tests. (ice-9 rdelim) read-string doesn't specify anywhere, but it returns "" when count is not 0. It also has a bug in that it'll lose one character when the count is 0. But rnrs specifies that read-string, get-string-*, etc. should all return eof-object, not "". <rlb>So right now (scheme base) is wrong because it indirectly relies on (ice-9 rdelim) read-string. <rlb>And so is get-string-n <rlb>Since we'd never documented the (ice-9 rdelim) behavior there, and we did document the others, we could consider just changing rdelim's to follow the standard, but wondering, I tried that, and we to in fact have rdelim.tests that break when it returns eof according to the standard... <rlb>So the conservative (and potentially confusing) thing to do is to just have two read-strings with different behavior :/ <rlb>old: ^ let me know if you have a preference (we of course have more leeway if we were only going to fix it in utf8). <jcowan>If there's no documentation, you are just as entitled to change the tests as the implementation, or indeed both. <rlb>Oh sure, we'd be "within our rights" --- still want to think about what the practical impacts might be, if any, and if we can tell (i.e. might shouldn't change rdelim's version if a lot of existing code depends on the behavior). <rlb>Could end up deciding just to make the documentation very clear on both sides. <rlb>Though of course I'd prefer, all else equal, to just have the one standard version if we can. <jcowan>That's a problem with fixing any bug: some people are depending on the buggy behavior. <jcowan>It's my problem with semantic versioning in general: all changes that have user-facing effect need to bump the major version, except if we did that your typical app would be version 32767.0.0 <apteryx>do we have something builtin in Guile to reflow text to a given width? aka `fill-paragraph' in emacs <apteryx>I see there's (fill-paragraph str width #:optional (column 0) in (guix ui) <old>apteryx: there's some helper in texinfo module IIRC <rlb>...longer side-track than expected, but I think read-string, get-string-* and get-line are fixed up now in utf8 with respect to the standards, and only have one simpler or faster implementation each. We do keep the dueling read-strings (rdelim vs (scheme base)) since they're just fundamentally different, though they also share most of their implementation. <bjc>is the guile stack trace most recent first or most recent last? <rlb>should be last (innermost) I believe, if you mean what it prints to stderr <old>rlb: for internal bindings, I would suggest to define them internally within wathever that is public and using it <old>See the make-exception and raise-exception stuff for an example <old>I've only glance at the above commit, so I might not have understood the policy you are suggesting here <rlb>I'm not sure I follow you --- also note here, that they're "internal" to guile itself, but they have to be shared across more than one module. <rlb>depending on what you mean. <rlb>The syntax is for things that can't just be hidden inside a module. <old>wrt: REVIEW: Is the naming policy OK, and is a leading underscore the right mREVIEW: Is the naming policy OK, and is a leading underscore the right marker? I'd also like to add some documented syntax for internal-only bindings, like we have with scm_i_* in C.arker? I'd also like to add some documented syntax for internal-only bindings, like we have with scm_i_* in C. <rlb>And modules that have bindings that have to be shared "internally only". <old>by sharing internally you mean <rlb>That commit only needs the "internal module" bit, not the "internal only binding" bit, though. <old>Module A is using binding from B. B is exposing symbol S that is meant to be used only by core Guile not by user of module B ? <old>is that what you are saying?/ <old>ah okay I see NEWS that's the missing rationale I was looking for <rlb>Cases where module A is using binding S from B, and S is "internal only", i.e. other guile modules can use it, but we reserve the right to remove or change its behavior in any release, even "bug fix" releases. <old>so you want to put all internal bindings into "internal modules" <old>instead of public modules exporting internal bindings <rlb>No, just want each of those options, as tools. <rlb>i.e. what might be suitable could "depend". <old>I wonder if Scheme does have some rule about reserved identifier names <rlb>Those are just two things I've recently wanted when working on utf8. <old>for example, C explicitly tell that any identifier starting with __ is reserved for the toolchain IIRC and _ for the standard <old>I'm surprise Scheme does not have such a rule <rlb>I don't know of any. For module names, I think it's a touch easier, since we completely control that (and I also think we should officially reserve at least (ice-9 *) and perhaps (guile *) too. <rlb>For bindings, you could argue that to be safe we might want something even more unique, like the scm_i_ we have in C --- __guile-... or dunno. <old>well we already have some third-party lib that have taken ice-9 ... <ieure>Most Lisps are such open systems, they don't reserve things like that. <old>e.g. (ice-9 colorized) <rlb>I think we should reserve something (even something new) so that users know what to avoid, and we can be sure we're not going to break backward compat more easily. <rlb>i.e. why *wouldn't* we want that. <dsmith> There are conventions, but nothing "reserved". <rlb>OK, well just my inclination. <old>well by reserve we mean not enforcing anything <rlb>I'd be in favor, but I think the module and symbol naming strategies are more important. <old>Just, it might break and you've been warned <old>fine. I don't very much like the _ prefix tho <ieure>// (define total-hours-wasted-here 25) <old>too much C for me. the proper prefix would be %, but since many public binding are using it, e.g. %load-path .. I am not sure <rlb>Oh, I don't care about the color of that shed at all -- just had to pick something to start the discussion ;) <rlb>I also suspect that *some* people intended for %* to be this, but it's clearly not always private. <old>058e5437-56dc-46cc-953b-09862ac2de46 <rlb>We could also just say that any module whose leaf name is "internal" is internal. That would work, but might be less pleasing/flexible in some cases. <dsmith>Could be really nasty and have a prefix like "guile-internal-only-" <old>for module, I would make a sub-tree internal for this I think <rlb>I also don't care whether we reserve (guile ...), because I'm just fine with (ice-9 ...), but I thought some people weren't fond of it. <ieure>I like the leaf-internal package idea myself. <old>I used to do that in guile parallel: (parallel internal io) -> private <ieure>rlb, ice-9 is completely baffling for new users. <old>user are meant to use (parallel io) no the internal module <rlb>It's in the info index now ;) <old>for bindings that are privated but exported in public module, I guess that a simple %guile-internal- is also good but too verbose perhaps <rlb>Sure --- suppose I don't mind the touch of potential mystery there, given that the meaning comes from an excellent source I'd be happy to learn about as a result ;) <old>I remember that when I first started playing with Guile sometime 5-6 years ago, I avoided using ice-9 thinking it was third-party stuff <old>either our documentation is terrible in that respect or we need proper (guile) module for new users <rlb>The docs are pretty clear about some of the cases where you should use it. <dsmith>I mean, if it's *really* verbose, no one will want to use it anyway. <rlb>And anything undocumented in ice-9 probably *should* be avoided. <rlb>old: OK, so how about any module named internal, or with an internal "parent" is internal? That'd be pretty flexible, and clear. <rlb>i.e. (foo internal) and (foo internal stuff) are internal. <old>anything under that, you have been warned it will break on your face anytime <rlb>Sure, that's another variant, but it'd mean splitting some modules across two trees. <old>we still need to be careful ourself wrt to cross-module inlining and stuff like this, but user should not use anything under that <rlb>I'm fine with either. <old>wathever fits best the mental model you have for the module tree <old>(guile strings internal *) for example <old>(guile bytevectors internal *) <rlb>And I'd extend it to say the policy applies for both ice-9 and guile. <ieure>Wondering how terrible an idea it'd be to have module-private behavior, ex. if (foo) uses (foo internal), that works like a normal module, but if (bar) tries to use (foo internal), that either fails, or all symbols are considered unexported. <rlb>My general inclination is to favor recommendation over enforcement for that kind of thing. <ieure>The second suggestion is kind of that. (bar) could still do (@ (foo internal) whatever), but (use-module (foo internal)) wouldn't intern new symbols into the using module's namespace. <rlb>i.e. (optional) warnings would be nice, and I might well want those, but I don't feel inclined to try to bake in some kind of java/c++/strict-privacy. <rlb>Though I have (in lokke) used, and was happy with (@@ ...) access for some truly private things. <rlb>But it sounds like that's not advisable wrt optimization/inlining now. <rlb>old: and regarding the bindings, I suppose we could could just pick %scm-i-* and be done with it. Not pretty-either, but very easy to explain to anyone already familiar with libguile... <rlb>Though I guess that on the scheme side, using scm is a bit "bolder" with respect to the broader scheme world, than it is on the c side, so could go with %guile-i- or whatever. <rlb>As long as it's not too generic, I doubt we'll really ever have trouble, and so I'm not all that particular about exactly what we choose, except that I'd prefer it not be "too long". <dsmith>It echos the C internal convention <old>rlb: as long as it's consistant and easy to grep <rlb>If it's feasible I'd be tempted to go ahead and establish the policy in main, i.e. even potentially in 3.0 if we have another release. Doesn't hurt, there was just no official option before. <rlb>And then we can "get started" --- would also need to be clear that this is an affirmative case, i.e. if it's in an "internal" module, or is named %guile-i-*, then it's private. Otherwise, may or may not be (status quo). <rlb>Since we're not going to retrofit :) <rlb>old: we also don't have to adopt that boot-9 hash-map change in main --- what we have right now does work, it's just a little sketchier. <old>I think it's fine if we cleanup this also <rlb>OK, well I think I'll want to adjust it wrt what we just discussed above before we decide to merge anything. <old>your change is more grepable for me <old>the hash-table stuff <old>It's easier to find the definition and understanding the provenenane of the bindings with your change <old>vs the scaning of boot-9 with hash-table .. <rlb>It's what I should have done in the first place if I'd realized I could :) <old>but go for internal module and%guile-i ! <rlb>OK, I'll update the commit with the new internal policy, and then I can merge it, assuming that's what you meant. <rlb>And thanks all for the help. <mwette>This is all to allow change in internal API between minor releases? <rlb>And to allow us to name things without (or with less) worry of collisions, etc. --- e.g. the %guile-i- prefix. <rlb>Just removes some things to have to worry about when working on guile, no matter what rlease it ends up in. <mwette>OK. I was thinking about the lib/guile/3.0 files. You can change internal API for 3.0 to 3.1, but not for 3.0.9 to 3.0.11. Right? <rlb>(and allows more structural/organizational flexibility wrt modules --- i.e. there's a clearly documented way to share "private" things among, for example, otherwise "disjoint" modules) <rlb>Well, with this we could in fact *maybe* drop %guile-i-* bindings in a Z release. <rlb>(depending on "other things", i.e. if we'd captured them in or own macros, perhaps not) <mwette>Macro calls from a client module will capture the internal *value* of a binding in an internal one, using the extended name (@@ (foo) bar). <rlb>We could also completely remove or relocate a (foo internal bar) module. <rlb>OK, well, I should probably have just left it at "depending" off the to of my head ;) <rlb>But this at least leaves the option open to us if we decide it's "safe".