So I just tried to use a URL! in PARSE and found it was an error. It's an error in R3-Alpha, too:
r3-alpha>> parse http://example.com/foo [http://example.com "/foo"]
** Script error: PARSE - invalid rule or usage of rule: http://example.com
Red treats it as a string:
red>> parse http://example.com/foo [http://example.com "/foo"]
== true
But if you think about it, this is a pretty limited application of the datatype.
-
If your input is a string, you're saving two characters over putting it in braces or quotes, like
["http://example.com" "/foo"]
- Ren-C has generic quoting, so there's quoted URL!s with a single character as another option...
['http://example.com "/foo"]
- Ren-C has generic quoting, so there's quoted URL!s with a single character as another option...
-
If what you're matching against is a URL it's only going to match the very beginning part.
Could It Fetch Rules From A Network?
In some cases--like the COMPILE dialect--you can build a list of code and libraries to put together, along with user natives. It's neat there to have URLs be interpreted as fetching from the network.
But that seems a bit strange for UPARSE. You'd depend on caching (you wouldn't want to do a network fetch each time you hit the URL! in the rule...?) In Ren-C you can kind of do this minus the caching, e.g.
uparse data [... :(load http://example.com/rules/) ...]
Could It Be Commentary?
In the test dialect, I thought it might be nice to just be able to drop URLs in the middle of things without having to make them comments. It doesn't save that much, but can look more clean:
[
#386
http://en.wikipedia.org/wiki/Some_Related_Topic
(1 + 1 = 2)
]
I've also sometimes wondered about this for function specifications.
foo: func [
http://example.com/this-explains-this-function
return: [integer!]
arg [integer!]
][
...
]
This doesn't seem a good fit for PARSE behavior, but I kind of want to mention the idea of different ways that URL! might be used.
In UPARSE It's Customizable...Leave it Open?
One possibility would be to say that URL! doesn't do anything by default, and you can make a URL! combinator that decides what it does do.
How useful would it be? I don't know.
I'm just questioning whether the knee-jerk response of treating URL! as a string (or matching a URL! value if block parsing) is obviously the way to go.