IRC channel logs
2023-03-29.log
back to list of logs
<RavenJoad>What is the (best) way to destructure and bind a tree structure? I have output from the PEG parser that I want to convert to an alist format (cons pair). Something like (convert-tag '(tag (tag-name "number") (tag-value "2"))) |- '(number . "2") <RavenJoad>I am using the sxml matcher, but that is a little clunky for when the tag-value is empty, which ends up producing '(tag (tag-name "number") tag-value) instead. <RavenJoad>I found SRFI-201, but wanted to make sure I was not missing something elsewhere. <haugh>RavenJoad, what about the structure of this tree isn't adequately addressed by (ice-9 match)? Can you provide some example input? <haugh>I'm not at all familiar with PEG (yet) but I welcome some tricky pattern matching <RavenJoad>haugh: That is exactly what I was asking about. I missed (ice-9 match) in my first search. I think that is really what I wanted. Some examples were provided in my earlier messages. <RavenJoad>I already got the PEG stuff working, so that's fine. <haugh>I recommend learning the provided pattern matcher very deeply. It is just ridiculously powerful. <RavenJoad>I figured it would be. I am a fan of pattern matching. I was just not sure which library had the pattern matching library. <RavenJoad>Is there an equivalence function for alists that is irrespective of ordering of elements in the alist? I want to use it for srfi-64 tests, so that changes in the alist ordering (but not changes in the values) is does not change the test outcome. <RavenJoad>That is definitely one way. I don't know though. I feel like Guile should have a way to compare two alists for total equality (these are short, if that matters). I know equal? is already there, and I can check each entry manually, but that feels a bit verbose. <lisbeths>I am trying to takea number which is encoded as an integer in the church encoding and to convert it back to an ordinary integer then print it <lloda>that isn't really what you want either, but it's closer <dadinn>I forgot how to simply do partial application in guile. Can't find any `partial' procedure! Is it in one of the SRFIs? <cow_2001>dadinn: i use the cut thing in srfi... let's see... <cow_2001>srfi-26 and ((compose a b c) x y z) = (a (b (c x y z))) <cow_2001>can modules not have numbers in their names? <sneek>I've been running for 11 days <sneek>This system has been up 1 week, 4 days, 16 hours, 45 minutes <cow_2001>is there absolutely no way of including numbers in module names? <haugh>scheme@(guile-user)> ,module 2foo2furious <RavenJoad>lloda: Thanks! (lset= equal? actual-parse %expected-bibtex-parse) worked how I wanted. It seems that lset= will do what I want for now. <cow_2001>haugh: could you try putting a dot in the module name? <pinoaffe>dadinn: there's srfi-26, but there's also just doing (lambda (a) (+ a 3)) - a bit more verbose, but a lot more flexible <RavenJoad>Is there a way to change the equality function used for srfi-64 tests? I want to use lset= rather than eq/eqv/equal. <RavenJoad>I guess I could define my own using test-assert as a base... <RavenJoad>I just figured that out. Thanks again haugh! <haugh>pinoaffe, even with λ, I find ad-hoc lambda syntax visually noisy, because it adds a parenthetical layer and requires an arbitrary binding. It's not usually an issue, but as I lean into HOF-oriented code, I find it constantly and subtly itchy. cut/cute are limited in that you can't specialize in subforms or re-order parameters, and it's a bit of a visual jump to move the called procedure to the second position. <haugh>SRFI-235 is very good for this problem because it conventionalizes a lot of common high-order behavior <haugh>But even with 235, I find myself sketching anaphoric reader syntax <pinoaffe>haugh: I personally have a certain preference for point-free, HOF-based programming, but as of late I've come to doubting whether a "lambda" here and there might be more readable than the stuff I tend to produce when I heavily use cut{,e} <pinoaffe>ooh, I didn't know srfi-235 had been finalized, that's neat <haugh>I definitely agree with you in the "here and there" case, but I also think there's a line at which I'm more distracted by the layers than I am aided by the explicitness <pinoaffe>I guess we are mostly in agreement, then :) <haugh>I think I'll make srfi-235 my first foray into guix packaging SRFIs, after I get some stuff off my plate <haugh>pinoaffe, if you're into it, the discussion archives for SRFI-235, especially between jcowan and mnieper, are an amazing read. I learned a lot. <RavenJoad>haugh: I have (define (test-lset= test-name expected expr) (test-assert test-name (lset= equal? expected expr))), but I get Wrong type to apply: #<syntax-transformer test-assert> when I try to use it. <RavenJoad>I know it should work, because manually using the body of test-lset= works. But using the test-lset= procedure yields that error. <haugh>RavenJoad, are you familiar with the macro systems? You would need to either define test-lset= in terms of syntax or manually write it into every invocation of test-assert. <RavenJoad>Oh... I thought a function would be enough. Ok. The most I have used macros for is define-syntax-rule to create with-thing bodies, but that is it. <RavenJoad>Switching define -> define-syntax-rule was enough to make it work. Thanks for the pointer!