IRC channel logs
2023-10-08.log
back to list of logs
<old>Is someone working on a SRFI-165 ? <rlb>old: not that I know of, but for now you might consider avoiding string mutation if you can -- if we move to utf-8 things like string-set! may become notably more expensive. i.e. you'd favor building new strings via string-map, string-tabulate, string-join, string-append, etc. <old>rlb: okay thanks for the head up! <old>why is string mutation expensive with utf-8 btw? <old>I do not know the internal details <old>but I could read a patch if you have one to understand <rlb>No worries - it's in large part because utf-8 is a variable-length (multi-byte) encoding, i.e. each character might encode to one, or more bytes, up to four (now). ASCII chars are all still one byte. cf. https://en.wikipedia.org/wiki/UTF-8 <rlb>So if you have a long string and change an #\x in the middle to #\λ, you'll need more room. And if you use a contiguous byte array, you'll have to "make room" somehow. (Other data structures for strings like "ropes" are different, but have other tradeoffs.) <old>This is due to the nature of flat array of string internally <old>you would not have this probleme if string were implemented with a rope datastructure I guess <old>or something like similar <rlb>The utf-8 work I've currently proposed does preserve (roughly) linear time access (string-ref, etc.) by using a sparse index. <rlb>But modifications still take linear time (in general). <old>What if you know the string is ascii? <old>say: (make-string "foo" #:encoding 'ascii) <old>then mutation is constant like before <old>or does all strings now have utf-8 encoding? <rlb>That's the "in general" part. Right now there are some places where the code might still modify ascii in place, but I'm thinking of dropping that, and so stopped adding it as I converted functions. It's notable extra complexity, both code-wise, and mentally wrt semantics/expectations. <rlb>well, "any ascii string is a utf-8 string"? <rlb>...utf-8 has a few clevernesses like that -- all 127 ascii chars have exactly the same one-byte encoding in utf-8. It's also true that the number of leading 1 bits of a utf-8 encoded char's first byte tell you how long it is, etc. <rlb>(That article should cover most or all of it.) <rlb>RhodiumToad: ...wrt the syntax-parameter loop/recur, it might well be used by clojure-side code creating macros via clj defmacro. Have to evaluate that once I understand it better. <RhodiumToad>but presumably clj defmacro isn't expected to be hygienic? <RhodiumToad>in particular if a clj defmacro introduces a (loop ...), it doesn't expect a (recur ...) form inside that loop to invoke the caller's recur rather than its own, correct? <rlb>It definitely does (practially -- tested) if you rebind recur via a let, say. <RhodiumToad>i.e. (mymacro (stuff (recur ...))) where mymacro expands it to (loop ... (stuff (recur ...))) <rlb>Wrt hygene, not specifically, no. It has its own gensym sugar "x#", and it automatically "expands" symbols to include their namespace in the resulting form, i.e. `(cons 1 (list 1 2 3)) becomes (clojure.core/cons 1 (quote (clojure.core/list 1 2 3))) <rlb>And depending on exactly what you mean, not sure what it actually does on the jvm, for a given case -- and I don't mention what it specifies, because I'm not sure how well that's documented. But good questions, and worst-case I can test if I need to. <rlb>Anyway, thanks - I might play with it later. <RhodiumToad>I guess the thing to do would be to compare the macro expansions in both environments <rlb>yep - lokke does some work at the tree-il level and so I had to get at least a bit used to it. <RhodiumToad>the expansion viewed that way may have some symbols renamed in order to preserve the hygienic effects <RhodiumToad>so you can see what symbols were considered to be equivalent and which were not <rlb>Also need to figure out both what clj(/jvm) currently does/expects, and/or what I think it reasonable/preferable :) <lilyp>note that tree-il->scheme can confusingly work against you <rlb>Do we already have any helpers for creating the commit message bookkeeping, we expect, i.e. the per-file entries? If not, I might poke at it if/when I need to finish up the utf-8 series if I can figure out anything plausible. That's going to be a good bit of work. <rlb>(I tried to create fairly good commit messages, but don't have any per-file info yet, and there are a lot of patches.) <rlb>Hmm, I guess I can just use C-x 4 a to build (disposable) top-level changelog entries, and then adjust those for the commit message. A script/command using git diff-tree etc. to build an initial draft would be faster, but without possibly notable work, wouldn't capture function names correctly, etc. <rlb>Oh, though C-x 4 a doesn't get the C names right either, anyway -- i.e. just gets SCM_DEFINE. OK. <rlb>wingo, civodul: if the commit message prose fully explains what happened, then could it be plausible to just have something like "see above" or nothing after the relevant path at the end, rather than coming up with some redundant text? No worries either way, just wondering what's required. <graywolf>Hi, quick question, how to I list all defined symbols in current module? I am looking at 6.18.8, but do not see anything. <graywolf>Description of resolve-interface sounds right, but does not seem to accept (current-module) <graywolf>(I technically care only about public bindings.) <spk121>graywolf: there is a (module-for-each proc module). proc takes (symbol variable). So something like (module-for-each (lambda (s v) (write s) (display " ")) (current-module)) <spk121>but I'm in the middle of a hack so my guile is broken, so I didn't test this <graywolf>Yes, that works nicely, thank you very much :)