IRC channel logs
2026-08-24.log
back to list of logs
<rogerfarrell>Hello #guile, Can someone please help me understand why lambdas do not support partial application by default? I feel like I must be missing something obvious. <rlb>rogerfarrell: can you elaborate a bit? <PuercoPop>Why would they support it by default? They scheme is not a lazy language. IIRC it doens't even guarantee that the arguments to a function are not processed in a left to right order <PuercoPop>rlb: I'm guessing they are asking about auto-currying. Some langauges, when you pass less arguments than a function need, return a function that takes a remaining arguments. <PuercoPop>e.j. ((lambda (x y) (+ x y)) 1) would return a function that would be equivalent of (lambda (y) (+1 y)) <ane>making a (curry fn 1 2 3) macro is not that difficult <ArneBab>rogerfarrell: I’m glad that there’s no auto-currying, because (a) that doesn’t work with argument numbers of parameters, and (b) passing the wrong number of arguments when a function takes a fixed number is a common source for bugs in Javascript. <ArneBab>s/argument numbers of parameters/variable numbers of parameters/ <ArneBab>rogerfarrell: that said, (srfi srfi-26) cut provides very convenient currying. <lloda>looking at srfi-26 the syntax is less than ideal. Instead of (cut f a <> c) why not just say (f a <> c). Only this doesn't seem doable with macros <JohnCowan>There's a paper that provides a series of currying macros that doi handle vararg functions <haugh>There's also some sugar in (ice-9 curried-definitions). <haugh>And writing your own currying syntax builds character. <rogerfarrell>Thanks everyone for the explanations. PuercoPop is correct. I was indeed referring to auto-currying. I naturally think of lambdas with multiple arguments as curried lambdas. It feels tedious to do an extra step to get this functionality. <rogerfarrell>After some minor alterations, I have exactly what I was looking for. <rogerfarrell>This is hardly ideal. It seems like a bad idea to use macros at such a foundational level, but I am still left wondering if this fundamentally goes against the grain of scheme. <ekaitz>rogerfarrell: the grain of scheme is that you can manipulate the language to fit your needs <rogerfarrell>ekaitz, But I want to be a good disciple of Ableson/Sussman. 🥺 <ekaitz>rogerfarrell: have you seen any of Sussman's talks? If that guy doesn't enjoy it, who does? <ekaitz>Ableson is more of a boring dude <hwpplayer1>hello, should I adapt Guile to a new systems language like Guix have to quantum computing or start my other lish dialect from scratch called qshell <hwpplayer1>I want to use Guile for quantum computing and my GNU/Linux distribution <ekaitz>it depends on what you want to do. If you want to spend all your time making the dialect, that's fine. <hwpplayer1>What advantages and disadvantages choosing Guile ? <rogerfarrell>ekaitz, I hear you. I just might have fun with my pet ~curried-lambda~. <ekaitz>i don't know about quantum computing but the fact that guile already exists is a plus <ekaitz>guile has macros, like any other scheme <ekaitz>guile is pretty fast, between the schemes, and probably substantially faster than Emacs Lisp <hwpplayer1>Can I use Guile for my needs/quantum computing ? <ekaitz>and it's as composable and cool as Elisp but in a cleaner way: proper module system and all that <ekaitz>i don't know your needs, but if python, js, elisp or any of those can fit them, Guile too <sham1>Well to determine whether Guile can fit with quantum computing, you'd first have to describe just what special requirements quantum computing would add for a programming language or the environment it gets executed in <sham1>I.e. what does it mean to do quantum computing, really. Like, I'm sure a lot of people are aware of qubits and such, but like what are the actual implications of those <hwpplayer1>I don't have enough network connection/gb/hotspot <ekaitz>i kind of find very funny the way IRC is slowly becoming like chatgpt for some people <sham1>Well it's a chat, and ChatGPT is a chat. I can see why the confusion would arise <ekaitz>"just tell me all the advantages of Guile" <sham1>Like I'm just looking at that question, and it's just that, what is one supposed to answer there? Basically no one has access to quantum computers so it's difficult to say just what the requirements would be. Like something something stochastic processes when the superposition of qubits collapses or whatnot, but beyond just some stuff you might find in descriptions of QC for laymen, it's not like people know what is going on there <sham1>And yeah, in general these kinds of "should I use Guile questions" are just odd. Sometimes it feels like people get annoyed when you actually aren't psychic and can't read people's minds in order to divine what their use-case is and other similarly important details <sham1>At that point the answer is just "maybe" <ekaitz>i basically tend to answer: if any other scripting language can do it, guile can <ekaitz>or basically ignore the question <sham1>That is probably the better way to handle it <rogerfarrell>As a programming noob/hobbyist just trying to learn, I really appreciate IRC (especially #guile and #guix). Human answers are categorically superior, but they are becoming increasingly scarce. Thanks for putting up with basic questions and misguided assumptions. I try to do my own research first, but sometimes you just need a mentor. <ekaitz>rogerfarrell: claro! we see many questions here and some are more appealing to answer than others. <gabber>i have two functions: a low-level (invoke . args) and a higher level (invoke #:key (foo #f) (bar #t) . args) one. what's a good way to remove the kwargs from a call to the latter before passing ARGS to the former? <gabber>should i just transform invoke to a lambda* and ignore all kwargs? <gabber>i guess i could for-each through all args and skip two whenever i encounter a symbol that starts with "#:" <rlb>If you just want to drop the keyword args, then I suspect letting lambda* or one of the variants (define*, etc.) handle it is a likely choice, unless you have special requirements. <rlb>e.g. if you knew the args had already been validated elsewhere (or you didn't care about incorrect invocations), you could just drop every thing after and including the first keyword if performance were critical, etc. <gabber>the issue stems from the fact that (invoke* #:key (foo #t) . args) includes all arguments (also kwargs) in ARGS <rlb>Hmm, yeah, I was just reading the lambda* docs --- realized I didn't actually know offhand all the details. <rlb>So maybe ignore me :) <gabber>i guess the for-each kwarg sanitizer is the way to go ;) <rlb>Or a let loop "reducer". i.e. if you just want to drop all KEY VAL occurrences. <gabber>looks like a good opportunity to get acquainted with the common let loop pattern <gabber>in this example `loop' is automatically treated as lambda an evaluated? <gabber>thanks! couldn't find it in the docs by myself <gabber>ahh, i should've followed the link to the `named let' at the bottom of the let entry on the bindings page <rlb>And if you're not familiar with it, the reason to do the cons and then final reverse! (could have also been a reverse, but reverse! is safe here) is so that we don't build the result "on the stack", though unlikely to matter much for argument parsing. <rlb>Though the on the stack version is "nicer" :) <gabber>what's a nice way to convert a string like "(gnu packages audio)" into a list of symbols '(gnu packages audio)? <rlb>gabber: if you know it's an s-expression subset, perhaps just with-input-from-string and read, assuming it's either trusted or there are no potentially risky reader extensions. <rlb>(reader extensions are currently global? if so, I'd prefer to have some clj style "safe" equivalent of clojure.edn/'s read, read-string, etc.) <rlb>Also, not "module scope", I think I now recall. i.e. I'd naively started off with clj-style keywords in some places in lokke (:foo), but that's a bit of a mess in modules because the setting doesn't revert at the end of the module (load). So I just "stopped doing that", since it wasn't important. <rlb>I felt like I wanted it to be treated like an "excursion", i.e. revert to whatever it was before the (define-module ...) at the end of the file when loading a module, but I didn't think about it enough to know if that was actually sensible. <old>you can have multiple define-module within a file <old>but ideally I agree with you <rlb>yeah, that's why I was hesitating :) <rlb>Also, what about include-from-path... <rlb>Hmm, is it a "file" attribute in some cases (like coding)? <rlb>Not today's problem? <old>in any case we can't really changet the global behavior <old>perhaps we could introduce local reader <old>but then, is it the used module that inject this local behavior in the importer module ? Or is the importer must be calling something from the imported module <rlb>dsmith: did we capture the freebsd setup instructions anywhere? <rlb>I had it working in a vm here back when we were messing with it. <lilyp>gabber: another way would be to drop the first and last letter and use string-split plus string->symbol; this assumes you know your string to be a module list tho <JohnCowan>rlb: whether reverse or reverse! is better depends on whether the gc has a write barrier <PuercoPop>how do I pretty print the code returned by macro-expand? ,pp doesn't work because macro-expand returns a tree-il record(? or is it object?) <daviid>OT: anyone knows a privacy/free s/w respectfull site where one can upload a screencast (whiche are mp4 files)? I tried https://paste.rs/, where i can uplao images, but trying to uploas a screencast doesn't seem to work <daviid>rogerfarrell: nice, but the site won't play the mp4, if you try to browse, it triggers a download action, both using epiphany and librewolf