Note: This was originally posted in another thread about things people might want to do with parse events, but discussing the needs of this particular tool warrants its own thread.
Because debugging parse rules can be painful, I created a Rebol 2 visual parse debugger of sorts (parse-analysis-view.r). Parse events are needed to track the input position and log each rule's Test, Succeed, or Fail. The events were mapped to screen coordinates to be able to step forwards/backwards through the parse steps and to be able to find the active rules under a mouse cursor position. Mapping strings was easy, mapping block input was a pain.
Running the visual debugger thing:
visualise-parse t j/grammar [parse/all t j/grammar/json]
I fiddled with it for 10 minutes and it didn't immediately work the way I thought...at least the generating sample input didn't. If someone else can fiddle and report on it for me that would be helpful.
(So @Brett, if you can kind of tinker with it and explain the difference between what they're doing and what you did, I'm sure it would be illuminating.)
But because DiaGrammar is not open source we don't have immediate access to whether it uses that. And because Red isn't LGPL'd we don't know what kind of hacked up version of Red they have; it's not a proof of what the language itself is capable of as pitched.
(I explained my rationale behind LGPL'ing Ren-C a year ago. People shouldn't look at it as "restricting their rights" to distribute their binaries without source... but rather as making a promise, that Ren-C won't be enhanced and folded into some project without letting you know what's going on...leaving those who've bought in without support...)
Well this is why they have to cut features in PARSE. If it had too many features it would be too slow to run in a loop.
If programming history looks back on them and scoffs, they can't say I didn't warn them...
I think the slow-and-steady scrutiny of things piece-by-piece is really the only way to get to the future vs. repeat the past.
And I'm not giving up on Ren-C. In fact, I just got back to my coding bunker after a couple months of enjoying what will likely be a narrow window of coronavirus freedom. I will be digging in for the rest of the year, seeing how much I can get done.
Would be something it would be possible to integrate the Wasm build with...
(BTW: The approach I suggest above is showing some real promise, but while writing the prototype for it I got stuck on some bugs...so I'm going back and doing some needed toughening on the code before continuing to tackle it.)
I'm a bit confused because I thought Red offered some kind of events back from PARSE as callbacks and this would be based on that, but I see no indication that the call to PARSE uses the /TRACE refinement. Without an in-depth analysis of uncommented code, I assume it's probably using methods that parallel parse-analysis-view.r.
There's one comment, about needing to "extract the names":
;; I haven't found any other way to extract the names
;; I tried collecting first words of the 'fetch' event,|
;; but sometimes it may be at 'opt name' and who knows what other cases are possible
Similar, though if I've understood on my brief glance, it looks like it's attempting to scan the rules to track events. I went with the dumber/simpler/possibly less fragile - let the user decide which rules to track and wrap those to create the event tracking.