enhance minifier

[Rudxain]

Closes #2

• memory simulator: includes "+/- x 256 removal" (modular normalizer), "mutual-cancel", and "+/- swapper"
• remove all ops after final . or , or ]
• cell-reset canonicalization
• cell-reset-after-mut recognizer (+++[-] -> [-])
• zero-before-loop elimination: includes consecutive loops
• infinite-loop tail-elimination
• compressor optimizer

[Rudxain]

I got kinda "mentally-blocked" at this point, so I'll write pseudo-code, then translate to Go. I think doing that might help me solve the algorithm faster

[Rudxain]

Thank you (everyone reading this) for your patience. I'm sorry for "abandoning" this project. Since I had to reinstall my OS, I didn't find time to install the Golang toolchain. I'll be back in ~2 months, if everything goes fine IRL (please read my profile for context)

[baris-inandi]

No problem!

Thank you (everyone reading this) for your patience. I'm sorry for "abandoning" this project. Since I had to reinstall my OS, I didn't find time to install the Golang toolchain. I'll be back in ~2 months, if everything goes fine IRL (please read my profile for context)

[Rudxain]

Now that bfgo has support for loading "memory-dumps", some of the minifier's assumptions would be broken (such as zero-loop). I propose we add optimization levels (like a compiler). Here's a draft:
8841359#diff-4f57800896f6b4699135c679b590fb527c150c8510ce43909cb15c0d7b0e46d4R12-R34

I want to branch that into its own PR, as this PR is already blocking on multiple features

[baris-inandi]

As I mentioned in the updates at #5, I added -mem to debug bf.style. Initially, I thought it could be a feature on its own. However, since it is interpreter-only and that it does not really add much to the toolkit, I will remove it.

If we add bf.style inside bfgo, I will use memory-dumping internally without exposing the feature to the user so that the minifier is not affected. The -mem flag should be removed from main soon. Once I commit the change, the new minifier's initial assumptions will continue to be valid.

[Rudxain]

oh ok. But still, I believe it'll be useful to have (at least) 2 minification levels (main & lib), since not all BF code is meant to be executed as-is, but rather copy-pasted (inlined) into other programs.

Loading/dumping mem can be useful for users who want to debug their code, although REPL seems to be enough for simple cases, and there's websites that provide full-blown debuggers (even stepping!), so I agree with not implementing mem

[baris-inandi]

Memory-dumping is removed at main!

[Rudxain]

I got a new optimization idea! I named it "infinite-loop tail-elimination" (I added it to the task-list):

It consists of recognizing "obvious" ♾️-loops of the form [🧠] +0xff [.], where 🧠 is literally any arbitrary code, +0xff is (+/-)<256 times (assuming the mem-sim already normalized them), and . is repeated 0-or-more times.

If the +0xff[.] is at the very beginning of the main (not lib) program, then it's also assumed to be inf.

This allows the minifier to do transformations like these [ [>] + [...] + [>,] ] -> [[>]+[...]] (unreachable code elimination). We can't always remove the outer loop, because it may (indirectly) conditionally-execute the inf-loop, so we gotta be conservative here