Well... I've hacked it up to get it to look like the proposal. It's raised some questions (including ones that are known and have discussions here, especially pertaining to binding).
But it's rather cool. And now the ren-c variant runs in the ReplPad without redbol:
>> do https://github.com/hostilefork/whitespacers/blob/master/ren-c/whitespace.reb
I did the changes in individual commits in the git log, corresponding to the points I raised. So you can sort of follow along, and I think it would be illuminating to take a look at each phase--even if some behind-the-scenes parts look like gibberish (for now):
-
First I introduced CATEGORY and OPERATION as simple aliases for MAKE OBJECT!, as a start to putting some running code that could give smarts to the definition (instead of just being inert literal blocks).
-
Then I got rid of the repetition of
command:anddescription:in each definition. Instead it assumes the block will have a string in the first position (the description) and everything else makes up the command array. -
Next was moving the code for the behavior for each operation to live with the operation. This was to start merging it together so that OPERATION would really just be a fancy way of defining a function plus more auxiliary information. (The function parameterization wasn't exactly consistent, so I had to fix that up)
-
Another essential step was auto-generating the PARSE rules from the operation and category specs. This is simpler than it looks.
-
And to finish off how much I can do before sleeping, I fused the parameter definition for the behavior function in with the whitespace instruction definiton. So the sequence of opcode characters is right in line with the spec of the argument that is expected to be encoded in more characters after it to form the rest of an instruction.
There's a lot of ugly hacking to get here, so it's going to need cleanup and more pushing on system features to make this work. But if it were easy to make something that blended source fragments together in this style and have it still run, some other language would have done it.
Let me know if any of the above is confusing or makes sense, @razetime. Note that if you're reading a diff on GitHub, you can click on the diff line and comment directly on it... to ask questions or make remarks. Please don't hesitate to do so if you have anything to ask or suggest...it's not spam, it's desperately needed peer review and commentary.
(I continue to hope that the "Minecraft of Programming" vision emerges from the process and line of thinking. The code for defining OPERATION and CATEGORY themselves is a lot uglier than I'd like, and we have to keep fiddling with that until it can make clear sense. But the fact that it's even possible to write--and make the usages of operation and category look that natural--shows the goalposts.)
Note: I used the term "Instruction" for the aggregate of the whitespace opcode plus its arguments (which I form as a BLOCK! in the runtime). Then "Operation" for the name like push or jump-if-zero, based on precedent from assembly language. The sequence of ASCII chars is still the "Command" for now due to the term being in the whitespace spec, though I guess that could change, possibly to "opcode"? I think terminology is important, so this should all be nailed down and used consistently...