Fork me on GitHub
#meander
<
2021-06-14
>
jimmy16:06:28

Really interesting pattern you have there. I personally, haven't had that use case, so haven't really thought about it. Does it work with multiple of them nested? Might have to play around with it

markaddleman17:06:09

I wrote it for a very particular use case - "editing" XML

markaddleman17:06:44

I believe I have one nested use case and I haven't seen a problem. I'll look more deeply into it

markaddleman17:06:16

I got to thinking that the "edit" use case might deserve a DSL of its own. The DSL would be similar to m/rewrite but every "rule" would need to specify three things:

markaddleman17:06:37

1. a matching rule - just like the current rewrite LHS. the matching rule is used to capture values to be used later 2. the new value rule. this is similar to rewrite's RHS but a new value rule would only return a value that would be used to replace an existing node in the tree 3. a targeting rule. this is a rule that works similarly to matching rule but is used to locate the position(s) of the new value

markaddleman19:06:51

Oh, one more difference from rewrite: If no edit rules match, return the original form

noprompt22:06:42

I want to keep this alive too. The conversation about editing is important.

👍 2
markaddleman23:06:08

I will try to write up some code examples this weekend

markaddleman14:06:43

Picking this back up

markaddleman14:06:32

I played around with a new pattern match operator that I call edit. I tried getting it to work the way I describe above but I ran into a problem with recursion. I just couldn't find an intuitive way to express how to recurse when then target rule is different than the matching rule

markaddleman14:06:33

I'm back to believing that the edit use case is best served something like the within syntax. see https://clojurians.slack.com/archives/CFFTD7R6Z/p1623543354015700

markaddleman14:06:08

The within syntax that I wrote doesn't really follow the spirit of meander so I'm going to play around with a better cultural fit today.

markaddleman15:06:22

The problem with something like within is that it needs to introduce multiple matching variables each of whose names must match in the match-syntax phase and the subst-syntax phase. I think it would be safer if the pattern matching operator (`rewrite` in this case) provided some context that could be shared between the two macro expansion phases

noprompt18:06:48

@markaddleman That looks interesting. You didn’t come across as a snarky either. 🙂

🙏 2
noprompt18:06:32

I’ve done this before too but I confess that I hadn’t thought about doing it this way.

noprompt18:06:56

This actually makes me think that, among other things, we should be able to use & more than once in sequential types of patterns.

(& ?before <pattern> ,,, & ?after)

markaddleman18:06:49

that would be convenient

noprompt19:06:25

I think it makes sense and would be able to contribute more thoughts provided an example/sketch.

markaddleman19:06:03

I could play around with some example syntax and post here

noprompt19:06:03

Its certainly welcome. 🙂