<div dir="auto">Thanks for the tip! Simply awesome feature. </div><div dir="auto">parse_transform would be preferable to save CPU cycles IMHO. </div><div dir="auto"><br></div><div dir="auto">/F.</div><div><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><br>On 19/02/2022 10:39, Frank Muller wrote:<br>
> Would it be possible to have a syntactic sugar(parse_transform)  for <br>
> wildcards:<br>
> <br>
> Ret=khepri:get("/stock/wood/_"<br>
> <br>
> instead of:<br>
> <br>
> PathPattern=[stock,wood,#if_node_matches{regex=any}].<br>
<br>
Hi!<br>
<br>
String-based paths are already supported:<br>
<br>
     1> khepri_path:from_string("/shoe/*/flipflop").<br>
     [shoe,{if_name_matches,any,undefined},flipflop]<br>
<br>
Most functions in the `khepri` module accept string-based paths. The <br>
`khepri_machine` functions don't however.<br>
<br>
I have plan to greatly improve the syntax and make `khepri_machine` <br>
accept string-based paths too so the API is uniform.<br>
<br>
That said, those paths are parsed at runtime. Would you find it <br>
convenient to have a parse_transform module so they are parsed at <br>
compile time?<br>
<br>
-- <br>
Jean-Sébastien Pédron<br>
</blockquote></div></div>