IRC channel logs

2021-06-01.log

back to list of logs

<jcowan>Does anyone know how the decision was taken to add R6RS support to Guile? I can't see any obvious Guilers on the R6RS editorial committee (unlike Chez and Racket).
<taylan>jcowan: I'd say it was done at the whim of either Andy or Mark. my guess is on Mark. could check commit logs...
<taylan>commits seem to be primarily from Andy
<dsmith>iirc, someone else provided the initial patch for r6rs library/module syntax.
<dsmith>"Guile now has implementations for all of the libraries defined in the
<dsmith>R6RS. Thanks to Julian Graham for this excellent hack."
<dsmith>Looks like first appeared in Guile 2.0
<dsmith> https://mail.gnu.org/archive/html/guile-devel/2009-11/msg00000.html
<jcowan>THanks. So that means there are three kinds of R6RS implementations: (a) those maintained by members of the committee, (b) R6-from-scratch implementations that did not exist before R6; (c) Guile.
<taylan>hehe
***KindOne_ is now known as KindOne
<rlb>alextee: for web stuff, I'd likely lean toward clojure/jvm. The options there are broad and deep, both with respect to the jvm and available java libs (which are easy to use directly from clojure), and the available clojure-specific libraries. But other platforms may be preferable if you want faster startup and/or solid POSIX/unix/linux support (i.e. the jvm has only recently admitted symlinks and filesystem sockets exist).
<rlb>alextee: and that's in part what I'd hoped for with lokke -- faster startup solid support for #! work, POSIX/linux calls, etc.
<rlb>(you can also use clojure on both sides, server and client with clojurescript, and that works well too)
<rlb>At least to the extent that I've done client-side work, which has only been a bit.
<lispmacs>is there some procedure already which converts multiple return values into a list?
<lispmacs>instead of (receive (a b c) (someprocedure) (list a b c)), for example
<d4ryus>lispmacs: I dont know any, i use (call-with-values somprocedure list)
<lispmacs>d4ryus: a little nicer, thanks
<alextee>rlb, thanks for the info. being able to use it in both client and server side seems like a nice benefit
<leoprikler>lispmacs (compose list your-proc)
<lispmacs>leoprikler: that doesn't quite make sense, and doesn't seem to work when I try it
<lispmacs>leoprikler: oh wait, I must have typed it wrong. seems to be working now
<lloda>my readline troubles seem to have to do with threads. My program uses a GL thread and if I spawn it before activating readline, readline doesn't seem to initialize properly and I get the strange file-completion behavior and no history across sessions. If I spawn the GL thread after activating readline, then I get broken history, broken keys (C-k for some reason) and sometimes crashes.
<lloda>I'm kind of lost atm :-|
<wingo>humm :/
<wingo>is calling readline only from one thread an option?
<lloda>yes, that's what i do now
<lloda>the GL thread doesn't do anything with readline, it only does GL things
<lloda>rlwrap works, so i'll use that instead fttb
<wingo>blah
<dsmith-work>Tuesday Greetings, Guilers
<apteryx>hello! Is there something ready to use such as string-split, but splitting on a string separator rather than a character one?
<dsmith-work>apteryx: Were you asking this about a month or so ago?
<apteryx>eh, I hope not
*apteryx checks logs
<civodul>apteryx: see string-tokenize* in (guix search-paths)
<lampilelo>apteryx: you could use something like this: (lambda (str sep) (string-split (string-replace-substring str sep #\us) #\us))
<lampilelo>requires loading (ice-9 string-fun)
<lampilelo>does 2 passes though
<apteryx>civodul: neat!
<apteryx>dsmith-work: my logs say no! :-). Phew. I'm not totally loosing it.
<dsmith-work>apteryx: Ok. np. *someone* did.
<dsmith-work>I wonder if the srfi-13 funcs that take a predicate can coerced into doing the job.
<apteryx>it's a relatively common procedure provided out of the box in other languages I think (Python, Java at least)
<apteryx>in the browser: "Hello something World".split("something") -> Array [ "Hello ", " World" ]
<taylan>wow, kinda crazy that SRFI-13 doesn't have string-split
<jcowan>And does have -upcase!. It's things liike that that keep SRFI 13 off the R7 ballots: it's not designed for a Unicode world
<dsmith-work>jcowan: Is there a better replacement? (/me not up on r7rs stuff)
<jcowan>We have no less than five string SRFIs with a new one on the way. If you don't care about immutability, use SRFI 152, which is completely portable.
<leoprikler>Five? Preposterous! We need a new SRFI, that covers all potential use cases.
<dsmith-work>leoprikler: So we can then have 6! (insert xkcd link here)
***roptat_ is now known as Guest5512
<jcowan>They serve different use cases: mutable strings, immutable strings, both; string cursors vs. string indexes; backward compat with R7RS vs. no backward compat.
<leoprikler>except for the R7RS stuff, everything else is no either/or
<jcowan>We could have lived with SRFI 13 indefinitely if it weren't for UTF-8/UTF-16 internal representation and immutability becoming popular
<jcowan>A or B or both is a choice, even if not an either/or choice. Libraries that provide cursors also provide indexes for backwards compat
<dsmith-work>Ugh
<jcowan>Also, I should have sais "R[567]RS"
<jcowan>dsmith-work: Can you clarify a bit?
<dsmith-work>Heh. Just seems a mess.
<jcowan>Oh, at the meta level, yes; but we have what we have. I am writing the sixth with the intention of providing both mutable and immutable strings, no cursor support, and backward compat. I believe it may be said to fairly subsume four of the five other SRFIs.
<manumanumanu>jcowan: (I am clearly beating the dead horse)why no cursors? To me it seems like the most efficient way to iterate over utf-8 representation strings...
<manumanumanu>Everything is of course a compromise, and it is not a very common way to handle strings, but I wrote some code for chibi and found it quite elegant...
<jcowan>Oh, I don't deny that. I thought fitting cursors into the Sixth Library would overload it too much, but it's certainly possible to do so.
<rlb>alextee: certainly, though of course there are tradeoffs, i.e. the happy path in that world is the pip/gem/mvn "download giant piles of code from ..." track, unless your distribution actually packages everything you need, and even then, it may not be trivial to make sure you're only using the distribution versions (if that's what you want).
<rlb>But I *did* like being able to write clj code for the browser (though I haven't been doing any of that for a good while now).
<manumanumanu>dsmith-work: I usually say that one wouldn't design a "2021 scheme without historical luggage" with mutable strings (or cons pairs for that matter). SRFI-135 seems reasonable to me :)
<manumanumanu>(mutable cons pairs
<manumanumanu>)
<dsmith-work>« and » for quotes eh?
<leoprikler>R8RS when?
<jcowan>manumanumanu: Owl Lisp is an immutable Scheme (modulo I/O)
<drakonis>Guile 4 when?
<jcowan>leoprikler: I sure don't know; after I'm dead most probably. For sure I won't be leading it
<manumanumanu>dsmith-work: something like that. I would definitely vote for having to write "please" often enough to make it compile like in intercal.
<manumanumanu>"immutable strings with manners"
<manumanumanu>Good night!
<dsmith-work>I've been learning/using Rust quite a bit lately, and the way they do strings feels right. Maybe it's just because I'm used to it?
<dsmith-work>Internal is all utf8. Os things (filenames, etc) are Os-specific. Iterate over strings, no direct idexing. The differece between a String and a &str was weird at first, but makes sense
<dsmith-work>Of course they have the luxury of no historical baggage.
<leoprikler>But in turn, there is Cargo :)