Path: ...!feeds.phibee-telecom.net!2.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Ruvim Newsgroups: comp.lang.forth Subject: Standard compliance for systems (was: single-xt approach in the standard) Date: Mon, 23 Sep 2024 10:56:46 +0400 Organization: A noiseless patient Spider Lines: 87 Message-ID: References: <1a3ebf77c1ed8926d455a268e1309fe0@www.novabbs.com> <66ee34a2$1@news.ausics.net> <66ef7dc7$1@news.ausics.net> <66f0fc6c$1@news.ausics.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Mon, 23 Sep 2024 08:56:48 +0200 (CEST) Injection-Info: dont-email.me; posting-host="33b085eef38ab766afb617aef8ec1273"; logging-data="2290480"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX190hnavaBECGfqx2SqVQPZP" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:xEhaUcHvYw4wDLmOVGY6lfcWaK8= In-Reply-To: <66f0fc6c$1@news.ausics.net> Content-Language: en-US Bytes: 4375 On 2024-09-23 09:28, dxf wrote: > On 23/09/2024 2:57 am, Ruvim wrote: .... >> NB: Keeping floating-point numbers on the data stack does not make a Forth system non-standard, but it merely adds an environmental restriction to this system, see the section "12.4.1.4 Environmental restrictions" in Forth-2012. > > I hadn't seen that. Forth-94 stated floating-point stack was "the default". > If the only change is that the latter is clarified, then no harm done. > Implementing separate stack on an 8-bit cpu would be expensive and a > performance killer. > As to being "far simpler" to program, similar appeals > are made in respect of locals. > I make it a point to program as if I had a > unified stack just to see if the claim is true. A real problem was to create programs that work with floating point numbers and would work correctly both on a unified fp stack and on a separate fp stack. See the section "C.7.2 Separate Floating-point Stack is now Standard" in Forth-2012 > >> 2) Quote-delimited character interpretation ('A') makes programs simpler, this seems obvious. > > Only thing obvious is it's an import from other languages and redundant. > Forth Inc stated they didn't agree with it but eventually provided it. > Using `'x'` is simpler and shorter than `[char] x` or `char x` depending on the context. And even if you redefine `[char]` to provide the expected interpretation semantics, like: : [char] state @ if postpone [char] else char then ; immediate `[char] x` is still longer than `'x'` and provides no additional benefit to programs. >> 3) Two buffers for interpretive `s"` makes debugging simpler, because you can test words like `rename-file` interactively, see "A.17.3.4 Other transient regions" in Forth-2012. > > I have >PAD ( adr u -- adr2 u ) for that. Uses existing resources and is > more flexible. > The phrase: s" foo" s" bar" rename-file . is simpler than: s" foo" >pad s" bar" rename-file . What advantages does the latter provide to users over the former? If a Forth system is so limited in memory that it cannot provide two buffers for `s"`, it *might* provide only one buffer and declare the corresponding environmental restriction according to the sections: - 5.1.1 System compliance | An otherwise Standard System (Subset) that fails to comply | with one or more of the minimum values or ranges specified | in "3 Usage requirements" and its sub-sections has | environmental restrictions. - 5.1.2 System labeling | The phrase "with Environmental Restrictions" shall be | appended to the label of a Standard System (Subset) that | has environmental restrictions. - 11.3 Additional usage requirements, 11.3.4 Other transient regions | The system provides transient buffers for `S"` and `S\"` | regions strings. These buffers shall be no less than 80 | characters in length, and there shall be at least two buffers. -- Ruvim