File path join / operator

[danielbayley]

Obviously / is the division operator… But what if—without any surrounding spaces—it could join file paths, like the Pathname::/ method in Ruby?

For example:

path := "~/path"
file := "file.ext"

path/"to"/file # ~/path/to/file.ext

could compile to something like:

path + "/" + "to" + "/" + file // ~/path/to/file.ext

or

`${path}/to/${file}` // ~/path/to/file.ext

[edemaine]

Sounds cool and useful! Some issues:

• For Windows, I imagine "/" should actually be path.sep. Except when working with canonicalized-to-/ paths, as in e.g. VSCode extensions. Maybe "civet slash=path.sep" vs. "civet slash=/" could control this...
• Alternatively and probably better, the strings could combine via path.join calls, and then you could override with something like "civet pathJoin=myJoinFunc". This seems to be how Ruby does it; path.join has a bunch of fixes regarding duplicate slashes.
• I worry about existing divisions like 1/2. This would get easier once we have operator overloading based on types (Operator overloading and custom operators #10). Until then, I don't think this syntax can fly...
• In the meantime, we could try another syntax. \ is gross but at least it's not taken. Maybe \/ or /\ communicates "/ or \ depending on path.sep". But they also look like ∨ and ∧ (or and and) which is maybe not great.

[danielbayley]

In the meantime, we could try another syntax.

@edemaine I think it should wait for #10 if necessary, rather than introduce some other ugly syntax.

[gwhitney]

I am a little confused; in current javascript "1"/"2" evaluates to the number 0.5 and this proposal, once operators can "dispatch" on the operand types, would be to change that to "1/2" on the presumption the operands were pathnames? As anyone who's read my posts here knows, I am all for change and improvement, but that seems like a pretty big unexpected "gotcha" case of altering the underlying JavaScript semantics. I'd suggest one ought only to use / as filepath joining on a specific type for representing file paths, not on string. Node has such a standard library, but JavaScript at large does not have one; unclear to me whether Civet would be in the business of extending the JavaScript standard library. I mean, it sorta kinda does already, but only in little nibbles around the edges; the "new facilities" are very lightweight.

[vendethiel]

TypeScript forbids "1"/"2" already, so isn't overloading it to mean something sensible fine?