On Apr 6, 10:34 am, an...@[EMAIL PROTECTED]
(Anton Ertl)
wrote:
> First of all, relative file names are not necessarily relative to the
> current working directory (cwd). Indeed, since a Forth source file
> should usually work without being dependent on the cwd, making
> relative file names written in the source file refer to the cwd is a
> bad idea; it does not help well-written programs, and makes
> programmers adopt bad programming practices (like making the source
> file dependent on a specific cwd).
I recall the discussion here on that point being on what
implementations did. What it makes sense to do is a separate issue.
> One disadvantage of F" (or SF") is that most Forth programmers seem to
> prefer INCLUDE and REQUIRE over INCLUDED and REQUIRED, standards be
> damned. So they probably won't write
> F" name.fs" required
They don't have to. If they are writing for their system, they write
INCLUDE or REQUIRED and use the filename in the form that their
implementation on their OS expects the file to be in. That
implementation might, for example, follow a convention that is common
to their OS, or to Forth's implemented for their OS, and the impact of
the standard is ... keep on doing what you are doing.
And people will be using the parsing version on the command line and
will not want the parsing version to change. Our command line idioms
are programmed into our brains, and are harder to change than doing a
global search and replace on a set of files in a directory.
That is, the issue arises when trying to port code written for one
implementation/OS combination to a different one or both ...
preferably with a macro or filter to convert from the local
implementation parsing version to the portable non-parsing version.
> OTOH, I think it is likely that they won't write
> require %inc%/name.fs
> either (which is even one character longer), so we might just as well
> forget about the prefix variant and just go with F" only.
And since it will only happen when explicitly trying to write portable
code (either from the ground up or in trying to port existing source),
its better to get out of the way of the parsing words, tell them to
keep on doing what they are doing, and provide a porting hook.
> >LF" ..." returns a string that refers to a file anchored in the
> >current library directory.
> I don't think that having only one library directory is practical.
> But we could have a library path (or a general path that includes the
> library path), and LF" (or P" or whatever the word is called) would
> produce the absolute name of the first match in the path; a library
> would have its own distinctively named subdirectory in one of the
> directories in the path; the distinctive name should avoid collisions.
Yes, that's a fine improvement/
LF" ..." returns a string that refers to the first file that is
encountered searching in the current library directory path. If the
filename is not found in the library directory path, it returns a
reference to that filename in the first directory in the library path.
|
