masak
Try running on the Bel reader
This one doesn't have to lead to a merge; I suspect it will be too slow right now. (Since interpreted Bel code is slower than the hand-written Perl code in the reader.)
Still, it might be interesting to know (a) how much slower, and (b) if maybe something falls out from it.
For one thing, there could be a tantalizing test file that we could write in that un-merged branch with tests for extending the reader during a REPL session, and having it be picked up immediately in the next command. (!) Then we could save that test file for later, when we are able to do this, and run natively on a Bel reader.
Preliminary results:
- Slower: fsh'yeah. Still running the test suite, 75 minutes and counting.
- But more interesting: the reader is more discerning, and has so far found two cases of missing
), which the old reader ignores.
If nothing else, we can re-integrate fixes to those test cases back into master.
Another interesting tidbit: the something connected with the new reader works in bytes, not characters. And so (rdex (list (wrap "hi" \¦))) fails, because it contains a ¦ character.
I remember adding a small exception for that in the old reader. But a more concerted, UTF-8-y approach would be better.
Another interesting tidbit: the something connected with the new reader works in bytes, not characters. And so
(rdex (list (wrap "hi" \¦)))fails, because it contains a¦character.
Now reported as #266.
As reported in this blog post, the total running time ended up being 11 h 30 m. (!)
Before I close this issue as a successful experiment, I'd like to try one more thing that might potentially speed up the reader — although likely not to speeds that will make me eager to merge it. Namely, we can add a special-cased "fast type" specifically for a Bel string that wraps a Perl string. That way, work doesn't have to go into spooling the Bel programs from Perl strings to Bel strings; I'd be curious to try this just to see what the time reduction would be.
As an added bonus, if the new type ends up being a time saver in the rest of the test suite, maybe we keep it. :smile: It's quite closely related to #144.