WISH: URLs to support parens `()` for string interpolation

[hiiamboris]

It is currently possible to use string interpolation with strings, tags and files:

"(now as {hhh:mi:ss}): (value) is invalid in (mold spec)"
{(now as "hhh:mi:ss"): (value) is invalid in (mold spec)}
%"(drive):\(path)\file-(idx as "000.").(ext)"
<img src=(url) width=(width as "0")>

Would be nice if URL could join the band:

http://(site)/(resource)?param=(date as "yyyy")

Since x:(1 + 2) is valid Red code for a set-word and a paren, I propose that paren support gets toggled on after :/ only. Anyway http:///https:// will be the vast majority of use cases, with file:// probably following. mailto: cannot be supported.

Workaround is possible right now: as url! #rejoin "http://(site)/(resource)?param=(date as "yyyy")" but still having URLs work out of the box would be cool.

[dumblob]

Just a side note - the parens should not interfere with literal parens in URLs (yes, URLs can contain parens).

[hiiamboris]

They can, just not easily...

>> to url! "http://(stuff)"
== http://(stuff)

well, that was a failure

>> to url! enhex "http://(stuff)"
== http%253A%252F%252F%2528stuff%2529

okay, this too :/

>> rejoin [http:// enhex "(stuff)"]
== http://%2528stuff%2529

got it right this time

point of this wish is to write () instead of %2528%2529 that's all

[dumblob]

>> to url! "http://(stuff)"
== http://(stuff)

well, that was a failure

Hm, why a failure? That should be fine according to RFC, right?

[hiiamboris]

Failure because it's currently not loadable. I guess design of mold is not finished in the area of url-encoding.

[hiiamboris]

I expected smth like in R2:

>> to url! "http://(stuff)"
== http://%28stuff%29

Also wondering why Red says %2528 and not %28 and so on.

[hiiamboris]

https://www.codetable.net/decimal/9512 Looks like a bug.

[hiiamboris]

Figured it out.

>> rejoin ["http://" enhex "(stuff)"]
== "http://%28stuff%29"

URL when molded runs enhex again, so we get %25 for every %

[dumblob]

Now I see what you mean. But contrary to that what I was pointing at is the fact that https://en.wikipedia.org/wiki/Kush_(cannabis) is a valid URL as it stands (so we should not actually expect it to be converted to https://en.wikipedia.org/wiki/Kush_%28cannabis%29).

[hiiamboris]

Latter URL works though. But I think you're correct:

So RFC 3986 supports this wish:

• () and %28%29 should not be converted to each other
• () should be loadable for that
• current mold implementation is correct to leave () as is
• characters []; are also currently not treated as part of the URL, but they should be

[greggirwin]

IPv6 lexical support has been added in a branch by @dockimbel. I agree that parens should be allowed in URLs, per the spec and also pragmatically.

[rebolek]

String interpolation in URLs makes sense but I would prefer to use { and } which are invalid in URL and usually used in API docs for user values anyways.

[hiiamboris]

Per RFC {} are not reserved as ()[] so they are even more valid than parens in URLs.