[comp.lang.forth] Problems with DOES>

UNBCIC@BRFAPESP.BITNET (05/06/91)

The PFA cannot be changed. For example, if we create a set of words
to implement STRUCTs (RECORDs), they should leave the address of the field,
an address inside PFA (maybe PFA). This address would be used for ! or @.
But in the mean time, an garbage collection could ocurr, changing the PFA
address, scrambling with the program. Alas, you couldn't use the PFA in
any case, if PFA could change.

This mean that HEAP systems, with garbage collection, couldn't be used? No.
But the PFA should then be implemented as a virtual address, not a physical
one.

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

UNBCIC@BRFAPESP.BITNET (05/08/91)

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