Fork me on GitHub
#events
<
2022-11-02
>
bruno.bonacci12:11:37

Hi all, the recording of last night's event is now available on YouTube Transform anything with Pattern (by Darrick Wiebe) https://www.youtube.com/watch?v=1V0VNBgWokA

🙏 1
wow 1
Darrick Wiebe13:11:25

Thanks for inviting me, it was fun presenting!

walterl00:11:01

Pattern looks amazing! 🤯 wow

😄 1
Martynas Maciulevičius14:11:17

I don't get the order of the evaluation. Somebody said it's similar to Meander but then there shouldn't be order in the computations. But then in the example we have (down (add 1 2 3)) and get (down 6) as a result. So wait a second, then there is an order of computation and this order is defined from the input itself. The operations are weird :thinking_face: Edit: Probably this is the point of the directed operator so that you could control how the expression would be handled. It's still weird in other places, like in the example with (?x

Darrick Wiebe17:11:19

Someone said they thought it's similar to Meander, but actually it is not. I think starting with meander is not a good way to understand how Pattern works. Rules are evaluated in order from first to last. The directed combinator allows you to descend selectively into the data structure. When you choose to descend, the child data is matched against starting from the first rule in the directed combinator. After the child data has been processed, the matching of the structure that contained it resumes, now containing the potentially updated child data.

Martynas Maciulevičius19:11:05

I'm watching the talk for the second time 😄 I think I finally get something. You could do some similar things as Meander does (talking only about data transformation), but IMO the approach is that you have this rule system and that basically means you're supposed to "hook into the internals" whereas Meander has everything hidden from you (I probably don't know Meander that much too). Edit: Also I see that the Meander-like substitution is supposed to be small-ish (at least in the example with arithmetic). And instead you combine multiple passes of rules into one larger program :thinking_face:

Darrick Wiebe20:11:05

The key is that the rules are high level composable units. They're definitely not to be considered internals! 🙂

Darrick Wiebe20:11:56

You're right that most rules (in my experience) are quite focused on one or two levels of source data for the match. There is no restriction to how big and complex your matcher can get, but typically the descent and iteration rule combinators save you from having be super specific about how to traverse through multiple layers of data.