Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!tut.cis.ohio-state.edu!ucbvax!BRFAPESP.BITNET!UNBCIC
From: UNBCIC@BRFAPESP.BITNET
Newsgroups: comp.lang.forth
Subject: Problems with DOES>
Message-ID: <9105081518.AA01120@ucbvax.Berkeley.EDU>
Date: 8 May 91 12:31:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: UNBCIC%BRFAPESP.BITNET@SCFVM.GSFC.NASA.GOV
Organization: The Internet
Lines: 39

From: Jan Stout <wsbusup4@urc.tue.nl>
=> I think you missed the point. The point is DOES> does the >BODY at
=> 'compiletime', whereas it should be done at 'runtime'.
=> I.e.:
=>
=> : ARRAY ( n -- )
=>    CREATE DUP 1- ,    1+ CELLS ALLOT
=>    DOES ( -- execution token)
=>    ;
=> : A@ ( ex token of an array\index -- value at index )
=>    SWAP >BODY TUCK @ MIN ( simple overflow check )
=>    1+ CELLS +   @ ;
=>
=> ( May contain typos, just hacked this together:)

Sorry, but I didn't understand wether DOES> doing >BODY compile time instead of
at run time should cause any problem.

=>
=> As to your suggestion of using virtual addresses,
=> this seems breaking code to me. PFA's have always
=> been @d & !d like regular addresses, so your proposal
=> would mean that I'd have to use VIRTUAL@ / VIRTUAL!
=> to obtain the extra level of indirection, not normally
=> needed in the @ / ! case.

No. It's just like the @ / ! of Forth-83 in a computer with data alignment
restrictions. If the memory is alocated dynamically, then @, instead of
searching the physical address, would search and address that corresponds to
the token (address) on the stack. The user just don't know that it's working
this way (if he's really using the Standard). It's slower, but the
implementation where DOES> have problems (and I think DOES have problems in
this implementations too) is slow by default.

=> Jan Stout,

                              (8-DCS)
Daniel C. Sobral
UNBCIC@BRFAPESP.BITNET