IRC channel logs
2021-07-11.log
back to list of logs
<marusich>Does "map" guarantee stability of the list order, even though it does not guarantee the order in which the procedure is applied? <marusich>That makes sense. I also see that R5RS says as much on page 32: "(map proc list 1 list 2 . . . ) / library procedure / The lists must be lists, and proc must be a procedure taking as many arguments as there are lists and returning a single value. If more than one list is given, then they must all be the same length. Map applies proc element-wise to the elements of the lists and returns a list of the results, in order. The dynamic order in which <marusich>proc is applied to the elements of the lists is unspecified." <RhodiumToad>put another way, (map (lambda (e) (pk (1+ e))) '(1 2 3)) is guaranteed to return (2 3 4), but it will also print out three diagnostic messages in some unspecified order <chrislck>marusich: map-in-order offers such guarantee <marusich>I did see that. Thanks for mentioning it. My hang-up was the fact that the stability was not explicitly mentioned in the Guile manual, but R5RS and common sense says it's so. <RhodiumToad>map guarantees the correspondence between input and output sequences but not the order of procedure calls; map-in-order guarantees both <RhodiumToad>the difference should only matter if the procedure has side effects <chrislck>and par-map is even worse in ordering of procedure calls :) <RhodiumToad>presumably that doesn't even guarantee that executions of the procedure are not overlapped? :-) <leoprikler>Is there some Guile function to iterate over differently-sized arrays? <leoprikler>I have a 3x3 matrix and a 3x1 vector, that I want to put together into a 3x4 matrix <RhodiumToad>you could do it with array-index-map, but maybe would be better using array-copy! and shared arrays <RhodiumToad>basic idea is: create the result array with make-array, then array-copy! into appropriate regions of it defined using make-shared-array <leoprikler>I've used array slices plus match-let, because the indexing was the important thing for me, but for memcpy-like behaviour obviously your solution is the better one <leoprikler>quick question though, would this also work with array-cell-ref instead of make-shared-array? <leoprikler>I suppose make-shared-array is more generic, but it's also a pain to write oftentimes ^^" <RhodiumToad>array-slice is more limited in what it can do, it can only fix the values of an initial subset of indices <RhodiumToad>whether it's enough for you depends on the shape of your input arrays <drakonis>hmm, how do you detect a language for guile to use on runtime? <ft>you mean (current-language)? <ft>But for that you kind of need to know the language already. :) <leoprikler>drakonis: Is this about selecting a language for a file or about knowing which language is currently used? <ft>Doesn't seem like ‘current-language’ is bound in elisp mode in any case. So it wouldn't even help with syntactically similar languages. <jlicht>How can I use srfi-1's `remove', instead of the 'default' `remove'? <rlb>There's a default remove? <rlb>Regardless, you'd typically just add a "#:use-modules ((srfi srfi-1) #:select (remove))" or "#:use-modules (srfi srfi-1)" (if you want everything) to your define-module form. <jlicht>rlb: no, there is not XD. I got very confused somehow, but your snippet still helped. Thanks! <jlicht>any Scheme-ish resource on how to compute all possible distinct covering partitions of a list? <jlicht>so e.g. (my-cover '(1 2 3 4) #:size 2) ; => '(((1 2) (3 4)) ((1 3) (2 4)) ((1 4) (2 3))) <jlicht>I know how to get all combinations, but not 'grouped' by them covering the entire original list <rlb>wingo: I pushed the #nil syntax fix to main after a bit more testing. I thought we were keeping main and master in sync, but it looks like they're not right now, so I didn't push to the latter. <rlb>That should fix lokke wrt 3.0.7, but it's still broken for main due to some issue I haven't figured out wrt cross-module inlining. <rlb>Well... fsvo "nice" :) It's still not remotely industrial strength. *rlb is working on defprotocol/defrecord at the moment <drakonis>clojure lives and dies by its java interop <rlb>I might break out the new edn parser if I have time, and it seems like something people might want -- the clj side is based on an intentionally scheme friendly module underneath (i.e. collection types returned are configurable, returns scheme-only structures as-is). <rlb>drakonis: I could imagine any number of possible motivations. For me, because I like guile, direct posix-ish access, and clojure :) <rlb>(i.e. I've quite enjoyed the collection interfaces, persistent data structures, some of the concurrency handling, etc.) <drakonis>not having to deal with java for anything seems like a good idea though <rlb>drakonis: it's a pretty tight integration right now - you can write modules in either scheme or clj, etc. <rlb>And it's faster startup than clj/jvm fwiw (though it's not as much faster as it would have been -- clj/jvm's been getting better). <rlb>But you're absolutely right -- has nothing remotely comparable to the jvm ecosystem, e.g. java.util.concurrent, etc. <rlb>(otoh, it's "easy" to extend via C) <drakonis>it is a fine way to pull in developers into the guile ecosystem <rlb>...I'd assume the scheme-based namespaces will generally be somewhat faster than the clj based namespaces right now (in part why I've written so much of it in scheme -- that and define-syntax), because they don't have the universal "invoke" trampoline insinuated during compilation. No idea atm how much that costs. <drakonis>i don't think i quite grasp the difficulty of a building a clojure dialect <rlb>Anyway, feel free to badger me on #lokke about any details if you like. <rlb>The syntax issue is why the macos tests are broken atm -- because brew's already moved to 3.0.7. <drakonis>there's no other way to drive adoption without something cool <drakonis>i'm curious however, guile is capable of being used for writing langs, yet it doesn't quite present itself in a manner that takes advantage of that <drakonis>it doesn't present that the way racket does <drakonis>it definitely needs more of that lang written with guile chutzpah first <rlb>There are also likely some rough edges -- I don't think languages other than scheme have seen all that much heavy use, so far. <drakonis>it needs more langs for solving specific problems though <rlb>When I get time, I'd like to see if I can fix up the repl modules to be more language agnostic. For lokke I had to just copy-paste some of the code and make adjustments, and it still doesn't preserve the clj printer in an error prompt (reverts to scheme's). <rlb>For that I *think* we'll probably need to teach the repl functions to pay attention to the custom printer "all the way though", but I haven't really delved yet. <drakonis>also fix up guile to have an easier time loading languages <rlb>Yeah, I hit some bits wrt the language spec and environment handling that I still don't fully understand, but "got something to work". <drakonis>in the same file, as that's an racket thing that mildly annoys me <drakonis>but its not well supported by the other existing langs yet <rlb>One thing I'll probably eventually need *if* I pursue more complete clj support is some solid thread-pool infrastructure. Figured I might see if I can do that in a way that's more broadly useful, but we'll see. <drakonis>native fibers implementation that's shipped with guile? <rlb>i.e. maybe just see about abstracting the existing future pool so that it can be re-used. <rlb>Hmm - I forgot about that (guile fibers). Have heard people mention it, but hadn't remembered to look. <rlb>*very* interesting - wonder if that might be able to support core.async. <rlb>I've found it very useful, but also sometimes a bit tricky. <rlb>It's not on my short list :)