Post #2280774

2025-10-30 13:09 UTC

@jbert@hachyderm.io yeah the "if you know all the matching which needs to happen on a chunk" part is what I'm going back and forth on but the more I think about it the more I'm suspecting that I'm making things more complicated than they need to be. My worry is that it would be possible to write a group that produced match positions out of order once you account for extending the current "dot" forward and backward (covered in the paper). That said, I've not actually written such a structex so I need to check to see if that's even possible. If it's not then the design you're outlining should work I think? I have some thoughts on an implementation I'd like to try but I want to make sure I'm not just digging a hole for myself before I try it out(!)

Replies (1)

@sminez@hachyderm.io 2025-10-30 13:43

@jbert@hachyderm.io OK, found an example of what I'm talking about. This is VERY contrived and the output below is showing some debugging prints that fire when match actions are being collected followed by the final output when things are run in order. The input text is this: A bar baz B C baz bar D And this is the script: , x/ba\w/ { g/r/ /[A-Z]/ p/>$0\n/; } Output: ADD ACTION: Action { kind: Print, template: 0 } -> "B" ADD ACTION: Action { kind: Print, template: 1 } -> "A" ADD ACTION: Action { kind: Print, template: 1 } -> "C" ADD ACTION: Action { kind: Print, template: 0 } -> "D" >B >D< The original matches being found by "x/ba\w/" are sequential within the file, but the group branches are searching forward or backward from that initial position based on what was matched. It is (of course) fully valid to say that this sort of thing shouldn't be supported 😅

Open ##2280775