CREATE> DOES and VOCABULARY

[mitra42]

• [x] Define DOES
• [ ] Test it
• [ ] Implement VOCABULARY words as CREATE> DOES - won't do - see #35
• [ ] Look at "FORTH" the first word in dic, can it be CREATE> DOES - see #35

[mitra42]

References https://www.taygeta.com/forth/dpans6.htm#6.1.1250 DOES> https://www.taygeta.com/forth/dpansa6.htm#A.6.1.1250

[mitra42]

This is hard lets take two (artifiically simple) examples.

: VARIABLE CREATE 1 CELLS ALLOT ;   VARIABLE foo
: CONSTANT CREATE , DOES> @ ; 10 CONSTANT ten

• CREATE creates a new definition with a token that puts the data field (next word of the code) on the stack.
• In the VARIABLE case, all that ends up on the stack is the pointer to the uninitialized data field
• In the CONSTANT case, it takes a cell 10 off the stack and compiles into the code
• and then the DOES> is passed the address of that field, and dereferences it.

This isn't so hard if direct code is being used, a call to the "CREATE" routine is replaced with a call to the DOES> code, but with indirect or token threaded code the problem is where to specifiy where that code is.

I see two possibilities a: For each DOES> create a new function which encapsulates the address of the DOES in the function, store it in jsFunctions.

The con for this is that the number of jsFunctions grows with each defining word and that we have addresses of dictionary appearing in Javascript functions.

b: Have create always compile two cells, the first being a token for CREATE and second being the address (xt) of the definition. So the definition : VARIABLE CREATE 1 CELLS ALLOT becomes identical to : VARIABLE CREATE 1 CELLS ALLOT DOES> ;

I'm going to go with that 2nd definition even though it breaks with the eForth model, (which is strangely missing DOES>)

[mitra42]

Above is working - still need to do Vocabulary