6.1.0030 # number-sign CORE

# deals with double numbers, and the stack effect reflects that. Not all words dealing with numbers deal with double numbers, e.g., + does not. So the answer to your first question is no.

The result of # goes to the pictured numeric output buffer, and that's the reason why it is required to be used inside <#...#>; <# does not change or look at the data stack. So the answer to your second question is no.

When you call # or #>, there has to be a double on top of the stack. The words are designed such that this is easy to achieve in usual usage, but if you want to use the words in unusual ways, you may have to put more thought into that. It's not necessary to have a double on the stack at all times between <# and #> (as demonstrated in GP3), so technically the answer to your third question is no.

Could I suggest that the definition be clarified to at least comment that many earlier versions of Forth used the same words to work on single width numbers.

I think this is one of the few cases in Forth2012 where the same name is used to have a significantly different stack effect from other common forth versions.

CHARS is another example.

Interesting, this definition is inherited directly from the ANS Forth document (1994). The previous standard Forth '83 has the definition:

# +d1 -- +d2 79 "sharp"

The remainder of +d1 divided by the value of BASE is converted to an ASCII character and appended to the output string toward lower memory addresses. +d2 is the quotient and is maintained for further processing. Typically used between <# and #> .

While the Forth '79 standard has:

# ud1 -- ud2 158

Generate from an unsigned double-number d1, the next ASCII character which is placed in an output string. Result d2 is the quotient after division by BASE and is maintained for further processing. Used between <# and #>. "sharp"

Yes it does have ud1 and ud2 in the signature and refer to d1 and d2 in the definition, at least they cleared that up in the '83 standard.

Therefore any system using single cell numbers for # are not and never have been standard. I see no need to refer to old non-standard systems.

I fail to see how CHARS can be considered another example as CHARS was introduced in the ANS Forth Standard document and this definition is inherited directly from that document.

I think the systems being referred to are those based on Ting's eForth - these were the only two conflicts I found, where the same name was used with different behavior. <# # #S #> on eForth use single precision numbers, and CHARS outputs a char a multiple number of times. When I was converting webforth over from eForth to Forth2012 both of those conflicts bit me as well.

Someone (and it seems that you, MitraArdron feel the itch) could add comments to # and CHARS that warn eforth users that eforth uses non-standard meanings for the respective word.

Happy to Anton, but I haven't contributed any text to the standard yet, and its not clear how to do this other than adding a Comment, which I think is what we did ... i.e. it ends up in this section where we are discussing. Could you point me in the right direction.

Yes, I meant such a comment. The difference from this comment would be that the comment would point out the problem (non-standard behaviour of eforth) right from the start instead of it being buried deep down in our exchange, and that there would also be such a comment for PARSE. And we could close this comment, which I am now doing (you can reopen it if you feel the need).

OK Anton, done - if that matches what you want I'll add it to the other words.

Shouldn't the burden be on eForth to document that it is non-standard?

Actually # etc. use double numbers in all Forth standards. It seems to me that it's some newer minimal systems (especially with wider cells) that don't want to implement all the prerequisites of a proper double-cell # and therefore choose to change # to work on a single cell.

It's a good idea if such systems document this deviation from standard and common practice, but given that at least one user was not aware of the difference, adding a warning here may be helpful.

It would be an even better idea if these systems used different names for their non-standard words.

As a maintainer of an old 8bit STC eForth variant I'm taking note of this discussion, and I'm of course thinking about options as using 32 bit math on a 8 or 16bit system is expensive. Before I take a decision, I'd like to clarify what "double" means on the background of the discussion "S>D in the standard, not double word set". I'd like to know what a double is in a system with 32 cells ( I'm reminded of the ambiguities of int and long int with respect to the native word width in the C language).

Doubles always use two cells. E.g., on a system with 64-bit cells, a double is 128 bits wide; an ud is in the range 0..2^128-1, a 2s-complement d in the range -2^127..2^127-1.

Leon, Anton - Does eForth predate those standards? There seem to be a lot of systems based on it - probably because its one of the few (if not the only) one that is both simple, and relatively complete - I've happily converted webForth which was based on eForth but is now Forth2012 compliant, but this tripped me up as its one of only a couple of places where the same word is used in eForth and Forth2012 with different stack effects. (I was asked to write the opening contribution as a constructive place to document that difference here, so that it doesn't trip other people up).

As far as I remember, eForth is later than most Forth standards, all of which use double-precision cells for the <# # #> and friends. Even on 64 bit systems, there is an argument for <# # #> and friends to use double-cell numbers, as this can make floating point conversion more accurate as the mantissa conversion can be arranged to be to 128 bit integers.

The design decisions of eForth and JonesForth should not influence the standard, nor should these be treated as model implementations of anything other than themselves.

According to eforth.src, eForth is from 1990, based on bForth from 1990, a decade after Forth-79 standardized # as working on doubles (and all standards since Forth-79 have kept this # (with the only variation that Forth-83 let # work on +d, while Forth-79, Forth-94, and Forth-2012 let it work on ud).

Closing because this comment has been answered.

For implementations that do not want to support full double arithmetic, it appears that Forth-2012 permits an implementation where a double uses fewer bits than twice the number of bits in a single. That is, I argue that as long as a single has at least 32 bits (the minimum required range of a double), an implementation-defined encoding of doubles where the only valid representations of a double are ( u 0 ) and ( n.negative -1 ) is possible (even if the testsuite needs more work before passing all tests on such a system). With that definition, an implementation could be as simple as:

: # ( ud1 -- ud2 ) \ Implementation for a system where all significant bits of a double fit in a single
  dup 0<> -24 and throw \ reject input that is not an unsigned double in implementation-defined form
  base @ um/mod 0 rot ( ud1 -- ud2 rem ) \ single division adequate in this implementation
  dup #9 > #7 and + '0' + hold ;