FILE! => FILE-WORD!, FILE-TUPLE!, FILE-PATH!..

Development Datatypes
1

I've never been quite on board with the FILE! datatype.

It displeased me that it was just a string, you couldn't really do too much with it. Not a lot of magic. It's burdened by representations of spaces in it, and hard to really say it gives coverage of any incoming file string.

Sample Rebol2 session on Windows:

>> cd /
== %/

>> ls
c/  d/

>> cd c
== %/c/

>> cd "Program Files"
== %/c/Program%20Files/

Are we really in the "actually good" territory of a problem space that can be reasonably tackled? If I'm a Windows user, I'd rather see that as {C:\Program Files} in my config files or scripts any day of the week.

I've Advocated Building on "NewPath"

"NewPath" was able to do things like /foo/bar or baz/mumble/). I advocated that FILE! build on that.

Now that we can have more basic types, I'm thinking that sounds pretty cool:

%foo                             ; FILE-WORD!
%foo.c                           ; FILE-TUPLE!
%1-foo.txt                       ; FILE-FUSED!
%foo/bar/baz.txt                 ; FILE-PATH!
%["C:\File With\Spaces.txt"]     ; FILE-BLOCK!

You've got your coherence...enforcement of not having doubled-up slashes...able to use COMPOSE and such...

>> dir: %foo/bar/

>> compose %(dir)/baz.txt
== %foo/bar/baz.txt

We could build the calculus-of-slashes that I've been demanding, so everything is on board with what's a directory and what's a file.

>> dir: %foo/bar

>> compose %(dir)/baz.txt
** Error: compose into FILE-PATH! needs ending slash in non-terminal slot

And basically, we could punt on the question of how to deal with obnoxious filenames by telling people "if you aren't going to name your files like a sane person, use a string." Spaces in filenames is one of the worst ideas ever, and I don't mind making those second-class citizens if it means we get good properties.

And of course, more parts for dialecting.

This Would Intern a lot of Random Strings

One downside here is that if you have a bunch of filenames of varying lengths, and you make them these symbolic structures instead of just keeping them as strings, you'll explode the symbol table.

That seems like an argument to say that if you're making some kind of database where these scale problems are going to affect you, you might should use string instead.

That's just a general truth--while WORD!s may look nice, they do go in the symbol table and that table can get big if you decide you're going to go crazy storing your data as tons of long unique words because-you-can.

2

Suggestion for inspiration here: have a look at the Haskell path library. This one does a pretty good job of supporting structured paths across OSs while keeping the overall data structure coherent.

3

In the past I've mused that I might like this kind of thing to work as meaning append content to the file, not to append to the string:

append/line %foo.txt "some stuff"

Part of enabling that was to consider FILE! as being immutable, so you couldn't be intending to mean "append string content to the filename itself".

And that would be served by the sequence types here (tuple, fused, path, chain...)

But FILE-BLOCK! and such would throw another wrench into that already-shaky idea, unless there was some rule that made them different and immutable. :-/

If you picked a category of List and said that it was immutable when viewed as such, you'd wind up with some pretty crappy invariants if you wrote a routine that took ANY-LIST? and then did an append to it and it happened to be a wacko FILE-BLOCK! that took your meaning entirely differently.

Oh well. It's always been a bit of a pipe dream to say appending to structural types that you'd find in source would interpret the request as anything but structural. I should probably give up on the idea.