Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!nstn.ns.ca!news.cs.indiana.edu!att!ucbvax!ETSUACAD.BITNET!S47852EF From: S47852EF@ETSUACAD.BITNET ("Frank C. Earl") Newsgroups: comp.lang.forth Subject: Re: DEFER Message-ID: <9104101308.AA29165@ucbvax.Berkeley.EDU> Date: 10 Apr 91 00:30:03 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "Frank C. Earl" Organization: The Internet Lines: 69 On Mon, 8 Apr 91 22:09:45 EDT said: >The same way it's done in FIG Forth and in every other Forth implementation >that doesn't have DEFER : > > VARIABLE 'FOO : FOO 'FOO @ EXECUTE ; > >Obviously, this is a bit more trouble than > > DEFER FOO Ugly... And it's a bit more than a bit more trouble (?? :-)... The way I understand DEFER and how it's usually implemented is that DEFER CREATEs a header and links the PFA up so it's pointing to the DEFER default body so it can be identified as a unassigned DEFERed word when used. Then IS alters the PFA (Or is it CFA... I'm tired... been up late... :) when IS is used to define the DEFERed word's actual function. With the old way, you also end up paying the penalty of the extra bytes of code in the dictionary for the variable reference, the call to @, and then EXECUTE- not to mention the overhead for the respective calls to NEXT that need to be made in adition to the time consumed by each word's execution... DEFER is far more efficient memory and speed-wise. It's not a matter of adding another word to the definition of the BASIS, but a matter of whether or not it's needed! A question to the minimalist camp- do you wish to sacrifice some more precious speed and memory (Sorry, memory and code performance are still an issue to be dealt with in implementations- just because we now have machines that use megabytes of memory and are blindingly fast that we should piffle any of it away just because we want to make the language simpler and can get away with it now... What about later???) to satisfy the need to keep everything to an absolute minimum even when the word DOESN'T have to be in CORE or EXTENDED- CORE? This is a VERY useful word and should be an optional word in the standard's definition just to keep it consistant with all implementations. (I hope that the minimalist members realize that there WILL be DEFERs out there for all commercial Forths- it's just too effective and fits in with the standard's dictionary structure. I'd rather standardise that and make sure that everyone plays by the same rules- if they don't want that on the basis that it can be defined portably, then I'd like to ask them, "Why *BOTHER* with making an ANSI standard anyway?" This is because this is the past and current attitude about some key things in the definition of Forth as a language and it's part of what is hindering it's spread to the industry...) >but I can't stand up and make a strong case that the old way is totally >horrible, or that the DEFER way gives you any inherent capability that >the old way doesn't have. I have to agree with the claim that DEFER >is just "syntactic sugar", and not additional functionality. See my statement above- it isn't syntactic sugar... It usually does add functionality (Unless you have got DEFER defined differently than I have seen in other Forths... ;-) >Please do; I will be happy to argue your position to the TC. I like >DEFER quite a bit, and I use it frequently. However, I can guarantee >you that the minimalist camp is well represented on the committee, and >it will be a hard sell. So what else is new... :-) If I don't "complain"- anything that I don't like in the language will truly be my own fault; I did nothing to fix the problem... I'll be formulating my comments when I get BASIS15 converted to human readble format... (A day or so at the most... :) (I think I'll get off of my soapbox now... :-> Thanks for your reply Mitch, Frank