nmichel/ejpet

Matching JSON nodes in Erlang

ejpet's Issues

Migrate to rebar3

Publish as Hex package

Add support for JSON backend jsone

https://github.com/sile/jsone

generators fail when expression contains regex and some options are given

Erlang re:compile/2 function doesn't appreciate options it doesn't know about 😅

option 1 - filter options to keep only those allowed by re:compile/2
option 2 - extend expression grammar to allow passing option in the regex matching expression
e.g. #"catch_me"(op1, op2, op3=value)

options2 is better because it allows different sets of options for each regex matching subpart in an matching expression

Global search marker /g when used with */ and **/ shorten matching expressions gives ambiguous expressions

Expression */**/42/g is ambiguous.

It can be read either

*/ ... /g

or

... **/42/g

The erlang parser associates the marker to the nearest expression (**/42, in the example).
But the javascript port of ejpet (jjpet) associates it to the outer expression (*/, in the example).

Add specifications to API functions

Caching should be fully optionnal

Currently functions generators always refer to the caching stub. This should be an option : there must be an expression compile-time option to bypass the caching stub ...

[true, "foo", true] should match [*, true]

Both following calls should yield {true, []}

ejpet:match("[false, 42, true]", "[*, true]") => {true, []}
ejpet:match("[true, 42, true]", "[*, true]") => {false, []}

There is something wrong when the last matching expression ("true") is matched by an element before the last one.

Empty list [] should *not* match [_] nor [*, _]

Add the ability to capture "default" value

When a sub-expression does not match, but is nested in a capture expression, add the ability to define a default captured value.

This allows for "regularized" captures sets (with the same length, essentially), hence easing batch processing of captures sets.

syntax suggestion: (?<my_cap>_ | null) where

• |is the separator
• null is the default value.

Allowed default values:

• null
• true
• false
• a number
• a string

Should we consider using injection for the default value ? Could be interesting ...