There is a "NewPath extremism" idea that http://somewhere could be a 3-element PATH! of:
As stupid as this might sound at first, there's kind of an interesting idea that in dialects, you could still get away with having "URL-looking things" for common URL!s
This could be kind of analogous to how PATH! can be turned into FILE!, an idea which is as old as R3-Alpha's %file-base.r.
This becomes more palatable--I think--if we were to say that it was common practice to put URL! inside of angle brackets.
If we were to do that, maybe the URL! datatype goes away... and it's just that sometimes you contextually assume "if I'm passed a tag here, it's intended as a URL!"... or I'm supposed to take some kind of interpretation of that sort of it.
Maybe a URL! is a type of OBJECT!... something that holds the decoded pieces. Maybe it accepts plain CHAIN! or URL!s just as well.
The NewPath Fever Dream Returns
You could TRY to make a URL! out of anything:
>> try make url! 1020
== \~null~\ ; antiform
But it would make a stab at decoding things it understood...be they TAG!... string... PATH!, TUPLE!, or CHAIN!
>> make url! <http://example.com/get?q=ščř#kovtička>
== &[object! [
scheme: http
user: ~null~
pass: ~null~
host: "example.com"
port: ~null~
path: "/get?q=ščř"
tag: "kovtička"
]]
>> make url! first [something:like:this]
== &[object! [
scheme: something
user: ~null~
pass: ~null~
host: ~null~
port: ~null~
path: "like:this"
tag: ~null~
]]
>> p: make path! [make chain! ['http _] _ make tuple! ['example 'com]]
== http://example.com
>> make url! p
== &[object! [
scheme: http
user: ~null~
pass: ~null~
host: "example.com"
port: ~null~
path: ~null~
tag: ~null~
]]
But What Of Inertness?
The "wacko" idea here would be to say that x://y is an inert PATH! because it has a blank-terminal chain in its first spot, just for the sake of making this work:
read http://example.com
The "less wacko" idea would be that you use a TAG!:
read <http://example.com>
But that's not so bad. Especially if you're reading a lot of code with CHAIN! and PATH! surrounding, saying "hey this is inert" is okay.
Getting The Scanner Out of The URL! Business Is Not Unwise
I know Rebol has prided itself in its "everything isn't a string, there are more types"!
However, Ren-C has pursued the bigger "force multipliers" (like FENCE!, or --[dashed strings]--). This is where the real power comes from, vs. not having to delimit URL!s.
Having the rules for URL! embedded in the scanner doesn't feel "timeless". It puts complexity in what may be the wrong place.
Maybe URL!-as-OBJECT! that's easy to make from anything (TAG! or TEXT! or PATH! or CHAIN!) is smarter.
Auto-Coercion of TAG! to URL!, maybe?
I think what would give the "feature mileage" would be if you could say you took a URL!, but someone passed a TAG! at a callsite and you get it validated and broken into parts for you.
That's kind of the killer feature... it would be better than today.
Hand-waving a bit, what if there was some sort of "conversion syntax" in the spec dialect...
demo: procedure [x [integer! url! {tag! -> url!}]] [
if url? x [
print ["Got a URL and host is" x.host]
] else [
print ["Got an integer" x]
]
]
>> demo 1020
Got an integer 1020
>> demo <http://example.com/foo>
Got a URL and host is example.com
Maybe if you accept a conversion to a type then it's assumed you'd accept that type literally, as well?
demo: procedure [x [integer! {tag! -> url!}]] [...] ; accepting URL! implicit?
Or maybe that's too presumptuous.
Anyway, in this example only TAG! would auto-convert, but if you had another source of your URL data you could do the conversion explicitly:
>> demo make url! first [http://example.com/foo] ; passing in a plain PATH!
Got a URL and host is example.com
That looks like the real power, to me. The superficial value of "hey, no delimiters" is fleeting by comparison.
This hinges on OBJECT! subclasses, so URL! is typechecked
And it needs constructors, for custom MAKE behavior.
...but we know we need all that anyway.
— Only the search engine metric puts URL ahead of URI as the more appropriate choice.