11:28 PM
perhaps. I think that maybe the array should be implicit, and that we shouldn't assume the language's array looks like [x, y, z]
since we seem to be using {...}
to be a matched expression, we could likewise use ${n,k}
to denote the usual sense
since we are making our own dialect as it were, we could add xor in addition to alternation
wait nvm that doesn't make sense
+ and * are in their usual sense
{...} is a literal. Ideally, the inside would represent code in the parent language, but it is also possible to define a small language capable of most computation that would be used in a regex, in the event that the parent language has no easy way to eval
. (I'm not sure if this would be the case with compiled languages.)
That, or we could leave it up to implementation. In any event, it couldn't be passed straight to eval, since we plan to have \1
and \2
be valid identifiers. We could modify it per language, e.g. $1 + $2
.
We may wish to define a language, in this case, for consistency...