***amiloradovsky1 is now known as amiloradovsky
<nerdypepper>i am looking to use trace to look at the outputs of recursive procedures ***pc is now known as Guest94276
<wingo>nerdypepper: search for "trace" in the manual <wingo>if you are at the repl, use ,trace <RhodiumToad>so I'm curious: there are several syntax variants for dealing with binding to the result of a multiple-value function, are any of them commonly preferred over the others? <RhodiumToad>so far I see, besides call-with-values itself, define-values, srfi-8 (receive ...), srfi-11 (let-values ...), srfi-71 (let ...) <amz3>RhodiumToad: call-with-values is more general I think (call-with-values thunk (lambda args args)) will return multiple values as a list. <amz3>there is receive that is quite popular, but I prefer call/values <RhodiumToad>yes but it's also rather clunky syntax, especially when mixed in with other bindings in a let <lloda>sometimes receive looks better than let (((values ... if you only have one, but I don't use let-values after having srfi-71 <RhodiumToad>receive also has the drawback of being its own thing <RhodiumToad>so far I've been tending to use receive when there's just one, and srfi-71 when there's other bindings to do at the same time <amz3>IIRC there is paper about call-with-values / receive that recommends yet-another form. I don't have the paper at hand. <chrislck>srfi-71's values->list is a nice one... can pack multiple values and (let*) can unpack them <lloda>173 would look ok with call-with-values chrislck <lloda>(call-with-values (lambda () ...) cons) <amz3>l173, is equivalent to (call-with-values (lambda () (partition ...) cons), imo in L264 I would split the big let* into two lets with a call-with-values in between them. <lloda>the thunk is a bummer sometimes <lloda>and you lose some explicitness in what the values mean <amz3>I seldom use let-values and define-values <amz3>at the REPL define-values can be handy, but guile REPL with $fu is good enough <lloda>cannot put the $fu in scripts tho <lloda>I remember some discussion about having $-1 etc. in the mailing list <wingo>i like call-with-values and let-values / let*-values, fwiw <wingo>just a personal preference tho <wingo>guile doesn't compile define-values very optimally right now but perhaps that's fixable <RhodiumToad>I have use-cases like (let* ((x y (compute-coords blah)) (thing1 (make some-gui-object x: x y: y)) (thing2 ...)) <lloda>I have a lot of code like that RhodiumToad <RhodiumToad>using call-with-values or receive would mean another nesting level for no especially good reason <lloda>srfi-71 made it look a lot better ***pc is now known as Guest52574
<wingo>i am curious to know when i will permit myself to use "define" instead of "let" :) <jcowan>SRFI 11 is part of R7RS; SRFI 71 is compatible with it bu tnot part of it, and it's less widely supported since it involves redefining a standard Scheme macro. <RhodiumToad>that's unfortunate, since I think I agree fairly strongly with srfi-71's rationale for why srfi-11 is bad <lloda>we cannot have (define (values ...) (values ...)) so it isn't an uniform pattern unfortunately <RhodiumToad>in particular, let-values does not work nicely for the case I described above <lloda>you'd have to put parens on every single value case yeah <RhodiumToad>it'd have to be (let*-values (((x y) (compute-coords blah)) ((thing1) (make ...)) ((thing2) (make ...))) ... <jcowan>Multiple values contradict the functional mental model in which most of Scheme is written (the same with call/cc). I hope to get SRFI 8 into R7RS-large, as it has the nice property of working in most of the cases (even if it is voted down, it's a 5 line syntax-rules macro <RhodiumToad>I only recently picked up scheme seriously (though I have on-and-off experience of various lisps, mostly _not_ using multiple values), but for whatever reason I've found myself using multiple values a lot <jcowan>It's hard to remember when writing a procedure with a functional argument to ask "What should happen if the passed function re-enters me unexpectedly?" <jcowan>for this reason, map guarantees that previous results returned will not be mutated (so the final result can't be built up by mutation) <jcowan>and the same for vector-map, which therefore needs to build up a list and call list->vector at the end. ***apteryx_ is now known as apteryx