Looks Like FILE! Immutability Is A Good Idea

Development Datatypes
1

Since changing URL! to be immutable, we've realized several benefits. Notably that you can't produce things that don't validate as URL! that are still claiming to be of type URL!:

red>> url: https://red-lang.org
== http://red-lang.org

red>> reverse url
== gro.gnal-der//:sptth

sptth! indeed, I say. :face_vomiting:

ren-c>> url: http://hostilefork.com
== http://hostilefork.com

ren-c>> reverse url
** Script Error: reverse expects [~void~ any-series? any-sequence? pair!]

But besides that we get another advantage: we don't have to be paranoid about URL! changing out from under us.

So for instance, when you LOAD some code from a URL! then we poke the address of that URL's data into all the blocks that get loaded. This way you can ask for the FILE OF and get that URL! back.

(As it gives a URL! sometimes and not a FILE!, that makes me wonder if we should call that SOURCE OF, and find another way to ask for source code... like IMPLEMENTATION OF).

In any case, since we know the URL! can't change out from under us, we don't have to worry about storing the pointer that was passed to TRANSCODE by LOAD directly. If we did have to worry, we'd need to make a copy of it.

But with mutable FILE! we do have to worry, and copy it. Otherwise:

>> file: %my-awesome-script.r

>> code: transcode:file (read file) file
== [reverse [my script is awesome]]

>> file of code.1
** Error: Only ANY-LIST? encode the file they were loaded from

>> file of code.2
== %my-awesome-script.r

>> replace file "awesome" "dumb"
== %my-dumb-script.r

>> file of code.2
== %my-dumb-script.r  ; ...but we loaded it from %my-awesome-script.r !

Immutable FILE! means we could kill empty FILE!

Empty FILE! doesn't make sense.

  • Did you want something that would cause an error when you appended it somewhere? Use NULL.

  • Did you want something that would be a no-op when you appended it somewhere? Use VOID.

All the AI say roughly this:

There are no known filesystems that allow the empty string ("") as a valid filename. Most modern filesystems, including ext4, NTFS, FAT variants, and others, explicitly disallow the empty string as a filename. This restriction is consistent with POSIX standards, which define filenames as non-empty character strings

Historically, some older UNIX systems might have treated an empty string as an alias for the current directory, but this behavior was likely unintended and is no longer supported in contemporary systems

If we could get rid of empty FILE!, that gives us one more leg up in terms of the datatype providing actual value vs. just being a weak alias for string.

Interpolation Is Stronger Than Mutable Manipulation

Now that we have interpolation, I think it can replace a lot of cases where you might have thought you needed to manipulate a file directly.

Also, the -OF functions will let you do things to immutable types:

>> replace of %my-dumb-script.r "dumb" "awesome"
== %my-awesome-script.r

I think this also points out a missing ability for PARSE, namely PARSE OF for immutable types. e.g.:

 parse-of tuple rule
 =>
 as tuple! parse to block! tuple rule

So for instance:

 >> parse of 'a.a.a.b.c.d [remove some 'a ~accept~]
 == b.c.d

Best of both worlds!

Retaking % As A WORD!

With no empty files, we can say that % is clearly a WORD!

Maybe some other things too. %% could be a WORD!, or a file with the name "%". There's lots of edge cases on that, e.g. to make a file with the name " you'd have to say %-{"}-. So I don't think we should be afraid to make %% a WORD! if that provides another interesting symbol.

This Seems Like A Good Direction

I've had the thought before, but recent improvements to OF makes it more palatable.

What motivated me to think about this right now was that I was resurrecting the LIBRARY! codebase, where you can load a DLL:

>> make library! %some-thing.dll
== #[library!]

I was thinking "Hm, it seems like it would be nice if it stored the filename".

>> make library! %some-thing.dll
== #[library! %some-thing.dll]

And I was going to poke the FILE! value into a Cell in the LIBRARY!'s Stub. But then I thought "oh no, what if they change it."

They shouldn't be able to. Immutable FILE! is just better all around for the system.

2 Likes