> Posted by: "Anton Ertl"

> Now I understand what you mean with consumer. You mean words like
> OPEN-FILE and INCLUDED that consume file names, right?

Yes. In practice, the only two that matter are OPEN-FILE and
CREATE-FILE. VFX expands text macros there. We have not had a
single tech support query about this behaviour.

> At the start of this proposal I thought so, too. But as I worked
> through it, I found that it actually makes more sense to add the
> directory to the file name at the place where the file name occurs:
>
> * The main reason is that the programmer specifying the file name
> knows relative to what directory it is, so it makes sense to specify
> that along with the file name; in the current proposal they do this
> by specifying the file name with F" (for include-directory-relative
> names) or with S" (for other names), and possibly in the future with
> FS" or somesuch.

Wherever this is done, at some stage the filename string has to
be modified, and the less this has to be done, the safer is the
app.

> With the TransFileName modes, the programmer would have to pass that
> knowledge separately to the consumer, and the modes are designed to
> make this particularly inconvenient in the (admittedly rare) case
> where the consumer is not directly adjacent to the producer.

TransFileName is a straw man for comparison - it's a bad way to
do things, but it illustrates an alternative approach with more
capability. MPE does not have a factor like TransFileName. We
use:
: Expand \ caddr len -- caddr' len'
\ *G Macro expand the given string, returning a buffer.

> * The implementation is easier: All consumers can stay exactly as they
> are. We are just adding new ways to produce file names.

That's the point. The best way (IMHO) is to modify OPEN-FILE and
CREATE-FILE.

> 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.

That's a specific behaviour of a specific dialog box.

> I have never seen a database contain file names, so I
> can't comment on that.

Any source/project management app. Any virtual file system.

> 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).

End-user files can be in many different places. When I go on
site the directory structure on the client's machine is often
wildly different from that of my desktop machine and my laptop.
The way clients manage files varies enourmously. Some keep the
MPE issue directory structure unmodified and compile MPE code
from the issue folder. Some copy the MPE issue files into a
project folder. Some add project folders into the MPE issue
structure.

> 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.

That's the problem - the proposal has no extensibility for
existing application requirements - it's a developer tool. It's
even an application programmer's tool.

> > 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.

I have no control over where my clients put their code, and even
less control over where the end-user puts the final system.

> 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"

I saw a similar problem at xxxxSys while they were trying to
keep code portable across several systems. The high end solution
was a word like
+INCLUDE \ caddr len "<text>" --
used in the form
AppDir$ +include foo.bar
where AppDir$ returns caddr/len.

I believe that +INCLUDE solves everything you want to do, has
been implemented on a range of Forth systems, is user
extensible, and covers most of what application programmers
need. It simply requires a string concatenation operation.

> 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:
> /build/app/src/app.fs
> /data/config
...
> 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
...
> The saved application and all its data files would then
> be stored in, say, /install:
> /install/app/app.exe
> /data/config

It just doesn't happen that way! Our load path macro is set at
start up to the directory from which On a development box we
have to be able to cope with:
.../VfxForth/bin/xxx.exe
/Lib/a big tree
/Examples/another big tree
.../job/src
/config
...

and on the end-user's machine
.../install/bin/app.exe
/config/globalconfigdata
jobs/projA/data
/projB/data
configs/printerA/PlotDefs
/printerB/PlotDefs
users/...

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

Engineers, architects and so on tend to put their job data in a
current work folder with subdirectories for each job.

> 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.

See +INCLUDE.

> > 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.

But it's a common reality. See
LoadDir$ +INCLUDE foo1.fth

> > d) home directory
>
> Use a prefix.

See
Home$ +INCLUDE foo2.fth

> > e) data directory
>
> That's the home directory, no?

No. See above and
DataDir$ +INCLUDE foo3.fth

> > f) Forth tools directory
>
> A future search path proposal.

See
Tools$ +INCLUDE foo4.fth

> > g) application source base directory

See
App$ +INCLUDE foo5.fth

I conclude that +INCLUDE solves more of my source management
requirements as well as your specific one, while making FINCLUDE
trivial to implement.

Stephen
--
Stephen Pelc, stephen@...
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads