There's a lot that isn't known about how NewPath files are going to work. But I'm at the point where I think enough is known that it's time to start using it and get to pushing on its development.
This is the basic gist of the idea, showing the prototype MAKE-FILE and the quoting shorthand %%
>> extension: "txt"
>> dir: %/home/test/
>> make-file '(dir)/subdir/foo.(extension)
== %/home/test/subdir/foo.txt
>> %% (dir)/subdir/foo.(extension)
== %/home/test/subdir/foo.txt
It completely replaces the extremely sketchy historical "pathing" of a FILE! to produce a new FILE!:
>> dir: %/home/test
>> dir/subdir/foo ; cases like this give no hint that it's a file
== %/home/test/subdir/foo
It's bad for all sorts of reasons--like that you don't really know what dir/2 should do (does it give the #h character, or %/home/test/2 ?). The slash handling mechanics were ad hoc, adding more variability to the process instead of more certainty.
Now it will be an error, and good riddance.
Structure Means More Checks Possible
The hope of MAKE-FILE is not just to provide a representation that's nice to look at, but also one that can help you avoid mistakes that aren't caught by normal string operations.
For example:
>> extension: "txt/bad"
>> %% a/b.(extension)
** Error: Embedded / encountered inside filename component: "txt/bad"
There is no mechanism for silent tolerance of doubled slashes. Instead, situations that generate doubled slashes are called out:
>> base: %/home/test/
>> %% [(base) /subdir]
** Error: Doubled / encountered while generating filename: /subdir
The code is a very rough prototype, and the reason I want to push forward on it is that I want other people involved in designing it. Or at least throwing more situations at it so that we can figure out what protections offer good value propositions vs. just getting in the way.