IRC channel logs


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>The guile docs didn't say.
<RhodiumToad>the result list matches the order of the input, yes
<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
<marusich>Right, that makes sense.
<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>yeah, it works with 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>hmm, that's an interesting idea
<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>sometimes that's enough
<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.
<leoprikler>bummer :(
<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>(of a fixed size)
<jlicht>so e.g. (my-cover '(1 2 3 4) #:size 2) ; => '(((1 2) (3 4)) ((1 3) (2 4)) ((1 4) (2 3)))
<RhodiumToad>the 2 refers to the size of each partition element?
<jlicht>RhodiumToad: exactly
<jlicht>I know how to get all combinations, but not 'grouped' by them covering the entire original list
<drakonis>leoprikler: selection
<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>s/push to/update/
<jlicht>Is this about lokke?
<rlb>Sorta? lokke was how I noticed the problem, but I think it was a more general issue. There's a simple test in the commit:
<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> (also on gh)
<drakonis>ooo nice
<rlb>Well... fsvo "nice" :) It's still not remotely industrial strength.
*rlb is working on defprotocol/defrecord at the moment
<drakonis>hmm, why clojure instead of clisp?
<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 :)
<drakonis>i see
<drakonis>a clojure that can be embedded i see
<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.
<drakonis>this is interesting though
<rlb>(otoh, it's "easy" to extend via C)
<drakonis>that's an advantage
<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>aint no mac user here
<drakonis>am a guix user
<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
<rlb>drakonis: that was one of guile's founding principles, i.e. to support multiple languages on the same platform. One related bit In particular, "Compiler Tower".
<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
<drakonis>switching between them, as well
<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>rather, i think it is doable already
<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.
<drakonis>or just something else?
<drakonis>that could be useful for guix
<rlb>Hmm - I forgot about that (guile fibers). Have heard people mention it, but hadn't remembered to look.
<drakonis>it implements concurrent ml features
<drakonis>also a way out there project
<rlb>*very* interesting - wonder if that might be able to support core.async.
<drakonis>typed guile
<rlb>(wrt core.async )
<drakonis>i've heard about that
<rlb>I've found it very useful, but also sometimes a bit tricky.
<rlb>It's not on my short list :)
<drakonis>it has some adoption weirdness