Re: [Cbor] Regular expressions

[Joe Hildebrand <[e-mail]>]

> On Feb 28, 2021, at 4:24 PM, Carsten Bormann <[e-mail]> wrote:
> 
>> In ECMAscript land 'gimsuy' are all valid.
> 
> But g, for instance, is not an RE modifier.  It modifies how the operations are using it, but not the RE itself.  Similar for y.  u is really enabling syntax for decoding unicode, so it should not be visible during interchange (of the decoded RE).

Hm.  I understand your point, but round-tripping the objects intact is more important to me than which part is technically part of the regex.

>> Nod.  We'd probably need a small registry then, with the names or a code.  I would expect the semantics are "use this if it's a type you know about, otherwise, keep the tagged version and punt to the application layer".
> 
> Right.  But why not use tags for those?  We already have that registry.
> 
> (We could write a common document that we expect new RE tag registrations to reference, so there is some structure to this.)

That works for me.  So, there would be an "ECMAscript RegExp" tag then, right?

>> No argument, but I use regex's every day, and ABNF or a full PEG grammar just when I need to get out the big hammer.
> 
> REs are certainly more amenable to interchange as such.
> 
> I need to fix up my ABNF to RE compiler…
> (Which is almost trivial – as long as the ABNF is not recursive – but the current version generates way too much noise that a manual RE writer would know how to avoid.)
> 
> I’m also on the lookout for a toolkit for translating between the various RE dialects.

I bet the regex101 folks have a starting point for that.  Does anyone have a contact there?

BTW, one of the reasons all of this has come up for me is I've been tinkering with Basura (https://github.com/hildjj/basura/), a library/CLI for generating random trash JS that is syntactically valid, but otherwise useless.  I just released it this morning, and I've learned a few interesting things about my CBOR implementation by tying the two together.

— 
Joe Hildebrand