Make PATH! the loaded type of %foo/.../... and *eval* to FILE!

[rebolbot]

Submitted by: fork

In discussions with @earl I discovered something that I did not know about. That is: the evaluator for URL! and FILE! types as the base of a PATH! does an append, with a slash, of words and strings.

>> base: %foo
>> sub: "bar"
>> type? base/:sub/baz.html
== file!
>> probe base/:sub/baz.html
%foo/bar/baz.html

I was not aware of this. I mentioned it to @GrahamChiu and he was not aware of it. I then tried something that I think is a bug:

>> base: %foo
>> index: 2
>> type? base/(index)
== file!
>> probe base/(index)
== %foo/2

That doesn't sit well with me in terms of wanting to index into FILE! with an INTEGER!, when it's an ANY-STRING! type. :-(

But that is a bit on a tangent of whether the overall concept is a good idea or not when STRING! and WORD! types are used. I didn't like it at first, but I did a bit of thinking and... I think I do like it. But to really like it requires %foo/:bar/(baz)/mumble and foo/:bar/(baz)/mumble to not become drastically different beasts because of the choice of whether the leading piece of the path has a % or not.

Consider the difference today between those two:

>> a: load "%foo/:bar/(baz)/mumble"
** Syntax error: invalid "file" -- "%foo/:bar/"
** Where: to case load
** Near: (line 1) %foo/:bar/(baz)/mumble

>> b: load "foo/:bar/(baz)/mumble"
== foo/:bar/(baz)/mumble

The first won't LOAD at all. The second loads, as a PATH! with 4 elements: WORD!, GET-WORD!, PAREN! (with one WORD! in it), and WORD!.

Let's take out the offending colon.

>> a: load "%foo/(baz)/mumble"      
== [%foo/ (baz) /mumble]

We already have arguments for why this shouldn't be so, and Ladislav has mapped the territory:

2094

So we know that certainly could have been read differently. One way would be as a FILE!

>> a: load "%foo/(baz)/mumble"      
== %foo/(baz)/mumble
>> type? a
== file!

But I'd propose instead we consider reading it as a PATH!

>> a: load "%foo/(baz)/mumble"      
== %foo/(baz)/mumble
>> type? a
== path!

So the PATH! containing [%foo (baz) mumble]. We know that evaluating this PATH! in the interpreter would produce a FILE! (assuming success). We also know that there are going to be some things creating trouble if we start trying to use filenames with invalid words:

>> a: load {%foo/1.reb}      
** error blah blah blah 1.reb is not a happy fun word

But this could be gotten around in many ways, for instance parens with strings inside:

>> a: load {%foo/("1.reb")}  
== %foo/("1.reb")

Producing the proper FILE! evaluation result. Also, if an easier construction syntax for words were introduced, then the additional PAREN! series could be eliminated if that bothered people

>> a: load {%foo/#[1.reb]}
== %foo/#[1.reb]

(that's assuming that MOLD was smart enough to know it should use construction syntax when rendering words in paths that would be illegal to LOAD, and that construction syntax for an arbitrary word was done with #[...], which are two random assumptions I'm throwing in here... but the point is that's just a path with a FILE! as a first element and a WORD! as the second).

For people using paths in runtime, those most affected would be:

1) Codebases in which FILE! path literals were using characters illegal in Rebol3 words at source level (I believe that all characters should be legal in programmatically created WORD!)

2) Dialects that "sniff" unevaluted elements to see if they are FILE! and take action if so, vs. running an evaluation. Because they will "sniff" a PATH! if there were slashes in the literal expression and don't evaluate to get a FILE!

A convenient construction syntax for FILE! that subverted the PATH! interpretation might help any unease here. #%[foo/baz/1.html] for instance, not that we've solved all of exactly what construction syntax is.

But the thought I've had in turning this over in my mind for all of half a day (so far) is that this could be a shift. Toward starting to be a little prescriptive. To saying "please don't name your files "1.html", and if you do, you'll pay a little bit more. Might not our intuition about what makes a good WORD! that doesn't need construction syntax help inform system design? You wouldn't name your variable 1, why name your file 1? Why name your file a:b?

It's not about prohibiting those things, but maybe just about not catering to it. And instead helping make the fluid expression of source that follows some rules reap benefits from being sensible. There's your philosophy moment.

Philosophy aside, there's a technical proposal here.

;-- current behavior

>> bar: "bar-mitzvah"
>> baz: "baz-lurhmann"

>> a: load "%foo/:bar/(baz)/mumble"
** Syntax error: invalid "file" -- "%foo/:bar/"
** Where: to case load
** Near: (line 1) %foo/:bar/(baz)/mumble

;-- desired behavior

>> a: load "%foo/:bar/(baz)/mumble"
== %foo/:bar/(baz)/mumble

>> type? a
== path!

>> type? first a
== file!

>> type? second a
== get-word!

>> type? third a
== paren!

>> type? fourth a
== word!

>> b: reduce reduce [a]
== [%foo/bar-mitzvah/baz-lurhmann/mumble]

>> type? first b
== file!

^{CC - Data [ Version: r3 master Type: Wish Platform: All Category: Syntax Reproduce: Always Fixed-in:none ]}

[rebolbot]

Submitted by: maxim

sorry, I see no logic in what you're proposing. a lexical file! value starts with a % . there is nothing more to it.

If I put a file! in a block and parse that block I want to know that a file! value was put there. I cannot risk evaluating a value to know its internal type, it could have been a function! I will only know once its too late.

path! really has nothing to do with filepaths. what you are proposing could be how a file! is managed in a dialect, but not in the root dialect.

[rebolbot]

Submitted by: fork

@maxim

There is a deep suggestion here, and I wasn't really intended to give it as a foregone conclusion one way or the other. I was reticent to consider PATH! as an appropriate carrier for what was intended as a FILE! for several reasons.

But I drew this issue to your attention because you had suggested dialect use of PATH! to represent something essentially a filename:

http://stackoverflow.com/a/26172114/211160

I disliked the idea, perhaps in part based on your own impulse reaction. The same thing that made me want ISSUE-PATH!, for instance. But I've presented an argument from the point of view of a dialect designer to whom "structure" has value over "string", and if the LOAD time builds structure and offers the advantages of that, there can be rewards. You don't win friends and influence people with 10 different types of string... you show them something powerful.

In any case, you can't take down a several page proposal in four lines with preconceptions. You have to refute the points. Your response was short and quick and dismissive. You didn't weigh in on details, like what:

f: %foo
index: 2
probe f/(index)
probe f/:index

...should be. You've got to lay out a position instead of just making me want to quit. Or, well, if you just want me to quit...say "QUIT!" (But until things get patched for sanity, you'll need to say "QUIT/NOW")

[rebolbot]

Submitted by: abolka

Responding to a multi-page proposal with a few lines too, but nevertheless: I think that's a very interesting proposal to think about. I'll definitely have to mull this over for a while.

(Maxim: to detect a file! in a block under this proposal, you don't have to evaluate a value at all. You'd check for a plain file! or a file! as first element of a path!.)

[rebolbot]

Submitted by: fork

One thing to mention here is that there has been reluctance to use WORD! for things that would be STRING! due to the cost profile of WORD!

Being symbolic, words take up space with the notion that there is going to be more than one reference to them and they need to be "looked up".

If you have literal paths like %foo/baz/bar.html going from ANY-STRING! to [word! word! word!], that is different.

I think there are two reasons why this isn't so bad. One is that we're talking about construction syntax so that if you really are writing data (vs. source) of FILE! then you'd have #%[foo/baz/bar.html](or whatever) and nothing changes. Also, if you are writing a lot of paths out by hand in source then there probably is a lot of repetition (directories repeated over and over, you probably have a %foo/baz/mumble.html too, so that's only one new word.)

It all does point out to me the need to make construction syntax very convenient, which is important for other reasons.

[ladislav]

Disagree, should be dismissed.