IRC channel logs

2021-07-09.log

back to list of logs

<iskarian>Is there a way to have an optional (part of a) pattern in an ice-9 match?
<iskarian>Or do you just write a new branch?
<flatwhatson>iskarian: do you have an example of what you're trying to achieve?
<iskarian>flatwhatson, I want to match something like ('replace ('path path) ('version version) '=> ('path new-path)), where ('version version) may or may not be present
<iskarian>Ideally I'd like to provide a default value for version if it is not there
<flatwhatson>iskarian: have you considered just using a function with optional arguments?
<flatwhatson>iskarian: you can use "or" and "..." to represent some kinds of optional patterns
<flatwhatson>this works: ('replace ('path path) ('version version) ... '=> ('path new-path))
<flatwhatson>if you're happy to receive version as a list, and have a loophole that multiple versions could be provided!
<flatwhatson>i can't work out how to do "zero or one" instead of "zero or more" though
<iskarian>you're brilliant! I didn't even think of just passing off to a fn with optional arguments
<iskarian>ah, it's fine if it can technically take more, since the parser feeding this only accepts one anyway
<flatwhatson>yeah keyword arguments might be a bit more straightforward if you're in control of the syntax
<iskarian>this though... this is why I find match syntax absolutely impenetrable: ('replace ('path path) ('version version) ... '=> ('path new-path))
<iskarian>how does the ... make the previous pattern optional?
<flatwhatson>... is like regex *, zero or more matches of the previous rule
<iskarian>Ahhhhh
<flatwhatson>implicitly promoting all of the affected bindings to lists
<iskarian>okay, that makes sense. My best approach before asking was ('replace spec ... '=> ('path new-path)) and then using assoc-ref or such to pull apart spec later. I had no idea why the ellipsis worked though!
<sarna>"the implementation of continuations in Guile is not as efficient as one might hope, because Guile is designed to cooperate with programs written in other languages" - is that true only for call/cc, or for delimited continuations too?
<civodul>sarna: wingo would know better, but i think that applies to call/cc
<civodul>there cannot be C stack frames in the middle of a delimited continuation
<taw10>That was my interpretation of that part of the manual as well. Two paragraphs later it explicitly says to use prompts instead where possible
<taw10>call/cc inefficiency doesn't only apply to Guile. It's overkill for most things in any Scheme implementation (see e.g. http://okmij.org/ftp/continuations/against-callcc.html)
<civodul>yeah, call/cc is not very useful
<sarna>I see, thanks civodul
<sarna>IIRC only chicken has fast call/cc because of the way their VM works
***chris2 is now known as Guest6866
<dsmith>sarna: There are some call/cc implementations that are *very* efficient. Like if your call frames are heap allocated lists. A call/cc is just pointing to a different list. Not compatible with C, however.
***chris is now known as Guest7372
***Guest7372 is now known as chrislck
<dsmith-work>Happy Friday, Guilers!!
<vijaymarupudi>Happy Friday to you too :)
<sarna>dsmith: not compatible with C FFI you mean?
<dsmith-work>sarna: Yeah, C->Scheme->C or Scheme->C->Scheme.
<dsmith-work>sarna: Often it's copying around the processor stack.
<ArneBab>dsmith-work: wasn’t the problem of call/cc that it is more powerful than expressive, so it doesn’t actually reduce complexity?
<sarna>dsmith-work: got it, thanks
<ArneBab>And that it does not match the requirements of hardware, so it forces slowpaths?
<dsmith-work>ArneBab: Yeah, there is that too.
<dsmith-work>I've never used call/cc much (becase the thought of copying whole stacks back and forth just makes me shudder)
<ArneBab>dsmith-work: yes …