Add jsre

[juancarlospaco]

• Add jsre module, Regular Expressions for the JavaScript target.

:)

[timotheecour]

to fix test failure, you can update kochdocs as follows (untested but shouldn't be hard to make it work):

# add this:
proc isJsOnly(file: string): bool = file.isRelativeTo("lib/js")

# update `commands[i] = nim & " doc $# --git.url:$# --outdir:$# --index:on $#" % [nimArgs2, gitUrl, destPath, d]`
# to:

let isJsOnly = 
var extra = ""
if isJsOnly(d): extra.add " --backend:js"
commands[i] = nim & " doc $# $# --git.url:$# --outdir:$# --index:on $#" % [extra, nimArgs2, gitUrl, destPath, d]

(let me know if anything is unclear)

[timotheecour]

@juancarlospaco this test will fail:

doAssert jsregex.exec(r"nim javascript") == @["nim"]

=>

doAssert jsregex.exec(r"nim javascript") == @["nim".cstring]

(as you can see locally with nim doc --backend:js -r lib/js/jsre.nim)

[timotheecour]

and you still need to update kochdocs as described in #14870 (comment)

otherwise CI will fail with:

2020-07-01T20:56:15.7235670Z /Users/runner/runners/2.263.0/work/Nim/Nim/lib/js/jsre.nim(6, 13) Error: importjs pragma requires the JavaScript target

after that LGTM for me

[timotheecour]

• in a cleanup PR (if you don't want to keep editing this PR and finally ship it), it would be nice to cross reference this from std/re and std/nre:

eg:

# in re.nim
when defined(js):
  {.error: "This library needs to be compiled with a c-like backend, and depends on PCRE.".}

=>

when defined(js):
  {.error: "This library needs to be compiled with a c-like backend, and depends on PCRE; see std/jsre for js backend".}

• in future work (but obviously much more involved), one could contemplate lifting that restriction and making std/{re,nre} work with both c and js backend, using std/jsre as implementation for the re/nre API when using js mode (unless pkg/regex is faster than std/jsre which I kind of doubt).

I hope it works :|

running locally ./koch --localdocs:htmldocs2 docs is your friend, for faster turnaround ;-)

[Araq]

Shouldn't this be a "fusion" module?

[timotheecour]

if regex is stdlib territory for c backend, it makes sense to have regex for js in stdlib as well; it should reduce friction when porting working nim code from c to js; and as said above, in future work it would be nice for this to be transparent (so that re/nre can use jsre under the hood for js backend). And this could be gradual (1 proc at a time).

I don't think pkg/regex is "the answer" in the js case since I expect it to have large overhead over jsre but maybe @juancarlospaco can do a quick benchmark? /cc @nitely

[pietroppeter]

For an example where it would help to have jsre in stdlib, nim-markdown would be able to support js backend.

[Yardanico]

@pietroppeter did you look into https://github.com/nitely/nim-regex? I think it might be a good fit too

[timotheecour]

@Yardanico see remark here #14870 (comment), this at very least needs a performance comparison, assuming https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions would be natively (or at least efficiently) implemented whereas nim-regex would incur large overhead on js backend

[pietroppeter]

yes, I was aware of nim-regex, having seen it mentioned in #7640 (which could actually be closed if this is merged), but it is good that this is also mentioned in this conversation. I still think this jsre would be a good fit for stdlib:

• we have it for C backend so it makes sense for JS (@timotheecour's point above)
• I would expect native JS regex to be better than a nim implementation (although I guess it could also not be the case)
• also if you use native JS regex you would not need to ship in your js file Nim's implementation
• regarding markdown library above, it currently has no dependecies other than nim and it would be nicer to keep it that way