[29] 2017-04-16 08:03:17 AntonErtl wrote:

proposal - Core-ext S\" should reference File-ext S\"

The references don't link to File-ext S". At least one user thought that the standard does not define interpretation semantics for S" at all.

Do we actually need Core-ext S" at all? Isn't File-ext S" enough? Are there any systems that implement the Core-Ext version and not the File-ext version?

[r76] 2017-04-15 19:03:39 gnuarm replies:

proposal - Implementations requiring BOTH 32 bit single floats and 64 bit double floats.

There are a number of smaller CPUs that implement 32 bit IEEE floating point in hardware and not 64 bit. They work exclusively in 32 bit without the extended precision intermediate values used in x86 and similar CPUs. Seems 32 bit floating point is adequately addressed by the present standard to support these smaller devices. Or am I missing something?

[r77] 2017-04-16 07:54:38 AntonErtl replies:

proposal - Implementations requiring BOTH 32 bit single floats and 64 bit double floats.

Sure, if you have a 32-bit-FP-only FPU, you (as systems implementor) will probably go for 32-bit floats. The question at hand was if we should have multiple FP types for FPUs that support 64-bit and 32-bit floats.

[r78] 2017-04-16 21:54:19 BerndPaysan replies:

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".