World: r4wp

To me, it's a matter of whether SPLIT-PATH should be consistent in 
how it handles the path, as a string to process, or whether it should 
try to be "helpful". The problem with being helpful is that it may 
make other things harder.

By saying that SPLIT-PATH always behaves the same way, depending 
on whether the path ends with a slash or not, it may not shortcut 
a few cases for us, but it does make it easy to reason about, and 
also to wrap for other behavior. e.g., you can always dirize the 
path before calling it.

One test missing in your collection:
%foo [%./ %foo]

Also:
%"" [%./ %""]

Thanks Andreas!

after thinking again, I would perfer %./ as the last part of the 
result of split-path, as it has a trailing slash and it  is still 
the samel

if the argument was a directory

What do you mean, if the arg was a directory? Can you give an example 
each way?

split-path %test/ should give [%test/ %./]

Why would that return anything for the target? That is, why not  
[%test/ %""]

%"" looks strange, even if its allowed. %./ has a trailing slash, 
if someone wants to test for that

I think I would prefer split-path so split into the last non-slash 
component (target), and the original path with that last non-slash 
component removed.

Anton, but then you could never get an empty target, and you would 
have to compare to %./ as your empty value.

And then make sure that wasn't the end of the original path.

Andreas, can you give examples, to make sure I'm clear?

Would behave mostly as the current split-path does.

(For the common cases.)

So this is OK for you: %/c/test/test2/ [%/c/test/ %test2/]

Yes, that's what I'd expect.

I'd also prefer a stronger invariant, as REJOIN is relatively weak 
for joining path components.

Something more along the lines of

set [d b] split-path f
f = d/:b

what do you mean with an empty target?  %./ just means the target 
is a directory, the actual directory

OK, using that as a quality test, here's where the current SPLIT-PATH 
fails:
Path quality failed: %/ %/none
Path quality failed: %// %/
Path quality failed: %. %./none
Path quality failed: %./ %./none
Path quality failed: %./. %././
Path quality failed: %.. %../none
Path quality failed: %../ %../none
Path quality failed: %../.. %../../
Path quality failed: %foo/.. %foo/../
Path quality failed: %foo/. %foo/./
Path quality failed: %foo/../. %foo/.././
Path quality failed: http:// http:/
Path quality failed: http://..http://../
Path quality failed: http://.http://./
Path quality failed: http://../.http://.././

And here's where my proposed SPLIT-PATH fails:
Path quality failed: %. %/.
Path quality failed: %.. %/..

%. is tricky :)

Anton, which is the behavior question. Do you expect SPLIT-PATH to 
return a target you can write to (i.e. a file)?

Here's a few example values and what I would expect: 

http://sprunge.us/AaDJ


Where there is a third column, current R3 split-path differs from 
what I'd expect, and the third column is what split-path returns 
currently.

Great! Since I haven't had coffee yet, the second column is *always* 
what you expect, correct?

Yes.

Got it.

But with a "path component"-based invariant, the %. %.. and %/ cases 
will require more work to reconcile.


With a "string"-based invariant (rejoin), those cases could more 
easily be described with the neutral %"" element:

Here's some examples based on a string-based invariant:
http://sprunge.us/VeeH


Which is, I guess, what your proposed split-path already implements 
:)

Yes, I believe that matches my current proposal.

Basically strips off everything past the last / as target.

And where it fails the path (p/:t) invariant is in these cases:
Path quality failed: %"" %/
Path quality failed: %foo %/foo
Path quality failed: %. %/.
Path quality failed: %.. %/..

A slightly better path-based invariant:

set [d b] split-path f
clean-path/only f = clean-path/only d/:b

It doesn't match your expected results in a number of cases though.

I don't have a *nix VM up here to check basename and dirname results.

That might be something else to consider.

Using the clean-path test, here's where my proposed version fails:

Path quality failed: %"" %/
         %""     ; clean-path test
         %/      ; clean-path p/:t
Path quality failed: %foo %/foo
         %foo    ; clean-path test
         %/foo   ; clean-path p/:t

My first examples should match dirname/basename exactly.

OK, great.

In effect, that is :)

dirname/basename does a clean-path before splitting.

:-) Let me play with an idea here for a bit.

Let's widen the discussion a bit. Spitting a string at a delimiter. 
Easy enough to define clear behavior if the series contains the delimiter, 
but what if it doesn't? Most split funcs return an array, splitting 
at each dlm. If no dlm, return the original series as the only element 
in that array. 


What if we always want to return two elements? e.g., we have a SPLIT-AT 
func that can split a series into two parts, given either an integer 
index or value to match. Let's also give it a /LAST refinement, so 
it can split at the last matching value found, like FIND/LAST works. 


Given that, what do you expect in the case where the dlm (e.g. "=") 
is not in the series?

    SPLIT-AT "abcdef" "="   == [? ?]
    SPLIT-AT/LAST "abcdef" "="    == [? ?]

I haven't had the time to follow all the discussion in detail, but 
to me, the second part of split-path should NEVER return a directory 
path. 


when doing   set [dir file]  I should be able to count on the fact 
that the second part is either a file or none.  The same for the 
first part which should always be none or a dir.  I have my own implementation 
in R2 which makes this strict and it simplifies a lot of code.
so we can do with absolute certainty:

if second set [dir file] split  path [   ]


IIRC some of the versions of my split perform a clean-path to simplify 
and add robustness to the result.

Thanks for posting Max. With 5 of us talking about it, we have 5 
opinions so far. :-) The one thiing we all seem to agree on is that 
we want consistent behavior, which we don't have right now.

Maxims method sounds reasonable

Re: 

One test missing in your collection:
%foo [%./ %foo]

- this test violates the "invariant"