Quits:nicole (ilbelkyr@freenode/staff/atheme.ilbelkyr) (Killed (grumble (My fellow staff so-called 'friends' are about to hand over account data to a non-staff member. If you care about your data, drop your NickServ account NOW before that happens.))) ***ilbelkyr is now known as nicole
*daviid has a g-golf wip-3.0 branch that now successfully works with 2.2 and 3.0.7 <taylan>wingo: I already opened #guile@irc.libera.chat and can give you channel ownership when you want :D nickserv registration doesn't seem to work yet though... <leoprikler>sneek later ask ArneBab should it be possible to read a Wisp sexp from the middle of a file assuming proper indentation? <dsmith>taylan: Is irc.libera.chat actually working? Connection closes for me when I use erc-tls to connect <taylan>dsmith: maybe it's TLS-only. I was able to connect to irc.libera.chat:6697 with TLS <civodul>peval reduces (string? (caar `(("x" ,+)))) to #t, yay! <civodul>but it fails to do that with (let ((x `(("x" ,+)))) (string? (caar x))) <civodul>wingo: what are your thoughts on this? <ft>Hm. Didn't guile have something that turns a file glob pattern into a list of matching file names? Did I just dream that? <civodul>ft: i don't think there's anything for glob patterns in Guile <civodul>Gash has that, and Guix has a regexp-based 'find-files' procedure <ft>civodul: Thanks! I may have to borrow that real quick. :) <lampilelo>guile has readline support that you could use for that, if filename completion worked, but it doesn't <lloda>i saw your bug report on that a while ago lampilelo <lloda>i've had this problem for a while that i have filename completion in embedded guile and i don't know how to switch back to normal completion <lloda>the switch happened one day i updated some debian packages i think. No idea how <lloda>do you happen to have a link? <lampilelo>wait, filename completion worked for you? with filename-completion-function? <lloda>in plain guile i get normal completion <lampilelo>i don't think it solves your issue of not being able to switch to normal completion though <lloda>patch seems straightforward tho <lloda>I tested with (with-readline-completion-function filename-completion-function (lambda () (read))) which i remember not working before <lloda>civodul: wdyt about reverting master to 3.0.7 like wingo was saying <lampilelo>thanks for pushing it, i remember rewriting a script from guile to elisp because filename completion didn't work, elisp is fine but not very good for scripts so i wrote this patch anyway <wingo>civodul: weird :) re the peval thing <lampilelo>fwiw i'd prefer if you just outright removed master branch because i'm sure some day i'll try to compile master and be surprised by the wrong version, i'm saying it from a perspective of someone who git checkouts to the newest tag after a release and rarely compiles the most recent code <lloda>there's no confusion if the branch is gone <lampilelo>i have an unrelated question: do you require copyright assignment to fsf from contributors? <lloda>tbh i'm not sure of what is the size of patch where that becomes a thing <wingo>i would like to stop requiring assignment fwiw <wingo>haven't gotten around to doing that yet tho <wingo>will require some policy statements etc <lampilelo>i think it was >15 lines total? per contributor, not per commit <dsmith-work>(I personally really dislike the GNU C style, but I appreciate having a consistent style) <dsmith-work>lloda: { on a separate line, indented 2. body idented 4 <dsmith-work>It is just such a small commit that it popped at me. <lloda>i'll try to remember dsmith-work thx <dsmith-work>What's with the "THIS CHANNEL HAS MOVED TO IRC.FREENODE.NET" messages on libera? <ft>dsmith-work: Sounds like trolls? <rekado>hmm, guile-redis cannot be built with guile 3.0.7 <rekado>“unknown location: unexpected syntax in form ()” <rekado>very confusing. There’s no “()” in the file it complains about. <taylan>rekado: and it surely doesn't use #nil, right? <civodul>lloda, wingo: i think i missed something: reverting master to 3.0.7? <taylan>(I happened to work on a #nil-related bug in 'match' recently that produced that same error message) <taylan>civodul: master has been moved to "main" <lloda>the other option is to remove master entirely *civodul goes afk for a bit <lloda>but maybe some distro relies on that? no idea <rekado>it might be because of “(syntax-rules () …)” in redis/commands.scm <rekado>yup, replacing the #nil with (list) fixes it. <taylan>rekado: the main takeaway for me was that the syntax-rules pattern (x ...) matches #nil, which can be surprising but makes sense in a way I guess <taylan>rekado: do you know why they use #nil? the general idea is that it's strictly for elisp-compatibility purposes and shouldn't ever be used explicitly in Scheme... <lloda>maybe that point hasn't been stressed clearly enough <leoprikler>I think it's fair to use #nil in contexts where you want something to be both the empty list and false :P <taylan>leoprikler: I'm not sure... it can cause headaches to the Guile maintainers when they want to tweak an aspect of how exactly #nil behaves when they realize they can improve Elisp compatibility, or improve Guile's performance without breaking Elisp compatibility <taylan>it's less about RnRS and more about why it was added to Guile in the first place, which is: an Elisp compatibility hack <taylan>leoprikler: for instance it's unclear whether (equal? '() #nil) should be #t or #f, and if your Scheme code relies on either, then Guile maintainers realize that it would improve compatibility to change it, your code will break... <taylan>and next thing you'll complain at the Guile maintainers for "breaking" your code :P <leoprikler>I would never demand from Guile maintainers to make #nil equal? to either '() or #f <taylan>if you're ready to tweak your code in accordance to changes Guile makes to the semantics of #nil then no problem I guess :) <leoprikler>I do however rely on ((@@ (ice-9 match) match) (cons 'a #nil) ((a) #t) (_ #f)) => #t <leoprikler>Which I personally think is a fair assumption to make. <taylan>yeah IMO that should keep working, otherwise lists coming from Elisp-land won't work properly with 'match' <terpri>leoprikler, technically, it already breaks rnrs (unless #nil is considered not to be a scheme object), by extending null? for example. but that's a fairly conservative extension imo <leoprikler>that's exactly what I meant with "who cares about RnRS" :P <terpri>whereas making equal? a...tolerance relation, i think? rather than an equivalence relation might have consequences for optimazation or something even though it might be convenient on a pragmatic level to make r5rs do the intended thing in the presence of #nil <dsmith-work>So the nil #f '() issue is one thing. I'm curious about the lisp-1-ness of Scheme and the lisp-2-ness of emacsl-lisp. How is that handled? <terpri>dsmith-work, at the moment, very simply: the values of the symbol slots are stuffed into separate guile modules (value-slot-module, function-slot-module, etc.) <terpri>it was written that way mostly for expediency; it's probably not the ideal design <leoprikler>I think the problem could easily be solved by the user defining false? as (member '(#f #nil)) and using null? ***zap1 is now known as zzappie
<leoprikler>note, that emacs does have the notion of an obarray, but it's used sparingly <wingo>in guile, that is more efficiently implemented as (not x) <terpri>yeah, iirc there's no obarray in guile-emacs <leoprikler>wingo: I didn't say it was the best implementation of false? :) (define false? not) (define true? (negate false?)) should work <manumanumanu>civodul: that is not quite true. It becomes something like (let* ((cursor (list 1)) (cursor-1 (cons 3 cursor))) (reverse cursor-1)) <wingo>leoprikler: i just mean that (not #f) => #t and also (not #nil) => #t <wingo>ok if this is an aesthetics question, sure :) <wingo>not recognized by the compiler tho <wingo>haha if only we could be so elegant in boot-9 ;) <leoprikler>well, (define (->bool what?) (not (not what?))) is semantically the same anyway <terpri>wingo, fwiw i think i'm probably wrong about the idea of making #nil equal? to other scheme values, since that would emphasize either its boolean-nature or list-nature at the expense of the other. making it equal? to a boolean or a list would privilege one interpretation, making some rnrs programs "just work" while others would be broken <wingo>ah i think i am missing some of the scrollback on this laptop <wingo>terpri: you were considering a change but decided against it, if i understand correctly <terpri>right, i was (perhaps a bit selfishly) focusing on more transparent elisp compatibility <wingo>omg if you are back on this hack, that is fantastic news!!! <wingo>(if not, that is ok too, no pressure :) <wingo>but do as you will re: elisp in guile, i trust your judgment <leoprikler>I can't wait to rewrite half of dystopia.el in 3.0.8, because keywords are finally recognized :) <terpri>wingo, the idea is due to taylan, and i agreed with them initially, but it can't be done "the right way" (or, per newer rnrs, the very wrong way) by adding more equalities, since as someone helpfully pointed out... <leoprikler>by the transitivity you would have (equal? #f '()) in the end, which is silly :P <terpri>(equal? #nil #f) and (equal? #nil '()) would reduce equal? to a mere tolerance relation <manumanumanu>wah... I had a closer look at some of the scheme benchmarks things. the scheme benchmarks are _not_ comparing the same thing at all, even if we only do safe optimizations. cyclone does memoization of pure recursive functions :) And does no cycle detection. <terpri>lacking the extra #nil equalities will surely break the "intent" of some rnrs programs (for n > 3, iirc) <terpri>but maybe that can be papered over with a lisp-compat module or something that redefines equal? and friends <leoprikler>does RnRS want people to compare booleans and lists with equal? <terpri>(another idea is to have, internally, a "lisp box" which is totally transparent to scheme except for #nil, and for #nil requires an explicit coercion, but that sounds a bit clunky and maybe bad for perf) *terpri should be writing this up for emacswiki <leoprikler>or is this about (equal? '(a b c) (cons* 'a 'b 'c #nil)) <leoprikler>(which I'd argue should be done in terms of match anyway) <terpri>leoprikler, yes, that sort of expression is the "problem" <taylan>terpri: are you sure privileging (equal? '() #nil) over (equal? #f #nil) would be a problem? IMO privileging one would be better than neither, and I think #nil is the better choice due to its ubiquitous role in list structure, but not sure... <leoprikler>taylan since you mentioned clojure the other day, what would happen if (equal? '() #nil) and (equal? #() #nil) :P <taylan>leoprikler: I'm not well-versed in Clojure... <leoprikler>maybe that was someone else then, sorry, my memory might be fuzzy <taylan>leoprikler: but IIRC nil doesn't equal the empty vector in Clojure? <leoprikler>didn't someone say that #{}, #(), '() and #nil are same-y in Clojure? <justin_smith>taylan: correct, conj treats nil as if it were an empty vector, but an empty vector and nil are not equal <terpri>rlb is a clojure/lokke expert in this area, who mentioned #nil's utility in clojure-on-guile <justin_smith>leoprikler: not quite - the "seq" function collapses all of them to nil but that's an abstraction layer used for sequential data, and not a property of those data structures <terpri>taylan, well, we can define it either way, considering it's a unique(?) extension for modern scheme <justin_smith>so instead of having map-list map-vector map-set etc. we have map, which uses seq to get a sequential view of any collection <justin_smith>leoprikler: which might be an approach worth emulating - instead of treating empty collections as nil as false, using a function that is false for empty collections and nil and true for other inputs <terpri>taylan, it's just a situation where we (probably) can't have our cake and eat it too, in terms of behavior matching a scheme programmer's likely intent in all situations <terpri>taylan, i think any of (and (equal? #nil '()) (not (equal? #nil #f))), (and (equal? #nil #f) (not (equal? #nil '()))), or (and (not (equal #nil '())) (not (equal #nil #f)))) are all acceptable in a formal sense <terpri>i don't have a good intuition for which "pun" would be more useful, if any, but i wouldn't object having one of them enabled -- probably little harm in just trying one out at this point if you find one distinctly preferable, or if one choice makes #nil an appropriate representation of clojure nil but not another, etc. (the only caveat i can think of is that for the "punning" options, there might be low-level bits <terpri>of guile to consider, like equal? as a hash table predicate) ***Server sets mode: +nt
<leoprikler>I really think the pun should be handled by some separate entity like seq <terpri>(tbh the mathematical-logician part of me doesn't like the idea of introducing equality "puns", but as long as it's marked <blink>experimental</blink>, it should be harmless enough to try it out and perhaps we could do some testing with important programs like srfi-1) <leoprikler>I think stuff like SRFI-1 should just handle #nil internally without a pun. <terpri>sort of a Solomon-esque solution ;) <terpri>"no you can't have either convenient thing, fix your program or import a compatibility module" <leoprikler>Not only would this probably solve most issues that could arrive in RnRS programs, it's also show how to implement things correctly *terpri reads the symbol patch <leoprikler>and people wouldn't be led into the temptation of comparing with equal <terpri>leoprikler, yeah, that's the ideal outcome, people using procedures like null? where appropriate and not relying quite so much on the concrete representations of things (even though it's perfectly legal per rnrs) <leoprikler>IMHO Guile documents its RnRS incompatibilities pretty well. <leoprikler>that's more valuable than "Oh, it's legal RnRS, it should work." <leoprikler>The equivalent C would be "It compiles, so I don't care." <terpri>i don't know if it's technically feasible, but it would be neat if it were a runtime option (perhaps an, ah, optional runtime option) so that people could test their programs under different modes and find out "how broken will my program be when the million-line elisp elephant enters the room" <leoprikler>I think a compiler warning about (equal? '()) and (equal? #f) should do the trick as well <leoprikler>and of course optional so as to not confuse people, who know what they're doing ***Server sets mode: +nt
<dsmith-work>Speaking of compiler warnings, wouldn't it be nice to *only* display all those "hey I'm compiling this now" messges when specifically asked to? As in a -v option? <leoprikler>you mean the auto-compilation? imo the current stuff is fine, because it gives you performance by default but warns you about the side effects that may have <terpri>taylan, to answer your earlier question, pragmatically speaking, imo you're probably right that the equal? issue will pop up more often with lists. i'd guess (eq? #nil '()) => #f and (eq? #nil #f) => #f will both cause issues with real-world programs, but we can't do anything about that in core guile, at least without a radically different design for lisp<->scheme communication <leoprikler>auto-compilation can break programs in unforeseen ways after all :P <terpri>which doesn't mean we should necessarily introduce the pun, but i concur it'll be more of an issue (how often is it likely to show up with booleans? (member? #nil '(#f ...)) and the like?) <terpri>i like the compiler-warning idea too (which could help with more than just equal?) <taylan>the CLI switch was my priority since that'll allow script authors to do it <dsmith-work>taylan: Yes, saw that. I'm suggesting the logic should be inverted. *terpri pokes around debbugs to see if they can commit things through that interface (as a savannah-level guile commiter) <taylan>dsmith-work: hmm, maybe so. I have no strong opinion on it. <terpri>taylan, the symbol? patch lgtm on an initial skim, thanks for fixing that! (might be the sort of bug where emacs ended up redefining the boot.el definitions...or maybe it's just been broken this whole time, who knows) <taylan>terpri: btw any plans of rebasing your branch on 3.0? :P I guess it's probably a big task... oh and, you've seen rekado's rebase on a more recent 2.2, right? <terpri>wingo, i'm afraid i'm not back on the hack just yet, as i'm working at a gamedev-tools startup which needs me full-time atm, lest it run out of runway. but in 3-6 months my client expects that i should be able to work roughly half-time <terpri>and then full, er, half speed ahead! ***malaclyps2 is now known as malaclyps
<rlb>In case it wasn't fully covered, yeah, in clj nil is also effectively an empty collection for most purposes, and it's also "false", while other concrete empty collections like #{} [] '() are not. ***sneek_ is now known as sneek
<terpri>taylan, yes, provided it's not too time-consuming. thanks for mentioning rekado's rebase, i rememebered someone worked on it after dustyweb but not who) ***unCork is now known as Cork
<rlb>and if I remember the history correctly, clj used to be more like elisp, in that '() was false too, but they intentionally changed that, I believe to improve laziness. <rlb>Personally, I find the collection/seq (laziness) abstraction often very convenient, but it's indeed not very traditionally "schemey". <taylan>rlb: assuming there's an 'equal?' of sorts in clojure, nil isn't equal? to any of '(), [] or #{}, right? <taylan>assuming ClojureScript has the same semantics, according to https://clojurescript.io/ (= nil '()), (= nil []), and (= nil #{}) are all false, only e.g. (= nil (seq '())) are true <taylan>but I'm not sure if clojure's '() is represented via Scheme's '() in lokke. if so, then (equal? #nil '()) might pose a problem I guess. <taylan>I feel like we discussed this a few days ago already but I forgot since I couldn't keep clojure's semantics in mind, sorry ^^ <terpri>taylan, same results for = on regular clojure ***Server sets mode: +nt