Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Paul Rubin Newsgroups: comp.lang.forth Subject: Re: "Forth is Sudoku for programmers" Date: Sun, 21 Aug 2016 12:52:23 -0700 Organization: A noiseless patient Spider Lines: 30 Message-ID: <87a8g5sxvs.fsf@jester.gateway.pace.com> References: <1e1c16c6-300f-4c4f-8590-379029478232@googlegroups.com> <3df7e7c1-9b33-450d-89b3-a66c9ea9f859@googlegroups.com> <87h9agthh5.fsf@jester.gateway.pace.com> <87d1l4t9gv.fsf@jester.gateway.pace.com> <9a2b3c38-f34b-459e-b07a-b448d5007139@googlegroups.com> <1xpqu044ht68t.gd9k4bzxkk0l.dlg@40tude.net> <2016Aug21.115739@mips.complang.tuwien.ac.at> <971e65bc-d0c7-42cb-81f6-010ca343a0ec@googlegroups.com> <8db87724-dc68-43cd-94d6-1bebe2d13897@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="e3de301d7f270f19e44cbaddb3a92e97"; logging-data="24743"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19MoaUP2U5gfUbjDDlaNr1a" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:H/1MHoSUu83/bTnaHEvuOkhDCX8= sha1:/rkm6BLzmVuZs25Nn1T647+C/6o= Xref: csiph.com comp.lang.forth:50351 Julian Fondren writes: > Assuming you mean 'standardized functions' and 'non-standard > extensions', respectively, this still allows two contradictory systems > to be considered standards compliant, where programs on one system > won't work on another. The problem - the entire problem, the problem > that you are using as reason that the standard is bad - remains. My interpretation of Cecil's complaint is something like: word X might reasonably be used in situations A, B, C, and D, and there are several possible natural things for it to do in each of those situations. The standard says what to do in cases A, B, and C, but leaves D unspecified or ambiguous. Vendors implement cases A, B, and C the way the standard says, and are left to their own devices with D, so they implement it in different, incompatible ways. Now if someone comes along and says "hey, let's standardize case D", well, by now it can't be standardized without breaking existing code. So it becomes another point of difference between implementations. This is perhaps a complaint-worthy situation because if the standard had specified case D in the first place, those incompatible treatments wouldn't have gotten into the wild. They'd have all done the standard thing. So the committee screwed up by not standardizing D when they could, leaving a legacy problem that's hard to solve after the fact. Of course that imagines that the incompatible treatments of case D weren't already out there before the process started.