Path: ...!3.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: Re: VALUE and TO implementation Date: Mon, 5 Aug 2024 20:08:58 +0400 Organization: A noiseless patient Spider Lines: 37 Message-ID: References: <2af79ef5abcec71a1d42a461b6bc56b8@www.novabbs.com> <2024Jul31.193344@mips.complang.tuwien.ac.at> <2024Aug1.120730@mips.complang.tuwien.ac.at> <4b8297b5787264614edcb6180ef3e1b6@www.novabbs.com> <23a44aa0445a30c0fc782819f48463f9@www.novabbs.com> <66b0c4f2@news.ausics.net> <5eff99125b18466c3fdcd2a0cca8368b@www.novabbs.com> <66b0eabb$1@news.ausics.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Mon, 05 Aug 2024 18:09:00 +0200 (CEST) Injection-Info: dont-email.me; posting-host="aac5f2bad1664c7b692d7a3e22101e31"; logging-data="838299"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19FC3wbeS64altviDAtJUyd" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:8R/zKnFNflAXuAuzrKkm92HVKJU= Content-Language: en-US In-Reply-To: <66b0eabb$1@news.ausics.net> Bytes: 2840 On 2024-08-05 19:07, dxf wrote: > On 5/08/2024 10:38 pm, mhx wrote: >> On Mon, 5 Aug 2024 12:26:26 +0000, dxf wrote: >> >>> On 4/08/2024 5:17 pm, mhx wrote: >>>>> However, as I showed earlier, a parsing "TO" has several advantages over >>>>> a non-parsing "TO". >>>> >>>> Am I the only one that thinks parsing words are an incredible nuisance? >>> >>> Don't know but to this day Mitch Bradley (ANS, Open Firmware) still uses >>> parsing words to interpret hex, double, float numbers. >> >> "de gustibus non disputandum est." >> >>> He also uses state-smart words. >> >> Show me a Forther *without* strong opinions *and* unfathomable >> inconsistencies. > > I'm more interested in knowing how parsing words can be a nuisance? Do they > possess a life of their own? > We've been told state-smart words are evil. The only reason for that evil is that `POSTPONE` in a classic implementation behaves incorrectly for them. See "About POSTPONE semantics in edge cases" Nobody have pointed out any logical error in my reasoning. -- Ruvim