IRC channel logs
2024-06-11.log
back to list of logs
<cpli>i've been using this definition a bunch: `(define-syntax-rule (curry form args ...) (lambda x (apply form args ... x)))` <flatwhatson>technically it's not currying, hence the name, explained in detail in the SRFI <flatwhatson>it's worth knowing the standard approach in case you see it in the wild; encountering cut can be confusing at first, and it turns up reasonably frequently in guix <cpli>flatwhatson: exactly the reason i posted it here, thank you! <cpli>i was going to write: "am i missing something already available that allows for similar behavior" but i didn't quite know how to put it <cpli>i even wrote a.. worse macro that does it for `n` arguments <flatwhatson>i think your define-syntax-case doesn't work? honestly better to stick to the long form, macros are tricky enough <flatwhatson>or is it reusing name as the syntax object... bit confusing anyway! <graywolf>Hello Guilers, what would be a nice way to test syntax-case? I know there is test-read-eval-string in srfi-64, but I would need something like test-read-string (I explicitely do not want the eval). <graywolf>Is there such a function somewhere in guile? <bjoli>You could extract the syntax transformer and test it on systax objects <graywolf>Basically I would like to verify that the syntax transformer, well, transforms the source expression A into expected expression A' <bjoli>then you can do what I did above. <graywolf>So, for example, (test-read-string "(inc1 x)" '(+ x 1)) for example <graywolf>Right, so I guess there is nothing built-in directly. Thanks for the suggestion, will do more reading on it <graywolf>My understanding of what "syntax object" is bit vague still :) <bjoli>for something like that you can probably rely on the result :) I have forgotten how to get the syntax transformer from a macro, but then you can probably just do a (syntax->list ...) and test-eq to (my-expression (a b c) 2) <bjoli>but why not just test the output? <graywolf>In my case I want to write (sh ...) macro for ergonomic shelling out. So test-read-eval-string would involve calls to system*, which I would like to avoid <graywolf>syntax->list looks like a promising lead, thanks :) <bjoli>and you want (macro-transformer) <bjoli>but one thing: syntax objects are NOT just a list of symbols. <bjoli>When you start doing syntax->datum and datum->syntax you are entering a world of pain <bjoli>if you just want to validate that a transformer produces an expression, you are fine. But when you start going back and forth things break in werid places <graywolf>Ah, but I am looking forward to the pain. ^_^ <bjoli>I believe you will have to write syntax->list yourself, but that is simple <graywolf>Hm, it seems that ,exp uses (decompile (compile ...)) call <graywolf>Any opinion regarding how it compares to the above? <bjoli>but if you want to run things in the shell, you will probably end up using open-pipe <graywolf>yeah probably; I will want to capture the output (sh "base64" #:< "some string" #:> 'posix) so yeah, I will probably use open-pipe* <graywolf>The goof-loop looks interesting, albeit complex <bjoli>graywolf, pipe won't let you close the input port and read the input port iirc. <bjoli>I ended up always using open-process that is internal to the popen module <graywolf>I hoped it would with OPEN_BOTH mode... more experimentation is needed it seems <bjoli>you could have a look at the open-process procedure from the popen module. <bjoli>but it is internal so you will have to use (@@ (ice-9 popen) open-process) or semithng like that. I don't know if the pipeline procedure will do what you want though. <bjoli>Now, time to go back to work. <graywolf>Enjoy the work and thank you once more :) <graywolf>Hm, I see, so open-pipe* abstracts over the fact that there are two separate ports using the make-rw-port procedure. So there is no way to close just one of them. It seems using open-process directly would indeed make sense. <graywolf>I wonder if it should not just be exported, it looks useful. <jpoiret>bjoli, graywolf: have a look at spawn instead <graywolf>jpoiret: Right, that looks like what I need? I wonder why open-pipe is not implemented using spawn. Is that just a historical artifact, or are there things open-proccess (or piped-process) can do which spawn cannot? Looking just at the api, it looks like spawn is superset of piped-process. <jpoiret>since spawn was introduced, open-pipe is use spawn internally <jpoiret>maybe there's an indirection in C code <graywolf>Hm I see open-pipe -> open-pipe* -> open-process -> piped-process <graywolf>In piped-process there is do_spawn call though <jpoiret>ah yeah, that's the indirection I was thinking of <graywolf>I just mostly wondered why piped-process is needed at all <rlb>graywolf: ...another option might be to make it two macros, the lower-level one takes system* as an argument, then you can replace that with something else during testing. The top-level one then just calls the lower level one with system*. <graywolf>rlb: Right, that would work as well. I will probably try the (decompile (compile ...)) way first (because it will be more generic and (possibly) work even with macros not under my control), but will definitely keep this in mind. <graywolf>There are so many ways to do everything :D Sometimes it is pretty hard to pick the best one.