Proposal: Core-ext S\" should reference File-ext S\"

Actially, the file-ext version doesn't make much sense. S" is in file-ext, because for the file words, you need strings in interpretation mode. S" however is for strings with special characters, and file systems often forbid these special characters.

IMHO, the core ext S" should have interpretation semantics, and the file-ext one should go. Minimalistic systems which don't want the burden of interpretation semantics in S" will certainly not implement the rather complicated parser for S".

I can see S" being useful in embedded systems to construct strings for comms. Since embedded systems often don't have file systems it would be awkward to include the file words just to get a version of S". To me the question is why it needs to be in File-Ext?

I thought the lack of interpretation semantics in Core-Ext was so the string could be stored in non-volatile memory, but I don't know if that holds water. I'm also unclear on the requirement to not modify the string. Is that related to allowing the string to be compiled into non-volatile memory? Of so, why is that still imposed on the File-Ext version which has added interpretation semantics?

I guess I'm not clear on the reasons for these two restrictions.

You can include interpretive S" in your system even if you don't have file words. You may or may not be able to claim that the system has file-ext S", but who cares about that anyway. But sure, putting interpretive S" in file-ext is questionable. Should we move it elsewhere? Not sure. Disadvantage: Links to http://forth-standard.org/standard/file/Seq would break. Is the advantage big enough to justify that?

The reason for the core-ext and file-ext S" is probably because S" also has this split.

The reasons why a program must not change the string returned by compiled S" is the same in both versions: The c-addr may point to compiled code. Changing the string may change the string that is returned the next time that code is executed; or it may not; or it may cause an exception (if the string is protected by an MMU); or it may not even have an effect on the string that is returned this time (if the string is in ROM). Interestingly, that restriction is specified only for the compiled string: it's in the run-time semantics that is not exercised by the interpretation semantics.

Links don't break if we use a "moved permanently" redirect for expired links; that's a problem with a technical solution.

We might want to introduce something like an "optional functionality" of a word, without having it in two places. The interpretation semantics of S" and S" is optional. Note that S" is in FILE EXT, so it's even optional if you have the file wordset. The file wordset would require S"s interpretation semantics (no longer optional if you have the file wordset).

IMHO the S" and S" words should be moved out of the File word sets. It's just confusing and the conditions of 20 years ago no longer apply.

However, the decisions about interpretation and compilation semantics should surely be deferred until we have a notation for building separate semantics without invoking state-smart words. There are ways to do this that may even satisfy both Anton and Stephen, but they probably need to be locked into a room together at some time.

I am preparing a paper on the topic, but need more time before it can be published.

This is work for the editor.