Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #40103 > unrolled thread

Re: Verbose Regular Expressions

Back to article view | Back to comp.lang.javascript

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Verbose Regular Expressions "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-05-24 19:23 -0700
    Re: Verbose Regular Expressions Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-05-25 03:02 +0000
      Re: Verbose Regular Expressions "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-05-25 11:58 -0700
        Re: Verbose Regular Expressions Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-05-25 19:36 +0000
          Re: Verbose Regular Expressions "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-05-25 12:40 -0700
          Re: Verbose Regular Expressions Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2021-06-08 19:35 +0200
            Re: Verbose Regular Expressions Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-06-08 17:48 +0000
              Re: Verbose Regular Expressions Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2021-06-08 20:04 +0200

#40103 — Re: Verbose Regular Expressions

On Monday, May 24, 2021 at 3:28:38 PM UTC-5, Jon Ribbens wrote:
> I've just published an npm package: 
> https://www.npmjs.com/package/verbose-regexp 
> 
> It provides a way to use verbose regular expressions in JavaScript and 
> TypeScript, similar to re.VERBOSE in Python. It provides that white-space 
> at the start and end of lines are ignored, as are newlines, and anything 
> following // to the end of the line. 
> 
> It allows you to easily write multi-line regular expressions, and to make 
> your regular expressions more self-documenting using formatting and comments. 
> 
> Example: 
> 
> import { rx } from 'verbose-regexp' 
> // or: const { rx } = require('verbose-regexp') 
> 
> const dateTime = rx` 
> (\d{4}-\d{2}-\d{2}) // date 
> T // time separator 
> (\d{2}:\d{2}:\d{2}) // time 
> ` 
> console.log(dateTime.exec(new Date().toISOString())) 
> 
> You can use regular expression flags by accessing them as a property of rx, 
> e.g.: 
> 
> const alpha = rx.i`[a-z]+` 
> 
> Any comments or thoughts would be appreciated.

It's a useful feature definitely. I'm surprised it hasn't been advanced as a proposal yet for ECMAScript.

There has been limited discussion:

<https://esdiscuss.org/topic/regexp-x-flag>

Your #1 competitor is XRegExp which has the 'x' flag:

<https://xregexp.com/>

Were you aware of this library? What is your differentiating contribution?

[toc] | [next] | [standalone]

#40105

On 2021-05-25, Michael Haufe (TNO) <tno@thenewobjective.com> wrote:
> On Monday, May 24, 2021 at 3:28:38 PM UTC-5, Jon Ribbens wrote:
>> const alpha = rx.i`[a-z]+` 
>> 
>> Any comments or thoughts would be appreciated.
>
> It's a useful feature definitely. I'm surprised it hasn't been
> advanced as a proposal yet for ECMAScript.
>
> There has been limited discussion:
>
><https://esdiscuss.org/topic/regexp-x-flag>
>
> Your #1 competitor is XRegExp which has the 'x' flag:
>
><https://xregexp.com/>
>
> Were you aware of this library? What is your differentiating contribution?

I was not. So now I am, my answer would be:

  * XRegExp is over a hundred times larger
  * the syntax for mine is more compact and readable
  * XRegExp requires double-escaping, making it even harder to read
  * my package is discoverable using the sort of keywords I would
    search for, which XRegExp is not ;-)

(XRegExp has the disadvantage that it is trying to retro-fit features
which are otherwise unavailable pre-ES6, which my library is not.)

Honestly, even if I was aware of XRegExp before I wrote my package,
I would probably have written it anyway - XRegExp is just too enormous
and heavyweight for the simple requirements I had. My library is 9 lines
of code (not including blank lines and TypeScript cruft), XRegExp
is thousands of lines of code, without even counting its dependencies.
And the double-escaping thing is unacceptable.

[toc] | [prev] | [next] | [standalone]

#40132

On Monday, May 24, 2021 at 10:02:36 PM UTC-5, Jon Ribbens wrote:
> I was not. So now I am, my answer would be: 
> 
> * XRegExp is over a hundred times larger 
> * the syntax for mine is more compact and readable 
> * XRegExp requires double-escaping, making it even harder to read 
> * my package is discoverable using the sort of keywords I would 
> search for, which XRegExp is not ;-) 
> 
> (XRegExp has the disadvantage that it is trying to retro-fit features 
> which are otherwise unavailable pre-ES6, which my library is not.) 
> 
> Honestly, even if I was aware of XRegExp before I wrote my package, 
> I would probably have written it anyway - XRegExp is just too enormous 
> and heavyweight for the simple requirements I had. My library is 9 lines 
> of code (not including blank lines and TypeScript cruft), XRegExp 
> is thousands of lines of code, without even counting its dependencies. 
> And the double-escaping thing is unacceptable.

