Digest #19 2017-07-11
Contributions
Is %test% considered the same string as or different from %TEST% ?
Replies
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).
proposal - Implementations requiring BOTH 32 bit single floats and 64 bit double floats.
Which hardware systems do you know of that support higher precision floats, but can do the math in 32 bit floats rather than using higher precision for calculations while saving the results in 32 bits. The latter I believe is already supported by the existing Forth standard.
I certainly am not familiar with all systems, but the ones I am familiar with that support higher precision FP calculations will perform those higher precision FP calculations just as fast as 32 bit calculations.
I'm not clear what systems we are trying to not exclude? Graphics chips perhaps?
proposal - Implementations requiring BOTH 32 bit single floats and 64 bit double floats.
On current hardware FP that has both 64 and 32 bit operations, I can see no reason to implement the FP stack with 32 bit operations. The only area in which the 64/32 bit distinctions become significant is in memory access, for which we already have the SFx and DFx operations. Provision of 32 bit only FP for embedded hardware is likely to be a transient of a few years until silicon improves. We are already seeing this in the transition from Cortex-M4F (universally 32 bit until now) to Cortex-M7 (mostly 64 bit and 32 bit).
I'm tired of writing ARM and Cortex FP packages.
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.
Should we not use the name CREATE-DIR rather than MAKE-DIR in sympathy with the file words?