Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!pacbell.com!att!ucbvax!ENG.SUN.COM!wmb
From: wmb@ENG.SUN.COM
Newsgroups: comp.lang.forth
Subject: DEFER
Message-ID: <9104121341.AA17283@ucbvax.Berkeley.EDU>
Date: 11 Apr 91 16:08:23 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: wmb%ENG.SUN.COM@SCFVM.GSFC.NASA.GOV
Organization: The Internet
Lines: 36

> >     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