wmb@ENG.SUN.COM (04/09/91)
>>> Is there DEFER in BASIS 15. >>> >>No. I proposed it at the last meeting, but the proposal was defeated 3-8. >> > Mitch, how does the standards team propose to handle vectored execution > and forward compilation in a clean and easy manner, while also doing it in a > standard manner? 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 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. > (Read: This *WILL* be a portion of my comments to the TC) 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. Mitch Bradley, wmb@Eng.Sun.COM
S47852EF@ETSUACAD.BITNET ("Frank C. Earl") (04/10/91)
On Mon, 8 Apr 91 22:09:45 EDT <wmb@ENG.SUN.COM> 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
wmb@ENG.SUN.COM (04/11/91)
> > VARIABLE 'FOO : FOO 'FOO @ EXECUTE ; > Ugly... And it's a bit more than a bit more trouble (?? :-)... > ... paying the penalty of the extra bytes of code in the dictionary > for the variable reference, the call to @, and then EXECUTE ... > overhead for the respective calls to NEXT > DEFER is far more efficient memory and speed-wise. Frank, I think you are blowing this out of proportion. There is indeed some extra overhead with the "old" way, but it's rarely significant, especially considering that most applications use only a few defer words at most. The run time of most applications is dominated by a "bottleneck" somewhere, and I don't recall ever having seen one where the bottleneck was the time it took to indirect through an execution vector. As I have said, I like DEFER and use it, but I have to be realistic about its true value. I think it would be a worthwhile word to have in the standard, but not because of space and time considerations, but because a lot of people already use it, and standardizing widely-used words enhances the portability of Forth programmers. > there WILL be DEFERs out there for all commercial Forths Actually, I doubt that this is true. I think that, at present, it is mostly public-domain Forths, particular F83 and F-PC, that have DEFER. Among systems that do have DEFER, there is some variation in the mechanism for setting its value. > It usually does add functionality My definition of "adds functionality" is "let's you do something that you couldn't do before". This is different from "easier" or "prettier" or "more convenient" or "more efficient" or "popular". All of those other things can be quite valuable, and I am happy to argue for DEFER on those grounds, but I can't honestly apply the "functionality" argument to DEFER. Mitch Bradley, wmb@Eng.Sun.COM
Mitch.Bradley@ENG.SUN.COM (04/19/91)
> Hmmm.... CORE EXTENTION WORDSET (You getting this Mitch? :) Yep. You're preaching to the choir. Remember, I actually proposed DEFER at the last meeting. > The minimalists shouldn't complain about adding onto the CORE > EXTENTION WORDSET as it is an OPTIONAL word then Unfortunately, "shouldn't" isn't the same as "didn't". I proposed it for the CORE EXTENSION wordset. It got shot down. If you guys (and I'm speaking to everybody on ForthNet) really want DEFER, the thing to do is to write to ANSI during the public review period and say you want it. The committee can't ignore a whole pile of outside pleas for the same thing (unless they are balanced by a whole pile of outside pleas saying they explicitly DON'T want the same thing). I'll be happy to carry the flag, but I can't go it alone. Without written support (and paper carries a lot more weight than email), it will just be Mitch's pet word and it will get shot down just like it did last month. Mitch Bradley, wmb@Eng.Sun.COM
S47852EF@ETSUACAD.BITNET (Frank Earl) (04/23/91)
On Thu, 18 Apr 91 22:41:19 EDT <Mitch.Bradley@ENG.SUN.COM> said: >> The minimalists shouldn't complain about adding onto the CORE >> EXTENTION WORDSET as it is an OPTIONAL word then > >Unfortunately, "shouldn't" isn't the same as "didn't". I proposed it >for the CORE EXTENSION wordset. It got shot down. Geez... (I kinda guessed that was where you'd propose it go... :) It's not like you were proposing to enlarge the CORE.... :> >I'll be happy to carry the flag, but I can't go it alone. Without written >support (and paper carries a lot more weight than email), it will just >be Mitch's pet word and it will get shot down just like it did last month. As soon as I formulate my comment- they'll get it when it goes to public review time! And this *IS* one of those things I'll comment on... Frank <s47852ef@etsuacad.etsu.edu>