IRC channel logs
2023-11-20.log
back to list of logs
<festerdam>It appears r⁷rs only requires that the scheme implementations provide all possible cxr macros to a depth of 4. Is there a way to go deeper (besides chaining the macros)? I need to run (cadadadr my-tree). Maybe I shouldn't even be doing whatever I'm doing that requires me to use such a deep cxr macro. If that's the case, what would be the proper way to access specific subtrees of a tree? <flatwhatson>you can de-compose cxrs however you want, or define your own cadadadr <superkamiguru>Hey all, working on a cli tool written in guile and had a question (if this is a good place to ask, if not I apologize). I am trying to execute a shell command and evaluate the response. It looks like "system" works well for executing a command, but returns the status code instead. Is there a good way to retrieve the actual output from the command? <superkamiguru>Ah thank you! I appreciate the assistance (am still fairly new to guile) <festerdam>flatwhatson: I've heard that overusing cxrs is bad practice. And it indeed appears to make the code messier. My code now contains a lot cxr chains. Is something one should be doing instead, for the sake of code readability? <flatwhatson>festerdam: "it depends". what are you building? generally it's better to represent data with records, if you have a tree structure then it might make sense to use lists with records as leaves <flatwhatson>but you wouldn't normally need really deep cxr access even then; you'd traverse the tree with loops <festerdam>flatwhatson: Thanks! Yeah, I'm working with tree, so I'll look at records. <RhodiumToad>sometimes there are reasons to prefer lists over records <RhodiumToad>but if so, rather than rely on relatively opaque cxr chains, it would be worth defining macros with names that reflect the actual semantics rather than just the structure <haugh>what does the error message "unhandled constant" mean <haugh>until I learn otherwise I'm going to say it means "too based", /id est/ the compiler was disrupted by the sheer gravitational mass of my frontal lobe <lloda>i've seen this error trying to create a literal of struct type <lloda>i don't understand your code tho <apteryx>ACTION goes back trying to fix that 'include' issue more thoroughly <samplet>apteryx: I’m about to send a patch for your R7RS 'rename' bug. <samplet>apteryx: Done. May I ask about your interest in R7RS? Is it about the SRFI integration work you’ve been doing lately? <apteryx>Ideally I can drop .sld libraries in the source tree without a change <apteryx>which already works after the include fix, when rename is not used <apteryx>so having rename will be another step toward reusing .sld without the need for modifications <apteryx>another longer term goal would be completing the missing (scheme x) modules <apteryx>I think (scheme comparators) doesn't currently exist for example <apteryx>that seems to be just exporting the SRFI's I'm adding at the right places <apteryx>then we could claim and document Guile as R7RS ready, unless I'm missing something else <apteryx>samplet: the patch looks nice, thanks! I'll try it later <samplet>“Today I Learned.” It comes from Reddit culture (I’m not a Redditor, but it has seeped into general usage.) <samplet>I’ve been writing a lot of R7RS lately to explore its potential in the bootstrapping space. <samplet>It’s a pretty good little standard. The R7RS-Large work seems to be pretty thoughtful, too. <apteryx>just the top level organization of imports, which is what it's mostly about, is very welcome <apteryx>(import (scheme comparators)) is nicer than (import (srfi some-integer)) <apteryx>is there a reason why Guile prevent a module including a number in its name? E.g. (import (srfi 64)) works on most Schemes, but not Guile, which complains 64 is not a symbol <apteryx>which is why we need the annoying to type (srfi srfi-64) alternative instead <haugh>Actually I was assuming this was a bug with with-syntax but you don't even need that: <haugh>(define-syntax foo (let ((c identity)) (lambda (stx) (syntax-case stx () ((_) (datum->syntax #'stx c)))))) <samplet>haugh: My best guess is that a procedure is not really “syntax”. You can’t send an existing procedure object to the evaluator. It’s a syntax error. <samplet>In other words, “'symbol” is a constant. A procedure is not. Hence, “unhandled constant”. <haugh>so why does ,optimize(break) return the procedure? <samplet>Because the frontend can expand the macro back into the procedure object. That part is fine. The problem is that a procedure object is not valid Scheme code. <haugh>Well that's disillusioning. At least I can move on now. Thanks samplet. <samplet>apteryx: It looks like the R6RS compatibility layer converts N into srfi-N. In R7RS mode, Guile can handle ‘(import (srfi 64))’. <samplet>The basic idea is that macros have to return Scheme code. <samplet>There’s no way to represent a closure as Scheme code, so no embedding closures in the output of macros. <samplet>It would be the same with a port, if that’s easier to reason about. <haugh>I'm really struggling with what you mean by "Scheme code". Do you mean one of the intermediate representations on the way down to bytecode? <samplet>Not quite. When using ‘syntax-case’, a macro transforms a syntax object into a syntax object. It’s a source to source transformation. <samplet>You can manipulate procedures and ports and whatnot in a macro, but Guile will be mad if you try to pass those things off as code. <haugh>Well in a way it's nice to find the ceiling. Thanks for the explanation, I would have spent the rest of the day on this and left a bunch of angry comments in the code. <haugh>You basically just told a kid the truth about Santa Claus today, samplet. Hope you're happy. <samplet>Sorry! It’s limit imposed by wanting to be able to expand code independently of running it. <samplet>In some Schemes, it might be possible. If you are willing to mix the expander environment and the runtime environment, you can get away with it. No ahead-of-time expansion or compilation, though.