Bruce McFarling <agila61@[EMAIL PROTECTED]
> writes:
>As far as I recall, the Directories proposal foundered on the question
>of what should be the prefix.
At the last meeting, we discussed this for a while, and IIRC the
prefix that met the least resistance there was %inc%.
>If "name.fs" is in the current working
>directory, and in "./name.fs", "./" is conventionally a no-op, then
>how can "./" change the meaning from cwd to the current source
>directory?
>
>How about: no prefix?
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).
With that out of the way, if "./name.fs" were to refer to the
"name.fs" in the cwd, so would "name.fs", no? Ok, not necessarily,
but it would be an exception, just as "./" would be an exception.
There are two reasons why having this meaning for "./" would be
preferable to having it for prefix-less names:
1) There are a lot of programs around that contain prefix-less names
that mean something system-specific (and I guess that too often that
meaning is not "relative to the directory containing this file"). A
proposal that required systems to interpret these programs and names
differently would meet even more resistance than "./".
In contrast, there are probably few, if any, Forth files containing
file names starting with "./", that mean something different from
"relative to the directory containing this file".
2) There is at least one system that implements "./" with the meaning
"relative to the directory containing this file", whereas I know of no
system that implements prefix-less names with that meaning (although
AFAIK several systems give meanings to prefix-less names that usually
include that meaning).
>SF" ..." returns a string anchored in the directory of the source file
That's certainly an approach that would avoid the whole prefix issue
completely. Another advantage is that it would do the anchoring at
the right place (in the file where the string sits, rather than in the
file where the string is used).
In the current proposal I propose F" ..." with the meaning you assign
to SF" ...". IIRC there was no feedback on that.
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
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. What do you
all think?
>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.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2008:
http://www.complang.tuwien.ac.at/anton/euroforth/ef08.html
|
