A little late getting this out...it was "lost" in my drafts folder!

On Wed, 27 Mar 2002, Elizabeth D. Rather wrote:

> :NONAME isn't relevant in a SwiftX environment, where names are
> kept only on the host in any case. This solution is fine. IMO my
> version with the table is a little more efficient, but either will work.

Leon and I have been around this a few times. He hates the idea of
unnamed words; I have found them useful at times. Regardless, :NONAME
is a terrible thing by ANS design, since its stack effect is ( -- xt ).
It is difficult to implement this properly, and tends to have subtle
problems as shown below.

Try this on a system that has it:

34
:NONAME ( -- ) LITERAL . ;

If the xt from :NONAME is left on the parameter stack at
compile-time, then LITERAL will compile the :NONAME xt instead of
34. Then 34 is returned as the value to EXECUTE. Oops.

I have seen this "worked around" by :NONAME doing
   ( xt) >R ] R>
That solves the problem above. But then, this breaks (unless a
separate stack is used for compiling conditionals):

:NONAME ( n -- n' ) DUP 0> IF [ HEX ] 20 + [ DECIMAL ] THEN ;

The xt shows up on the parameter stack after the first [ at
compile-time, and then the conditional isn't compiled properly--THEN
resolves the :NONAME xt instead of the address IF left for it!

Granted, these examples are somewhat contrived. I don't recall what
in particular caused me to discover these issues. Nevertheless,
IMHO, :NONAME is best avoided.

> FORTH, Inc. doesn't support "forward references" in any of our
> products, because it's been our experience that this is a very
> bug-prone practice that should be avoided.

Hmmm...a DEFER is effectively a forward reference. But forward
references in Forth are a bad idea nonetheless, and should be used
very sparingly--preferably, not at all. Global forward references
are particularly nasty.

I recently revisited some Forth code I'd written several years ago
when the app was ported from chipFORTH to SwiftX, and had the
opportunity to painfully learn the consequences of too many forward
references. The forward references in the code, although relatively
few, made the porting task *much* more difficult, since the forward
references hadn't been ported yet, and thus didn't provide the
essential services they were needed for. When you depend on things
being in place and working "early", it can cost you your biggest
Forth advantage, namely being able to incrementally load and debug
your application.

--
Ron Oliver <roliver_at_openesque.com>
----------------------------------------------------------------------
swiftx_at_forth.com          The SwiftX programming discussion email list
To unsubscribe,  send subject "unsubscribe swiftx" to listar_at_forth.com
For help with listar commands, send subject "help" to listar_at_forth.com
Archives are located at http://www.forth.com/swiftx -- check them out!
----------------------------------------------------------------------
THIS LIST IS NOT FOR BUG REPORTS!  Send bug reports to support_at_forth.com.