Date: Mon, 4 May 2026 11:02:54 +1000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: The joy of formatting Newsgroups: comp.lang.forth References: <69f2ba42$1@news.ausics.net> <69f36016$1@news.ausics.net> <69f3ec53$1@news.ausics.net> <2026May1.080355@mips.complang.tuwien.ac.at> <69f74911@news.ausics.net> <2026May3.161118@mips.complang.tuwien.ac.at> Content-Language: en-GB From: dxf In-Reply-To: <2026May3.161118@mips.complang.tuwien.ac.at> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit NNTP-Posting-Host: news.ausics.net Message-ID: <69f7f03e@news.ausics.net> Organization: Ausics - https://newsgroups.ausics.net Lines: 52 X-Complaints: abuse@ausics.net Path: csiph.com!news.bbs.nz!news.ausics.net!not-for-mail Xref: csiph.com comp.lang.forth:135060 On 4/05/2026 12:11 am, Anton Ertl wrote: > dxf writes: >> IIRC the standard makes no mention of what needs preserving. > > It actually states explicitly what is not guaranteed to be preserved. > In particular, > > says: > > |The previous contents of the regions identified by [...] #> may be > |invalid after each use of these words. Further, the regions returned > |by [...] #> may overlap in memory. Consequently, use of one of these > |words can corrupt a region returned earlier by a different word. The > |other words that construct pictured numeric output strings (<#, #, #S, > |HOLD, HOLDS, XHOLD) may also modify the contents of these > |regions. Words that display numbers may be implemented using pictured > |numeric output words. Consequently, . (dot), .R, .S, ?, D., D.R, U., > |U.R could also corrupt the regions. > > Note that AT-XY is not included in this list (and chapter 10 does not > add it to this list). So > > 123. <# #s #> 3 4 at-xy type > > should display "123" at position 3,4. Testing this with a few Forth > systems, gforth, iforth, and SwiftForth pass this test, while lxf and > VFX don't. AFAICS there's nothing in the standard that says it "should" display 123 in that case. What happens in the absence of specification becomes a matter of interpretation. We know the standard made effort to specify corner cases e.g. u=0 in CMOVE. So if it were up to me I would say the standard simply didn't consider the case you specify. One certainly needs to ask what is the likelihood of the case you specify arising. > >> Some >> implementations preserve BASE; while others don't. >> As far as standard words are concerned, only DECIMAL and HEX are > allowed to change BASE (the specification of DECIMAL could be better, > however), and of courseyou can change BASE explicitly, e.g., with > > BASE ! Unlike the HOLD buffer, I would say a case can be made for preserving BASE across AT-XY calls. Since ANSI AT-XY sends coords in ASCII decimal rather than binary, it would be a burden on apps to ensure BASE was decimal. In such case I would seriously have to consider Albert's DEC: - irrespective of whether my AT-XY was personally affected or not. From a brief survey I would say most ANSI AT-XY implementations do in fact preserve BASE. And perhaps the standard should specify that.