Anything more before 0.13.0 is tagged?

[SirWumpus]

@rub @wboeke Are there any more critical issues at the moment? I'd like to tag the repository with 0.13.0 as a stable check point this week.

[wboeke]

Hi, Hopefully this mail does reach you. You asked for any issues for post4, but I have none!

[ruv]

Are there any more critical issues at the moment?

At the moment I don't see anything critical.

---

Regarding features.

1. The word synonym is wanted (see also the proposal Tighten the specification of SYNONYM).

2. Some Forth systems support lading a file with a path relative to the file being loaded. This is important for packages. You might want to add this feature (see my implementation).

[SirWumpus]

The word synonym is wanted (see also the proposal Tighten the specification of SYNONYM).

I have ALIAS

post4/src/post4.c

Lines 1761 to 1767 in a089958

	// ( xt -- <spaces>name )
	_alias: P4_DROP(ctx->ds, 1);
	str = p4ParseName(ctx->input);
	word = p4WordCreate(ctx, str.string, str.length, x.xt->code);
	word->ndata = x.xt->ndata;
	word->data = x.xt->data;
	NEXT;

Some Forth systems support lading a file with a path relative to the file being loaded. This is important for packages. You might want to add this feature (see my implementation).

Hmm. "lading"? Oi! Lads, we should go lading tonight. Maybe we can find some lasses lassing.

[loading] a file with a path relative to the file being loaded.

I cannot think of a precedent for this in other computing languages. C has #include <x> or #include "x"; shell source path. I have INCLUDE-PATH, INCLUDED-PATH, REQUIRE-PATH, REQUIRED-PATH which search $POST4_PATH, this is similar to Java's $CLASSPATH. I figured packages would live in /usr/local/lib/post4/* or other search locations.

I've only just woken up (puppy waiting for his walk under the desk) so have not yet read your feature, but maybe you need a PACKAGE-INCLUDE or PACKAGE-REQUIRE for this behaviour?

[ruv]

I have ALIAS

Yes, but this word cannot be used in a standard program.

---

Hmm. "lading"? Oi! Lads, we should go lading tonight. Maybe we can find some lasses lassing.

🤣

[loading] a file with a path relative to the file being loaded.

I cannot think of a precedent for this in other computing languages.

Links in HTML are either absolute or relative to the file where they are used (well, for the sake of clarity, different options of relativity are omitted). The same for <xsl:include/> in XSLT (but they also take into account optional xml:base attribute in the ancestor elements). The same in Node.js / require.

C has #include <x> or #include "x"; shell source path.

Doesn't #include "x" interpret "x" relative to the current ("parent) file location?

I have INCLUDE-PATH, INCLUDED-PATH, REQUIRE-PATH, REQUIRED-PATH which search $POST4_PATH, this is similar to Java's $CLASSPATH. I figured packages would live in /usr/local/lib/post4/* or other search locations.

I've only just woken up (puppy waiting for his walk under the desk) so have not yet read your feature, but maybe you need a PACKAGE-INCLUDE or PACKAGE-REQUIRE for this behaviour?

Have a look at fep-recognizer/implementation/

The file implementation/index.fth contains an instruction to include ./variant.gamma/index.fth, which includes other files in the ./variant.gamma/ subdirectory. How to include that files?

[SirWumpus]

[loading] a file with a path relative to the file being loaded.

Still on this one. Typically something like #include "foo.h" loads from the current working directory, similarly #include "../pkg/bar.h" also relative the current working directory.

INCLUDE et al. all allow relative paths from the current working directory, not just absolute. For example when testing post4 from the post4/src directory I often say INCLUDE ../examples/ed.p4 or similar.

Not tested, but I think INCLUDE-PATH will allow relative paths from one of the $POST4_PATH directories too, plus absolute paths. So in the case of C includes, header files could be aware of the source tree structure, usually a bad idea. Likewise Forth systems might behave similarly, dependent on the current working directory and the include file being aware of its source tree structure.

Now if I understand your request, you want an include variant that tracks the include directory of the file so that companion files can be found relative to the current include. That could be messy and when you factor in nested includes could be a problem.

Not sure I want to think about this before bed, might cause nightmares and visions of spaghetti (or Klingon gagh).

[ruv]

Now if I understand your request, you want an include variant that tracks the include directory of the file so that companion files can be found relative to the current include.

Yes. This is a kind of encapsulation.

That could be messy and when you factor in nested includes could be a problem.

Could you please provide an example of the problem?

