was unsure as to where to put it, so I put it in extra. Also the word could be renamed to something better...

Just out of curiosity, what is your use case for this? It looks similar to the interface for writing unit tests in a way.

Maybe this should be added to the test vocab then?

Ah sorry. I was under the impression that you use it for unit testing in the end.

I'm going to add one more word that I wrote some time ago, its a bit similar.
Given an array of words (for example: produced by \ palindrome? definition)
it will execute those words and show any intermediary values, as a form of super simple printf debugging.

The help still has "before-word" but the actual word is "before-after".
What about "visualize-results" or "gather-results" instead of "test-word" ?
And "gather-intermediates" for "before-after" ?

To me, this is a good tool for visualizing results when you don't really know what you want and are exploring (otherwise, unit tests are superior because they are silent when they work and check results)

Hmm, the property-based testing seems to be harder than I expected.

[ xor ] infer in>> length

I can use the above to figure out if a word is unary, binary or ternary (ie how many inputs it takes).

{ 1 2 3 4 5 } 1 all-selections . ! for unary number words
{ 1 2 3 4 5 } 2 all-selections . ! for binary number words

There's three obstacles I don't know how to solve:

1. In the above example, for words with 2 inputs, we expect the word to have 2 inputs of the same class
   If we instead have for example remove-nth ( n seq -- seq' ) which expects 2 inputs with different classes,
   then the following would not work, because sometimes we would get n seq and sometimes seq n (also n n and seq seq)

{ 0 "a"  } 2 all-selections

So the above problem was how to generate possible inputs, while taking into account situations where stack order matters
The second problem is:

2. I don't know if its possible to figure out from infer's output the appropriate class for the inputs of a word.

[ xor ] infer in>> ! outputs an array containing the strings "x" "x"

"x" could be anything, not necessarily a number, and I think this has to do with the fact that factor is dynamically typed.

3. There's a random numbers generator, but in true property testing you would have a random array generator, random string generator, etc.

Summary: my guess is that from the stack effect of a word, there isn't an easy way to generate possible inputs for that word,
this is something that has to be done by hand, although I'll mention in the docs a few examples as how to do this :)

Could you replace "quote" with "quotation" in the documentation?

these seem to be extension of with-datastack, so with that in mind i have these ideas:

• change vocab to continuations.extras
• rename gather-results to with-datastacks
• rename gather-intermediates to datastack-states, or something similar.

@razetime sounds good to me!