IRC channel logs
2026-04-26.log
back to list of logs
<rlb>jcowan: do you think it would be acceptable to have srfi-13's string-unfold(-right) behave the same as srfi-152's (i.e. include the superset mapper/make-final char/string support)? <jcowan>With the exception of the KMP stuff, SRFI 13 should probably just import and export SRFI 152 <jcowan>(oh, and string-tokenize, I guess) <jcowan>if you are going to share strings, then you can bring that over too <rlb>I'm making our (srfi srfi-152) export precisely what the srfi says, i.e. no tokenize. <rlb>Since you can always get it from 13 <rlb>Would it also be acceptable to allow all the relevant predicate-accepting functions continue to accept char-sets and characters? <rlb>(since srfi-152 doesn't include that) <jcowan>Extending argument types is always fine <rlb>Nice, then I think we probably do have an initial srfi-152. <rlb>And as you say, mostly via forwarding srfi-13. <rlb>I did add a C string-split, since it wasn't too bad, and I suspect that one may be fairly heavily used. <jcowan>Have you decided about sharing? To summarize: take, drop, pad, trim, and filter are allowed to share; copy is not; and (de facto) substring come in both flavors. <jcowan>Also, sharing is always allowed when the operation is an identity (e.g. append just one string) <rlb>I (at least) haven't yet, but I did switch string-split to share, and I might end up reworking some of the others to do the same. I just wasn't thinking about it much earlier; more focused on the utf8 conversion details (forest, trees). <rlb>If we did end up adding a completely in-line read-only string variant, and *if* there were some way to tell functions that's what you want, then that'd make them more efficient than sharing for smaller strings. <jcowan>Since you can't count on sharing, you might just as well make all short strings unshared. <rlb>iirc someone here had a tool for converting srfi html to texinfo? <ieure>Hi, I'm trying to make a macro which takes a list of symbols and expands into a sequence of defines, one per symbol. Context is, I want to create variants of Emacs packages in Guix without writing a bajillion lines of: (define-public emacs-whatever/native (with-full-emacs emacs-whatever)) <ieure>I am not having much success with this. <ieure>I wrote a macro which expands into a (begin (define-public ...)), one define per input symbol, but I get this error: definition in expression context, where definitions are not allowed, in form <ieure>How can I have a macro expand into a series of top-level definitions? <mwette>Can you show the code. It sounds like the defines are appearing somewhere they should not. <mwette>Use (begin (define a 1) (define b 2)). `let' won't (or shouldn't) work <ieure>And I'm calling this with: (dnev '(emacs-9lc-mode emacs-tl1-mode)) <ieure>define-emacs-native-variant works fine, define-emacs-native-variants does not. <ieure>I can't even see what these are expanding to. :/ <mwette>This is scheme: don't use defmacro: use syntax-case; don't use #nil. <mwette>You can see if you quote: `(,'quote ( <mwette>Oh, your macro is a little tricky. Is pkg supposed to be evaluated in the caller's environment? <jab>hey ya'll, I've been writing a functional-programming-ez blog post...Does anyone care to read/critique my current draft ? <mwette>ieure: It could probably be done in syntax-case by using (define-emacs-native-variant pkg-sym (interaction-environment)) <mwette>You can see what happens often by quoting the output of defmacro. <jcowan>'begin' in expression context (as opposed to top-level or library context) allows only expressions