Stephen Pelc wrote:
>These days, file names often come from
> dialog boxes, databases and so on. The application programmer is
> presented with
> a) a filename string
> b) knowledge of how to use it.

The dialog boxes I have experienced produce absolute file names, so no
relative-directory-handling is necessary. I have never seen a
database contain file names, so I can't comment on that. I have seen
files containing file names; these are either absolute file names (no
relative-directory-handling necessary), or relative file names
referring to the current working directory (that's what the wd is
there for); in neither case is a relative-directory-handling
necessary.

This proposal is about the application program or a library finding
its files (i.e., for file names generated by the application or
library programmer), not about end-user files and their names (we
leave the working-directory concept alone so it can be used for the
end-user files).

> My TransFileName word is simply an attempt to factor some of the
> requirements for easy implementation without having to litter
> the spec with other words and plug into the carnality of OPEN-
> FILE.

It seems to me that it does not succeed very well in that. You
introduce several additional words plus the need to define additional
ones, and require extending the definitions and implementations of all
the consumers (including OPEN-FILE).

In contrast, the present proposal adds only two words (ok, it's
limited in scope, but I only expect one more such proposal), and
leaves all consumers completely alone; no "plug into the carnality of"
any of them.

> Other file name manipulators that are commonly used are
> a) from the load path, i.e. from the directory containing the
> executable, e.g. for system-wide configuration.

Yes, I see that the presence of SAVESYSTEM (or similar) can lead to
complication, with the include directory changing between the original
include and the invocation of the executable.

Here's one way that might work with a system like VFX; I am making
some assumptions here that may need some adjustments for the real
system:

Ok, for the sake of the example, let's have a directory tree:

/build/app/src/app.fs
/data/config

Now app.fs could refer to the config file with

F" ../data/config"

and would store the resulting string somewhere, for later use with
INCLUDED or OPEN-FILE (or however you access the config file).

In order to build the application, the application programmer would
set the macro %load-path% to /build/app, and then do

INCLUDE %load-path%/src/app.fs

and the name stored for the config file would be
"%load-path%/data/config". This would survive SAVESYSTEM. The saved
application and all its data files would then be stored in, say, /install:

/install/app/app.exe
/data/config

Upon starting app.exe, %load-path% would be set to /install/app, and
the access to the config file would work as intended.

In this way the proposed F" could work with your system-specific
extensions to achieve the effect you need to deal with the more
complex situation in your system.

> b) from the home directory, e.g. for user configuration
> c) from user's data directory.

How does b) differ from c)?

Ok, the home directory could be addressed with another pair of words,
but there I actually think that the prefix approach is preferable (so
I would not propose these words), because that's often something that
the end user inputs, not something the application programmer
controls.

> I've been bitten often
> enough by words of the same name with incompatible behaviour
> that I treat search paths with deep suspicion.

Then it's a good thing that I have not included search path words in
my proposal:-).

> The real problem is how an application takes a
> simple file name and converts it to a full path based on one of
> a number of different base directories, including but not
> limited to:
> a) current working directory

Not necessary. Just leave the relative name, and the OS will add the
cwd.

> b) directory of current include file

Addressed in this proposal.

> c) load path

That's something specific to issues like SAVESYSTEM and turnkey
systems that have not been standardized, so dealing with it is outside
of the scope of the Forth200x effort at the moment.

> d) home directory

Use a prefix.

> e) data directory

That's the home directory, no?

> f) Forth tools directory

A future search path proposal.

> g) application source base directory

Can be accessed through the current included file, which is addressed
in this proposal.

- anton