Path: csiph.com!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail From: "Rod Pemberton" Newsgroups: comp.lang.forth Subject: Re: gforth too bloated ? Date: Wed, 21 May 2014 17:40:56 -0400 Organization: Aioe.org NNTP Server Lines: 112 Message-ID: References: <4b4ea6f6-3b09-434a-a501-ff31190b9f4a@googlegroups.com> <2014May13.184005@mips.complang.tuwien.ac.at> <47qdnXip89VGwe_OnZ2dnUVZ_jadnZ2d@supernews.com> <2014May14.140323@mips.complang.tuwien.ac.at> <7xha4sl4hf.fsf@ruckus.brouhaha.com> <2014May15.162231@mips.complang.tuwien.ac.at> <2014May16.151900@mips.complang.tuwien.ac.at> <2014May18.152057@mips.complang.tuwien.ac.at> <2014May20.135936@mips.complang.tuwien.ac.at> NNTP-Posting-Host: CNsg4fVcCsvs3UaOgZtQCw.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Opera Mail/12.16 (Linux) X-Notice: Filtered by postfilter v. 0.8.2 Xref: csiph.com comp.lang.forth:30539 On Tue, 20 May 2014 07:59:36 -0400, Anton Ertl wrote: > "Rod Pemberton" writes: >> On Sun, 18 May 2014 09:20:57 -0400, Anton Ertl >> wrote: >>> However, what you missed is that, however simple you may claim the >>> reversal is, you got the order in this relatively simple definition >>> wrong on the first attempt. >> >> Not true. >> >> I was asking about why a word used to define locals wasn't used. >> That seemed far more reasonable to me than the braces. >> >> You chose a Forth, iForth, which happened to have a word LOCAL >> which worked similarly to what I was asking about and named the >> same as what I chose, but has a different ordering from what I >> posted. That doesn't get to redefine or define the order on >> what I posted. >> >> So, the supposedly incorrect ordering was actually "ex post facto". > > Name one Forth system that has LOCAL, where the first version of your > 2DUP works! > I can't because none of them exist. I was not aware that a word named LOCAL existed in some Forths. As far as I knew, it was only the name I applied to the concept I was attempting to discuss: replacing brace based locals with a single word declaring each local independently. If that's what's causing you issues, we can change it if you wish, ex post facto, so that it's less confusing as to what I was saying: s/LOCAL/RODSLOCALCONCEPT/ > The word LOCAL has been discussed here several times, always with the > meaning implemented in iForth. Why do you claim you had a different > meaning in mind, [...] See above. > [...] and if so, why did you not explain that meaning when > you posted the code, nor when I first pointed out the mistake [...] It seemed obvious to me, but it's clear now that my perspective is different from yours. > (instead, you posted two versions of the code that would work with > iForth). I was just pointing out that if an actual implemenation of the concept works differently than a theoretical one, it's easy to correct the syntax. > So how would you specify your LOCAL with { ... } like ordering, and > how would it be implemented? As stated previously, (see "Admittedly, it's likely...") if an implementation is stack based it would likely to work like iForth. If some other method was used, it could be different. >>> Reverse polish notation is "x y -" >> >> Is that "x - y" or "y - x" ... ? > > x-y in infix is x y - in postfix. Is x subtracted from y or is y subtracted from x? It's not clear from Forth's "x y - " order. Typically, Forth use the top-of-stack as the primary value operated against. That would indicate x is subtracted from y. That's the opposite of the actual ordering. I.e., this is an example where ordering is "not important" in Forth. This was stated previously here: >> Most stack operators operate against the top-of-stack as the >> primary data item. Subtraction in Forth is reversed from that. >> The point is that the order is not clear, and could be perceived >> as being reversed by some people, even some Forth programmers. >> I.e., it could be argued that subtraction in Forth should've >> been implemented as "y - x". >> >> So, how is the "reversed" order here any different from LOCAL? > > Are you really arguing that subtraction in Forth should have reversed > arguments [...] in order to justify that the error-prone LOCAL is > "better" than { ... } ? No, I'm pointing out that Forth has never made any attempt at using a rational and consistent order of operations. I.e., if it's not a problem with other long implemented things in Forth, why does is it matter for LOCALS? From my perspective, the answer is that it doesn't. It's rhetorical. > (without giving a reason for that) This was stated previously too: RP> "Most stack operators operate against the top-of-stack as the primary data item." > Reality check: The ordering of - arguments is not reversed, [...] ... > [...] and the iForth LOCAL is error-prone, [...] As my brother likes to say for any statements he perceives to be unfounded: "That's YOUR opinion." The point is it shouldn't really matter if it's backwards or error prone in Forth. Forth is rife with such unfixed issues. Rod Pemberton