There is much to be said for keeping it a simple extension, I can't complain.
How do you approach matching whitespace with this format? I assume the character code has to be used.

Is whitespace between the final character on the line and '//' ignored (the comment)?

Since you are supporting comments, it seems like you could support named matches without too much additional effort.
Is that something you considered as a future feature?

[toc] | [prev] | [next] | [standalone]

#40136

On 2021-05-25, Michael Haufe (TNO) <tno@thenewobjective.com> wrote:
> On Monday, May 24, 2021 at 10:02:36 PM UTC-5, Jon Ribbens wrote:
>> Honestly, even if I was aware of XRegExp before I wrote my package, 
>> I would probably have written it anyway - XRegExp is just too enormous 
>> and heavyweight for the simple requirements I had. My library is 9 lines 
>> of code (not including blank lines and TypeScript cruft), XRegExp 
>> is thousands of lines of code, without even counting its dependencies. 
>> And the double-escaping thing is unacceptable.
>
> There is much to be said for keeping it a simple extension, I can't
> complain. How do you approach matching whitespace with this format? I
> assume the character code has to be used.

If it's at the start of a line you can use a backslash: "\ "
If it's at the start or end of a line you can use a character class: "[ ]"
You could of course use more convoluted options like "\x20" as well.

> Is whitespace between the final character on the line and '//' ignored
> (the comment)?

Yes. First anything from "//" to the end of the line is stripped, and
then any string of whitespace that contains a newline is stripped.
Whitespace within the line is treated as part of the regexp exactly
as normal.

> Since you are supporting comments, it seems like you could support
> named matches without too much additional effort.

I'm not sure what you mean - named capture groups are already a standard
part of JavaScript, so I don't need to add them.

[toc] | [prev] | [next] | [standalone]

#40137

On Tuesday, May 25, 2021 at 2:36:21 PM UTC-5, Jon Ribbens wrote:

> I'm not sure what you mean - named capture groups are already a standard 
> part of JavaScript, so I don't need to add them.

You're right. I overlooked that these were added in ES2018 and support seems solid:

<https://caniuse.com/?search=named%20capture>

[toc] | [prev] | [next] | [standalone]

#40186

Jon Ribbens wrote:

> On 2021-05-25, Michael Haufe (TNO) <tno@thenewobjective.com> wrote:
>> Since you are supporting comments, it seems like you could support
>> named matches without too much additional effort.
> 
> I'm not sure what you mean - named capture groups are already a standard
> part of JavaScript, so I don't need to add them.

But only because you implicitly limit your runtime environment and target 
implementation; i.e. regardless of that it is standardized, what matters 
here is that you are targeting *only Google V8* JavaScript thanks to Node.js 
as the *only* runtime environment :)

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#40188

On 2021-06-08, Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
> Jon Ribbens wrote:
>> On 2021-05-25, Michael Haufe (TNO) <tno@thenewobjective.com> wrote:
>>> Since you are supporting comments, it seems like you could support
>>> named matches without too much additional effort.
>> 
>> I'm not sure what you mean - named capture groups are already a standard
>> part of JavaScript, so I don't need to add them.
>
> But only because you implicitly limit your runtime environment and target 
> implementation; i.e. regardless of that it is standardized, what matters 
> here is that you are targeting *only Google V8* JavaScript thanks to
> Node.js as the *only* runtime environment :)

Yes. I only need support for Node.js 16+ and Chrome 91+, so that's fine
by me. And adding named capture groups to JavaScript implementations
that don't already have them would transform the project from a neat
9-line template-string trick into a complete re-implementation of
the JavaScript regular expression engine, which would be a whole
different project...

[toc] | [prev] | [next] | [standalone]

#40190

Jon Ribbens wrote:

> […] adding named capture groups to JavaScript implementations
> that don't already have them would transform the project from a neat
> 9-line template-string trick into a complete re-implementation of
> the JavaScript regular expression engine, which would be a whole
> different project...

You might want to reconsider after you have read JSX:regexp.js.  It was not 
trivial to do it, but it certainly did not require what you suggest here :)

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web