IRC channel logs
2022-11-24.log
back to list of logs
<old>Anybody wants/has a srfi-109 or a subset of it? <tohoyn>daviid: it seems that defining signal handlers for radio menu items and toggled menu items requires support for GVariants <tohoyn>daviid: the signal handlers are defined for the appropriate GAction objects <tohoyn>daviid: and the state of a GAction is a GVariant <tohoyn>daviid: I can't define a signal handler for the radio menu actions. I have to study this problem more. <tohoyn>I can't define a activate or change-radio-state signal handlers to a <g-settings-action>. Could somebody help me with this? <haugh>old, I would really like to see some kind of heredoc, but 109 goes a bit off the rails IMO. All I need are Chicken's multiline literals <haugh>Not a big issue because (ice-9 format) is so great, but format strings are like regexes in terms of module readability and I'd rather avoid them for simple cases. <old>I think that srfi-109 has some support for something like heredoc? <old>At the end what you want is: Custom multi-line string delimiter + variable interpolation <old>yes by only within "" <old>srfi-109 allow you do to something like EOF in bash <old>at least that's my understanding of it <haugh>would this be the only reader feature in Guile to care about whitespace? <haugh>singpolyma, the main idea (again imo) is to allow for trimming leading whitespace so your whole multiline string can be indented with the rest of your code. Also, interpolation. Cleary SRFI-109 goes well beyond this which I suspect would contribute to adoption hesitance <haugh>What's the best way to search multiple mail archives at once? <haugh>I'm not finding any discussion about this in guile or guix archives. The latter surprises me because those guys have to deal with UNIXy config formats and I certainly don't like doing that without heredocs <old>I found 109 to be overengineered, but a subset of it could be made <haugh>which features are vital to you? <old>For searching multiple mailing list I don't know. Typically search engine could be good enough for that <old>To me the most important feature is the variable interpolation in string <old>It's less error prone than variadic format like now <old>Because you put the expression that you want at the location in the string <old>This feature is really easy to make, I've made a proof of concept in ~30 lines <old>Multi-line is already supported natively in Guile. But a variant with trimming of whitespace could be great <old>Typically I always do my multi-line like this: <rekado>variable interpolation would be very nice to have <rekado>having a long string with a bunch of “~a” scattered throughout and a bag of variables/values at the end is error-prone. <haugh>I don't like all these & "markers" in 109 <old>I hope I've get the URL right, I can't resolve my own domain for some reason <haugh>so Bash supports disabling interpolation and optional (very limited) whitespace trimming, both of which are controlled by variations on the delimiter <haugh>I guess the big issues are 1) hijacking the reader to parse whitespace 2) options syntax better than marker soup 3) markup consistent with Guile as a whole <haugh>SRFI-109 has that very SRFI-specific complication where it's connected to how things are done in other SRFIs like 108 <old>One problem also is that you have to import the module everywhere <old>I don't like this approach. Having to use-module srfi-109 in every module is a pain <old>Right now, there's only the (guile) module that is included everywhere I think and r6rs at boot also I believe <haugh>I have a (style) module I use to collect all the conveniences I use everywhere <old>I don't know if there's a way to tell guile: Load this module for every environment of the program by default <old>But then you have to include that (style) module everywhere don't you? <haugh>isn't it a massive political flustercuck to get stuff included in basically every core library in the world? better to give users choices imo <old>Yes sure. I'm just used to `-include def.h` in C where that header file is now automatically included in every compilation unit <old>Such a breeze. Now my DSLs are available without include at the top <haugh>how does that work with this module system, though? wouldn't you end up with modules that only work in the right context? <haugh>there's also `use-srfis`, probably implemented specifically for people complaining about this :) <old>Typically you add an argument like `--use-modules=(foo bar) (foo buz)` and it would work the same as with srfis or r6rs/r7rs <old>By loading the modules during the boot <old>At least that's what Guile does I think <old>hmm `process-use-modules` <old>ah that only works with REPL <haugh>I like this module system. Ever work with Python? It could be worse. <old>yes. I had a bad time with python modules <haugh>Granted "it could be worse" is always true but as I (very gradually) mature I am starting to see the benefit of some explicitness. <haugh>This is what I meant the other day when I was talking about Guile being "conservative" <old>But not in the form of &{} <haugh>We agree that all we want is interpolation, trimming, and clean options to disable both? <old>By options you mean reader options? <haugh>No I mean per-invocation, like Bash <old>I'm just aware of single/double quote in bash for disabling/enabling interpolation <old>For trimming I don't know if that's even possible <old>But yeah these two features are I think the core of it. <haugh>but regardless, the whitespace awareness seems to require hacking the reader which is (probably) orders of magnitude harder than your elegant interpolation solution <old>I don't much about readers in Guile. But I think it's doable yes <old>Just have to think of a syntax that would be nice. My fear is that emacs or other editor will not understand that syntax and thus indentation will be terrible <old>For readers, I'll have to read the manual yet again to grasp how to do it. I could try a very simple proof of concept without trimming first <old>Btw I think this is why &{} is used in SRFI-109. Just like #~() is used by Guix for G-exp. It's just plain natural scheme <old>Easy to parse and the editors don't get confused <haugh>Right. As long it's still considered a list of symbols to a "foreign" reader <haugh>Wait, do hash reader extensions capture whitespace? <old>I've used arbitrary symbols for the reader but also one that don't clash with Guix G-exp <haugh>Oh, there's no EOF provided by read-hash-extend? <haugh>I can terminate it in the REPL by pressing "Control D" on a new line <haugh>maybe (ice-9 rdelim) is meant for this <haugh>in terms of symbol I would use one hash extension which is followed by modifiers, like #<term #<-term #</term #<-/term (but not necessarily these symbols) <haugh>> It’s something of a wacky interface, to be honest. <old>Yes that sounds good <old>#<() #<-() #</() #<-/() <old>Can't grasp my head around which one is which though <old>There's need for easy mnemonic <haugh>there's also the line-oriented custom term delimiter <haugh>agree a mnemonic is better, maybe even keyword list <old>That could do it I think <old>kind like f"" in python <haugh>okay but you keep using the list syntax instead of a custom delimiter <haugh>e.g. #<TERM foo bar baz TERM <old>Ah yes. It's necessary to not break editor I think <old>But it would be in theory possible <old>paredit will just keep messing with your heredoc otherwise <haugh>there are tooling issues with relying on a sexp, as well. How does paredit, for example, indent `#<(foo bar LINEBREAK baz qux)` ??? <old>Well for start its breaks slurping <old>Here your example but with '@' <old>This is what you would get with auto-indent of paredit <old>`$` could work but not `%`. Seems arbitrary .. <old>Also, you can also extend with a single character. You can't have two or three of them <haugh>I was just thinking the symbols should always be two characters <haugh>what a messy intersection of ideas <haugh>starting to understand why Guix said "f it, string-concatenate it is" <old>But I don't see you can extend the reader with 2 characters <old>In the manual under `read-hash-extend`: the character CHR <haugh>Yes, but it kickstarts the custom reader and you can just grab arbitrary characters off the port <old>So you would dispatch depending on the next character in the port <old>Also it does not mention what PROC is supposed to return <haugh>Yes. To do something complex like what we're talking about it probably requires P A R S E R C O M B I N A T O R S <old>Hey I think you're suppose to return the value of the expressino <old>Like '(1 2 3) would return (list 1 2 3) <rekado>I wanted to join the fediverse, but haven’t found any ActivityPub implementation that I could feasibly host on my little home “server” to federate with Mastodon. <haugh>rekado offtopic but try pleroma? supposed to be much lighter <rekado>so I wondered if this is sufficient to build a little server to talk to Mastodon <rekado>pubstrate is written in Guile, so I think it’s very much on topic :) <haugh>old, you think the manual should say "The object returned will be the return value of (read (PROC c p))" ? <haugh>rekado I just meant pleroma is offtopic, more guile software is better as far as I'm concerned :) <old>Yes. It would be more clear IMO <old>Maybe I've missed something in the manual <haugh>what if we named the four different modes 'default 'quote 'block and 'literal <haugh>and if you don't know which means which then those are bad names <old>eeh I'm confused lol <old>I think that quote could be a good one for no interpolation <old>#@'(,(+ 1 1)) -> (format #f ",(+ 1 1)") vs #@`(,(+ 1 2)) -> (format #f "~a" (+ 1 1)) <old>For trimming I'm not sure. Literal could be it yes. <old>In the end, this is easy to change after a minimal implementation is made ;-) <old>Well I'm happy to see that my usage of the '@' character was not crazy <robin>does guile/goops have anything like return-type declarations as common lisp does? or would i need to use procedure properties for that? <robin>(i'm thinking of using guile to compile a weird custom smalltalk dialect with type annotations, so it would be for debugging and documentation rather than performance) <singpolyma>robin: a Smalltalk frontend for guile you say? 😀 <robin>rekado, i've heard pleroma is much less resource-intensive than mastodon, and will probably use that for hcoop.net (unless our members really want mastodon specifically) <robin>pubstrate looks cool too, i hadn't actually looked at the repo before <singpolyma>robin: there's a new one making the rounds today that will be lighter than either and not require JavaScript <robin>singpolyma, it would be a very minimal smalltalk to run a handful of programs (tremendously complicated ones, admittedly, and they also hacked the VM and didn't release those patches) <robin>it could be fun to implement full smalltalk on top of it though (assuming there is even time for the minimal implementation!) <robin>(there is gnu smalltalk, of course, but gnu already maintains multiple implementations of other languages, and scheme is more fun than c :)) <robin>ty singpolyma, multiple-domain support is so useful i'm surprised it's not supported by other servers (setting up AP "virtual hosting" is pretty high on my TODO list; sysadmin-approved SML hacking is normally required for adding new service types, similar to scheme and guix services) <robin>low/no-javascript doesn't hurt either :) <haugh>old, if only use-module let you pass an argument to a module as you imported it. So many reader extensions could be implemented without worrying about "correct" symbols <rekado>but I don’t know what to expect from these things; no idea if they all seamlessly federate with mastodon.