Dialecting URL!s...Should They Ever Be Strings?

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"]
  • 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.

1 Like

Just because I came across it, here's another example from Rebmake:

gen-entries: meth [
    return: [object!]
    parent [object!]
    /PIC "https://en.wikipedia.org/wiki/Position-independent_code"
][
   ...
]

Is it a waste to use URL! as just another string type, for the sake of saving some quotes and maybe getting a different syntax coloring?

gen-entries: meth [
    return: [object!]
    parent [object!]
    /PIC https://en.wikipedia.org/wiki/Position-independent_code
][
   ...
]

Something nags me saying that URL! should have a deeper meaning than saving on the quotes.

But what? What would a URL in that spot mean if not a "see also" link?