anton@[EMAIL PROTECTED]
(Anton Ertl) wrote:
> Bruce McFarling <agila61@[EMAIL PROTECTED]
> writes:
> >As far as I recall, the Directories proposal foundered on the
> >question of what should be the prefix.
>
> >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).
> >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.
Just as a possibility, if each library was in a virtual file system, you
could arrange them in some consistent way that could be independent of
operating systems etc, and if you can access the file that holds the
virtual file system then everything from there ought to just work. At
least you get to decide how it works, and it can be independent of OS
etc. Would that help clear up this thicket?
Or is it important to use libraries to set a precedent that helps solve
the problem more generally?
|