In fact, the usefulness of this feature is not in question. The only question is what is the interface of use.

There are several options:

1. a separate word to load a file relative to the parent file location,
   - e.g. include-local foo/bar.fth;
2. explicit resolving a relative path on the path of the parent file,
   - e.g. s" foo/bar.fth" source-uri resolve-uri included;
3. use some special format that tells the system that the path is relative to the parent file (i.e., the file being loaded),
   - e.g., if the path starts with ./, then it is relative to the parent file: include ./foo/bar.fth;
   - or use a special "protocol", e.g.: include local:///foo/bar.fth;
4. implicitly try to find a file (if its path is not absolute) in several locations, and load the first file that exists:
   - resolve the path on the parent file,
   - resolve the path on the working directory,
   - resolve the path on predefined directories.

All these options can be found in Forth programs in the wild. I'm leaning towards option 3, and option 2 should be provided anyway as an API.

What do you think?

[SirWumpus]

Could you please provide an example of the problem?

Nope not yet. Its in a dark corner of my head, where childhood monsters like to hide.

1. a separate word to load a file relative to the parent file location,
   - e.g. `include-local foo/bar.fth`;

Sort of like this as a I like this as the top word.

2. explicit resolving a relative path on the path of the parent file,
   - e.g. `s" foo/bar.fth" source-uri resolve-uri included`;

This or similar under the hood to build the top word.

3. use some special format that tells the system that the path is relative to the parent file (i.e., the file being loaded),
   - e.g., if the path starts with `./`, then it is relative to the parent file:  `include ./foo/bar.fth`;
   - or use a special "protocol", e.g.:  `include local:///foo/bar.fth`;

Not sure I like the idea of introducing URI schemes, cause some one is going to come along and ask for https: or imap: and of course you then need to support file: (default URI) and who knows, maybe data: too (s" data: words go here" included).

However, local: is the sort of scheme I'd expect some RFC to define for local networking, so maybe best to avoid possible RFC candidates. Given you keep talking about "relative to the parent" maybe something more on the nose like parent: or child: scheme. BTW I think the // probably don't apply here as they have special meaning in RFC 2396 (need to re-read that as its been a LONG TIME) related to network resources.

Or create a specialised scheme set-module <name> include module:<name>/relative/path.

4. implicitly try to find a file (if its path is not absolute) in several locations, and load the first file that exists:
   - resolve the path on the parent file,
   - resolve the path on the working directory,
   - resolve the path on predefined directories.

This I like, cause its easy to implement quickly (and play with) and sort of a natural extension to what is already provided (points 2 & 3) eg. REQUIRE ../examples/ed.p4 and REQUIRE-PATH ed.p4

Essentially I can easily see that a package's entry point could temporarily prefix its directory to list of paths to search. What happens though if you move up/down/sideways in a tree? Does the path list get updated with each file included/required? Could make for LONG lists. When does the list change? Do you need some sort of word to "anchor" a package, eg. prefix-path append-path adds a parent to the list until the next prefix or append by another package? What if a package nests other package dependencies?

All these options can be found in Forth programs in the wild. I'm leaning towards option 3, and option 2 should be provided anyway as an API.

What do you think?

Mind. Boggle. /tmp is full. Too much before breakfast.

[ruv]

One more very useful word is execute-parsing ( any sd xt -- any ) (also known as evaluate-with), which is similar to evaluate, but executes xt instead of interpreting.

[SirWumpus]

So if I understand what the word does, it essentially sets a temporary input source while executing xt. Not sure I like the name (names are never easy to choose) execute-with-string or to borrow from shell terms, execute-here-doc.

How/when would execute-parsing be used?

Something like?

: set-source ( sd -- ; R: -- addr.input ) _ctx ctx.input @ tuck in.length ! swap in.buffer ! ; 
: execute-parsing (any sd xt -- any ) >r _input_push set-source r> execute _input_pop ;

[ruv]

How/when would execute-parsing be used?

1. The standard does not provide postfix factors for defining words (like :, constant, create, etc). Therefore, creating named definitions programmatically is awkward. With execute-parsing it's more elegant: 123 s" myname" ['] constant execute-parsing (see an example from my practice).

2. In some cases it's convenient to employ the words parse and parse-name for parsing text.

Something like?

Yes, but it should use catch to execute xt, to ensure that the prior input source specification is restored.

And, according to the stack diagrams, the fragment set-source r> execute is incorrect.

[SirWumpus]

0.13.0 was pushed this morning. These feature requests will be part of the next release.