Re: 2nd RfD: Directories
- From: Bruce McFarling <agila61@xxxxxxxxxxxx>
- Date: Thu, 26 Jul 2007 15:04:05 -0700
On Jul 22, 7:43 am, an...@xxxxxxxxxxxxxxxxxxxxxxxxxx (Anton Ertl)
wrote:
Finally, how do we expand these filenames to a sourcefile-independent
form? The source file of the string is important for the expansion,
not the source file of the consumer of the string (in the rare cases
where the consumer is not in the same file as the string); so the best
option is probably to have a special filename-string word like F" and
not perform the expansion in the consumer (INCLUDED, OPEN-FILE etc.).
In order to keep the conveniences of the parsing INCLUDE and REQUIRE,
these should expand the string after parsing. In addition, a word
INCLUDE-NAME-ABS for converting a string from an include-relative
filename to an absolute filename is a natural factor of these words
and can be useful in some cases.
There are different levels of "portability" that crop up in the
general problem statement, ranging from installing a source file in a
different system sharing a common operating system, but possibly with
a different path ... through to installing a source file in a
different operating system and implementation.
A1. The solutions to porting across the range of scenarios should nest
comfortably, so that provision for porting source code across the
widest range of systems and implementation ... the "Greatest Common
Denominator" solution with the widest scope ... does not interfere
with solutions that are narrower in scope.
An implementation can readily enforce a filename portability solution
for different instances of that implementation by translating in the
consumer of the filename.
However, there is an implication to translating in the consumer:
A2. If the filename is translated in the consumer, it is important the
application author be able to express any location in the file
hierarchy, without interference from the system for referring to
generic locations in the hierarchy.
As shown by the experience that Stephen Pelc cites with VFX Forth
expanding macros in Windows filenames, and the experience that Anton
Erl cites with gforth treating "./" as "location of the current source
file", with both of the two most broadly distributed large operating
systems, it is possible to arrive at a solution that provides a
comfortable fit to the namespace of that system.
If Unix/Linux/etc. implementors arrive at a common convention for
access to the directory of a current source, reference to a common
Forth library path, and access to the current working directory for
file-processing tasks, that is a good thing in its own right, entirely
independent of how broadly that is transported outside of the various
Unix-based filesystems.
In my third assertion, though, there is a point that I am not sure is
fully recognized.
A3. For cross-platform, cross-system portability, it is not
*necessary* for the application author be able to express any location
in the file hierarchy. It is *sufficient* to be able to express any
location within the hierarchy of the application itself, a hierarchy
of forth library files, and in file-processing applications, the
location of the target files for processing. The first two are within
the control of one or more Forth application author(s). The third can
normally be accessed without specifying a directory by relying on a
current working directory.
A4. Any unambiguous file naming system, combined with a word to
translate it into a file reference suitable for the implementation,
can meet the needs of a cross-platform, cross-system portability
standard, if it consists of one or more pre-defined special leading
characters, followed by one or more directory names and a file name,
with a pre-defined path separator.
In the abstract this would require, *at most*, a one-time renaming of
a hierarchy of cross-platform library files ... and in reality, cross
platform library files avoid a hierarchical structure, precisely
because of the lack of a cross-platform system for referring to a
hierarchy, so not even this one-time maintenance step would be
required.
In order to avoid interference ... either working interference or
conceptual interference ... this specific example avoids the use of
"./", which as far as I understand is already translated in the
consumer by gforth, and %name% macros, which are likewise already
translated in the consumer by VFX Forth.
Words:
AS-FILENAME ( ca u -- ca' u' ) translate the portable Forth file
reference in the string referred to by ( ca u ) into the appropriate
corresponding file reference for the implementation.
F" ( portable-file-reference" -- ca u ) the "-delimited parsing
version of AS-FILENAME.
cross-platform portable file references
The "/" path separator should be made available, by mapping if
necessary.
The following Portable Filename Character set should be made
available, by mapping if necessary.
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
0 1 2 3 4 5 6 7 8 9 - _ .
"-" should not be the leading character of a directory or file name
Systems may be either case sensitive or case insensitive, so treat the
system as case-sensitive, but do not rely on case alone to distinguish
directory or file names.
Restrictions: the single-character directories "@" and "#" are not
accessible as subdirectories of a source file directory. All portable
file references are relative to either the current source file
directory, the current default directory, or the implementation-
defined Forth library directory.
In the below, the text "filereference" refers to a string such as:
myfile.f
or
mydir/mysubdir/myfile.f
F" filereference" ... signifies the file relative to the same
directory as the source file (the directory of the command line is
taken to be the current default directory)
F" @/filereference" ... signifies the file relative to the current
default directory.
F" #/filereference" ... signifies the file in the default library
directory.
Note that this does not provide for giving the absolute location of a
master source file, nor for changing the current default directory,
nor for setting the default library directory. All of this is
information that is *exported to* the cross platform code by the
actions of the user, not *contained within* the cross platform code.
Also note that this does not include any provision for coping with
arbitrary depth file hierarchies or long file names in niche systems
with fixed depth hierarchies. flat file systems, or file systems with
short file names.
Given the prevalence of file systems that can be seen as supersets of
POSIX.3, including flash parts with embedded FAT32 filesystems, it is
left up to implementors on more restricted systems to decide how much
filename mapping they want to provide.
.
- References:
- 2nd RfD: Directories
- From: Anton Ertl
- 2nd RfD: Directories
- Prev by Date: Re: 2nd RfD: Directories
- Next by Date: Re: Yadda Yadda Blah Blah Blah
- Previous by thread: Re: 2nd RfD: Directories
- Next by thread: RomDoor released
- Index(es):
Relevant Pages
|
