Random Word Generator (Markov Chain)

Hey there!
I was check this that is very in interesting. I want to create a word combiner for my personal use.
Please tell me how to build it .
waiting response.

You should be using "script variables" instead of "block variables" here. Block variables are, uh, well, I don't understand why they're there really, but they're shared across all invocations of the script, so there will be issues if you use them in custom blocks or run multiple instances of the same script. :slight_smile:

Other than that, it's interesting, but the results don't really look like English words. You might want to make it more sophisticated, maybe by using two preceding letters instead of just one?

block variables store the progress the block has made

its not perfect, I haven't worked on this in a long time

Not quite. They're shared across all invocations of this particular physical copy of the script. So this works as expected:
untitled script pic (1)
untitled script pic (2) untitled script pic (3)
The letter input to COUNTER is just for clarity; what matters is that it's two separate copies of the COUNTER block.

This could go in a separate topic, but I'd love to know the motivation behind block variables and why they behave the way they do. It does not strike me as intuitive or even useful in the slightest!

Jens designed this feature with applications like COUNTER, above, in mind. Chapter VIII of the manual describes the official (i.e., taken from Scheme) way to build persistent local state into a block. But that way requires you to put the block you want to run in a variable and use CALL or RUN on it. (It works better in Scheme because it's a Lisp-1 (single namespace for all named things) and we're a Lisp-2 (separate namespaces for procedures vs. other things).)Block variables solve a simple subset of persistent local state problems, in a way that meshes better with our UI for invoking blocks. In a perfect world, putting a procedure in a variable would change the appearance of that variable's accessor block to look like a command or reporter as applicable, and the block could then be dragged into a script. But there are reasons we can't really do that.

Block variables thrive in a concurrent system. Here's one of my guiding examples:

How would you detect changes to a shared variable across several processes? You would need to keep track of the old value in a separate (global!) variable per process. That's what block instance variables abstract away: They offer a thread safe mechanism to keep track of thread relevant information.

But local block variables are rather call site bound than the thread/proces.
local script pic (3)
local script pic (1)

And are persistent in a slightly uncontrollable manner. If you D&D this expression, it will carry its values.

I found another use case to store internal state of the libraries without cluttering the variables space.
simple reporter
untitled script pic (4)
untitled script pic (7)
reporter with side effect of a setter
untitled script pic (3)

cool, I like it