On Fri, Nov 19, 2021 at 8:32 AM Marc Chantreux <e...@phear.org> wrote: > > [switch `($/)` signature to `($_)` and `make` to `.make:`] > > i dug around it but missed it! arggh ...
I've been digging around online doc etc and spotted that this is covered on the Traps page of the official doc: https://docs.raku.org/language/traps#Using_regexes_within_grammar's_actions The Traps page does *not* suggest topicalizing (changing `$/` to `$_`). I began to wonder if that was due to the concern I raised: > I've no idea where the `$/` that `S///` clobbers comes from. But I'm now pretty convinced that each new routine gets its own writable `$/` initialized to `Nil` which any regex operation (eg `S///`) is then free to use. So I tentatively conclude that topicalizing the match object argument is an appropriate idiomatic way to enable use of regex operations within an action method. (But you do need to be clear that you're using `$_` in the signature, not `$/`. In your exchange with Bill, you've been talking past each other about the fact you mistakenly wrote `$/` not `$_` in your method signature, despite saying you were showing him the topicalization solution I'd shared.) ---- > > But it draws you into the `$/` dance. > > The way I read you is "no" as i can't reassign inside a grammar. You can't *at the outer level* of *a regex/rule* . That's not quite the same thing as you've just said. I'll try to explain. ---- Raku automatically inserts a `$/` *symbol` into each regex or rule. It always makes it read-only, and you can't do anything about that. It also always binds a fresh match object to that `$/` symbol. And match objects are (shallowly*) immutable. So you can't re-assign or rebind the `$/` symbol at the outer level of a regex or rule, nor mutate the captures in the match object it's bound to. * (You can alter the `.made`/`.ast` attribute by using `make`/`.make`) ---- When you write an action method, its body is *not* a regex/rule. So you don't get an *automatically* inserted `$/` symbol. Instead, you have to introduce it. The norm is to write `$/` as a parameter, and to do so without an `is copy` trait. As such, it ends up being read-only, and bound to a match object, just like it is inside a regex/rule. But you're in control of declaring `$/` inside *GPL* blocks. Thus the topicalization approach we both like, or the `$/ is copy` that the Traps page suggests. Or you could write: ``` 'a' ~~ / . { print $/; $/ = 42; print $/ } / # a42 ``` This is why I qualified references to the `$/` symbol with "outer level". Where the `.` is the `$/` symbol is read-only and is bound to a match object that can only be altered by writing regex pattern code. But in the `{...}` block inside the regex, the `$/`, while still initially bound to the match object, is reassignable/rebindable. ---- > what i was expecting is to hack the grammar itself. While you can control what ends up in match objects, you can only do so by writing regex patterns which capture, or by hanging extra data off of match objects by using `make` (or `.make`). Note that the captures in a match object aren't strings as such. Instead they're from/to *indexes* into the matched string. So, whatever parse tree you end up with, all of its captures can only contain `from`/`to` indexes into the original input string. So you can't "lie" the way the Perl parser lies, or the way Marpa's "Ruby Slippers" feature does: http://blogs.perl.org/users/jeffrey_kegler/2011/11/marpa-and-the-ruby-slippers.html On the other hand, you *can* "just" create whatever *Alternative Facts* (Ruby Slipper like) syntax tree you want *on top of* the *Concrete* Syntax Tree aka parse tree. You can do that today -- as you know -- because that's precisely what `make` allows. cf the notion *Alternative facts Syntax Transformation* I just invented as another entry that could be added to the rather unusual answer to the Computer Science Stack Exchange Question: > Is "sparse subtree" an appropriate term for what I describe in this question? at https://cs.stackexchange.com/questions/95759/ is-sparse-subtree-an-appropriate-term-for-what-i-describe-in-this-question/114689#114689 ;) > your solution is really elegant :) -- love, raiph
