IRC channel logs

<cow_2001>O_O

<cow_2001>inching https://codeberg.org/kakafarm/guile-srfi-123

<dsmith>sneek, macro-examples is https://www.scheme.com/tspl4/syntax.html#./syntax:h4

<weary-traveler>mwette: thanks for that reference

<freakingpenguin>Is (ice-9 getopt-long) the recommended way to handle cli arguments or is there a more featureful alternative? e.g. formatting the help output.

<rlb>freakingpenguin: perhaps also see https://www.gnu.org/software/guile/manual/html_node/SRFI_002d37.html

<daviid>freakingpenguin: fwiw, i use (ice-9 getopt-long), which imo is quite feature full - probably a matter of taste, but i prefer it to the srfi - guild nd its scripts uses it as well, if you need some example to start with - https://git.savannah.gnu.org/cgit/guile.git/tree/module/scripts/compile.scm

<daviid>actually, that is using srfi-37

<daviid>let me find an example

<daviid>freakingpenguin: here, a guile-ssh example - https://github.com/artyom-poptsov/guile-ssh/blob/master/examples/sssh.scm.in

<freakingpenguin>rlb davidl: Thanks! I'm coming from Ruby's OptionParser which tidies up things like version/help logic for you, but seeing how Guile's getopt-long is used in a real project helps.

<daviid>freakingpenguin: caution, guild (guile's main script so to speak) uses (basic use) getopt-long, but the compile (sub)script actually uses the srfi-37 - caution when you evaluate, those api's are diff

<dthompson>I have used srfi-37 and optionparser years ago and I think srfi-37 is better

<daviid>dthompson: probably, my experience is more out of 'sticking to what i was doing', so i'll trust your judgment

<dthompson>I haven't used getopt-long in any serious capacity so no comment there

<freakingpenguin>dthompson: Why the preference for srfi-37 over optionparser? Any chance you remember?

<dthompson>optionparser was really procedural and kinda odd to me. srfi-37 is more declarative, functional

<dthompson>I like how with srfi-37 I can just setup an alist of default options and then fold over what the user passes in

<daviid>that's what the compile guild (sub)script does, fwiw - see parse-args i the script module def

<daviid>anyway, good luck, back to hack ...

<jason>anybody have a way for geiser to reload all guile modules within a path?

<graywolf>Hello :) Would someone have an example of how to print a stack trace for an exeception inside the handler in with-exception-handler? I was not able to figure it out from the manual :/

<cow_2001> http://0x0.st/8iT_.RSh8GEtT

<cow_2001>it should crash in the second one

<cow_2001>or error

<cow_2001> https://0x0.st/8iTO.B7CQll2u

<cow_2001>oh oops. someone on #scheme quoted the "Error situations and unspecified behavior" section and it specifically says it is allowed

<elpogo>that same someone in #scheme also said that "(let ((x 2)) (letrec ((y x) (x 3)) (+ x y)))" should return 5 according to the rnrs specs, but in the guile repl it prints 6.

<cow_2001>zipheir, if anyone wonders

<graywolf>elpogo: Hm. Do we have a bug report for that?

<graywolf>I think I agree 6 is not correct.

<graywolf>However "should return 5" is also wrong. Honestly what chicken does (crash) is imho the correct way to process that expression.

<mwette>Why? I'm seeing 5 as the right answer; sounds crazy to generate an error.

<mwette>Oh, wait. Maybe it should be 6. Need to go back and read.

<graywolf>So it seems this is an undefined behavior, so *any* answer is correct after all.

<graywolf>Personally I would prefer to get an error, but meh

<elpogo>graywolf: it mentions in the comment on https://www.gnu.org/software/guile/manual/html_node/Local-Bindings.html that it's unspecified

<graywolf>Honestly I would not get that from our docs.

<graywolf>> Note that while the init expressions may refer to the new variables, they may not access their values.

<graywolf>I would understand that it as "would cause an error", not "undefined behavior"

<graywolf>But yes, now that I know what to look for, I see it there.

<elpogo>also, you will get an error if you use the guile interperter instead of the compiler

<elpogo>",option interp #f"

<elpogo>graywolf: search on that page for "The behavior of the expression above is unspecified"

<elpogo>the comment for the example in the letrec* section mentions the unspecified behavior of letrec

<graywolf>Ugh, did not occur to me to look for it in an example for letrec*, I give you that

<elpogo>yeah it tripped me up earlier when i was trying to find it (i knew i'd read it before, so i knew it was there somewhere)

<sneek>mwette: Greetings!

<mwette>equivalent according to TSPL4: https://paste.debian.net/1342448/

<elpogo>makes sense mwette . convert_assignment in libguile/expand.c does something similar and does raise an error. so does the eval.scm interpreter. only the compiler returns a value

<mwette>I see now. The error is adding #f. I thought "error" before implied syntax error.

<mwette>The letrec gives 6. But the equivalent form w/ let+set! gives an error.

<jmes>I believe I've done this before but I can't remember how to do something like this: (define (symbol-append 'foo- 'bar) 'baz)

<jmes>Context: writing a macro to define some functions, the names of which need to be generated

<jmes>I get source expression failed to match any pattern in form ...

<jmes>Specifically something like:

<jmes>(define-syntax-rule (define-parser type)

<jmes> (begin

<jmes> (define ((symbol-append type '-parser) data)

<jmes> (do-something-to-parse data))

<jmes> (define etc etc)))

<mwette>jmes: I think you need to use syntax-case for that. e.g., https://paste.debian.net/1342461/

<mwette>where tid is a syntax-object to use w/ datum->syntax; args can be string, symbol or identifier

<jmes>mwette: Thanks, I'll digest that for a second 😅

IRC channel logs

2025-01-04.log