On Mar 30, 3:01 pm, an...@[EMAIL PROTECTED]
(Anton Ertl)
wrote:
> It also leads to proposals for "fixing" REPRESENT that break existing
> code and are very bad in other respects, too.
Is this the Represent_21.txt that you are referring to?
MAX-FLOAT-DIGITS as an environmental query, and:
(1) REPRESENT always returns the string the longer of n1 and MAX-FLOAT-
DIGITS
(2) 0 is 0.00E+1
(3) Round to nearest used
(4) n1=0 -> significand rounded to closer of 0 or 1
(5) flag2=false string at ( ca ) is left aligned and padded with
spaces
I never had to use REPRESENT portably, I only had to use it correctly
on a given system, so I was happily ignorant of the complexities of
accounting for all the varieties of semantics that are allowed in
Forth-94. Once it worked in gforth, it worked. And it was only really
scientific notation that I needed, for SNA data and therefore only
robust to three digits of accuracy, so I felt 6 significant digits was
ample.
If a proposed "fix" of REPRESENT is specifying one of the several
outcomes that are allowed under Forth-94, then it breaks code that
assumes more than the Forth-94 standard warrants.
However, from the side of a library side that namespace control, it is
simpler for me to pin down one set of semantics, and wrap the
implementation REPRESENT to deliver that.
There is, of course, the additional question of whether the semantics
in that proposed fix are the preferable semantics.
If a proposed "fix" of REPRESENT is specifying a facility that is not
compatible with Forth-94, then it should not be called REPRESENT.
|
