Re: relative-to-source file names

On Jan 20, 6:39 am, stephen...@xxxxxxxxxxxx (Stephen Pelc) wrote:
#INCLUDE Alternative 1: magic quotes ... <filename.fs> for an
implementation-defined library directory (this is upwardly compatible
with an implementation defined library path), "filename.fs" for source
file relative. % is reserved for macro expansion, for those
implementations that support, and macro expansion is applied prior to
resolving relative to absolute locations.

...

Forth is not C. There's no need to mimic the C notation. It just leads
to horrible parsing needs. All one wants is to know *how* #INCLUDE
will use the following name. At this stage, there is still a chance
for the notation to be designed rather than hacked.

That was your proposal, of course, but seemed one Anton might not
mind.

Macro expansion is already in proposal stage, ready for a CfV. Both
Windows and Linux apps already have to deal with
  "file name with spaces.fs"
and common practice there is to use one or both forms of quotes. We
already have escaped strings in fairly widespread use.

What is the common practice for directories with spaces, is it:

%basepath#/"My Subdirectory With Spaces"/"My Filename With Spaces.fs"

or:

%basepath#/"My Subdirectory With Spaces/My Filename With Spaces.fs"


A possible design could use the letters I, L, S and W to mean
Include, Library, Searchlist and Workingdir leading to
  #include I foobar.fs
  #include S "a file name with spaces.fs"
  #include L %arch%/%dev%/secret.fth
Now #INCLUDE has no problems with file names with spaces or
even macros. There are plenty of characters for further
expansion of "how". For application use, e.g. when file names
come from a database (such systems do exist), there's probably a
factor such as:
  #INCLUDED  \ fname flen how --

Now the difference between F" and similar and #include is a processing
word versus a magic code. And you have included one intrinsically
system-dependent and therefore more appropriate for INCLUDE and
omitted the one out of two missing, the relative to source ... but
while using a letter token to indicate this is opaque, and a bit
inelegant and ungainly, its workable.

With %lib% pre-defined, this is compatible with an implementation that
has a library path rather than a simple library directory, by special
casing %lib% and running the macro expansion on the balance of the
string.

Please note that VFX uses %lib% and %librarydir% already
and both of them specify the library directory.

Yes. Of those two, %lib% is most appropriate for standardization
beyond the scope of the macro expansion tools.

So there is nothing mutually exclusive about the *approaches*, its
just the need of each to accommodate the other in the design of the
common facility, which has not been part of the design target for
anybody, incompatible *implementations* then convincing people that
there is something mutually exclusive to the *approaches* when in fact
there is not.

I agree, the argument is about notation.

That's progress in any event - previously it was reading as if macro
expansion should be the one and only permitted standard means of
referring to directory paths, rather than the standard means of
referring to directory paths ought to be designed to be compatible
with macro expansion.

.