My last code used CONSTANT . It wasn't really testing the issue of twins
being automatically bypassed because the optimizer changes them to equates.
I redid my test with variables and got similar results. The danger present
is not regarding the bypassing of twin creation due to existence of a
like-named word in the host. The behavioral difference in try1 is really
due to search order. Interpretive order looks in the host vocabulary (
FORTH ) before the twin vocabulary (*EQUATES/*INTERPRETER?). That is why
the host 0 is returned instead of target address. A twin is still created
but its existence is deeper in the search order. So, sorry for tossing your
mind from danger of twins not being created due to the existence of host
words with the same name-- not the case. My coworker found that the
auto-bypass of twin creating is sound, via 'TWIN . The lesson for me: keep
search order in mind!
________________________________________
c:\temp\temp.f source:

host
: try1 0 ;
\ ...
\ really big app
\ ...

target
variable try1
variable try2

CR

interpreter
try1 . CR
try2 . CR

target
try1 . CR
try2 . CR

________________________________________
SwiftX output:

include c:\temp\temp.f
0
2302060
2302056
2302060
 ok
----------------------------------------------------------------------
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.
Received on Fri Jan 25 2002 - 09:02:25 PST