Compatibility changes & Leopard serialization polish

[towerofnix]

This pull request does... a whole lot!!! Sorry, not sorry, I usually don't do monolithic PRs but sometimes you gotta take what you can get. 👻

This PR builds off of #89. To isolate this PR's changes before that PR is merged: https://github.com/towerofnix/sb-edit/compare/var-ids...towerofnix:sb-edit:compat

• Continues from #89
• Depends on leopard-js/leopard#157
• Depends on leopard-js/leopard#159
• Depends on leopard-js/leopard#161
• Fixes #60
• Fixes #87
• Fixes #88
• Fixes leopard-js/leopard#156
• Resolves leopard-js/leopard#58
• A whole host of other changes and legibility improvements, see below!

Major changes summarized:

• New desiredInputShape feature exists so that inputs are casted as needed (improves Scratch compatibility) and can be mutated from within blockToJs, providing custom equivalent-behavior forms to improve code legibility.
  • Possible values: any, index, number, string, boolean, stack (all strings)
  • The block-to-source map is refactored to set a new blockSource variable instead of returning right away.
  • Each entry in block-to-source map also sets the kind of input shape it naturally satisfies, e.g. math blocks always satisfy "number", conditionals always satisfy "boolean".
  • If a block satisfies the desired input type, its source text is returned as-is. Otherwise, it's wrapped with a casting function.
  • Special handling for index desired input shape (which is for use in list and string indexing):
  • Works by changing satisfiesInputShape to index (instead of number) if it was specially handled
  • operator_add: If one of the values is a number and not a block (right-hand preferred), it is decremented by one, e.g. this.vars.list[this.vars.i + 1] instead of this.vars.list[this.vars.i + 2 - 1]; if the decremented value is just zero, returns the other side as-is, e.g. this.vars.list[this.vars.i] instead of this.vars.i + 1 - 1]
  • data_itemnumoflist: Does not do + 1 if the desired input shape is index, e.g. this.vars.list[this.vars.indexOf(this.vars.foo)] = 42 instead of this.vars.list[this.vars.indexOf(this.vars.foo) + 1 - 1] = 42
  • Generic numbers: Decremented by 1 if the desired input shape is index, e.g. this.vars.list[0] instead of this.vars.list[1 - 1]
  • Some inputs may be more stringent than necessary for Leopard's purposes, e.g. it's possible this.goto and this.glide will work even if the input hasn't been casted to number, and so on. This could use some more investigation.
• Use new this.compare() Leopard-provided function for comparisons when needed
  • Analogous to scratch-vm's Cast.compare function, implementation based on @apple502j's optimized code: https://github.com/LLK/scratch-vm/pull/2580
  • Aiming for compatibility, this is always used for greater-than and less-than. This can probably be avoided when comparing against strings, but Scratch will treat numbers as strings (for the sake of comparison) if either side can't be parsed as a number, which makes using > or < for numbers awkward.
  • Easier to get away for equality comparisons: if either side is a static string or number, we cast the other side to the appropriate type and perform a strict equality check (===). I'm not sure this is exactly correct 100.00% of the time (particularly if Infinity is involved), but it should cover the vast majority of use cases.
  • Future work: x === y could be converted to x !== y instead of !(x === y)
• Use new increase() and decrease() "macros" for common operations, so that ++, --, +=, and -= are all used as appropriate, instead of always using +=
  • ++ and -- are disabled in most instances (only used for data_setvariableto and next costume/backdrop blocks), since they don't really fit the "feel" of changing tangible values — this matches existing Leopard behavior while allowing for this.vars.i++, which should feel more appropriate when treating variables as abstract data
• Remove "branch" behavior from uniqueNameGenerator and just spawn totally new generators when it makes sense
  • This fixes a serious legibility issue where sprite-local variables (and custom block arguments!) were being generated with unique names across the entire project, e.g. this.vars.i, this.vars.i2 ... this.vars.i12, this.vars.i13 if you had 13 sprites with variables named i!
  • There didn't seem to be any issues resulting from this change — we store generated unique names on a project-wide map, so accessing a variable from another sprite (with sensing_of) still works fine. There's no possibility for names to be duplicated within the same namespace!
  • I think this is what the "branch" behavior was probably supposed to do from the start, but it didn't actually accomplish that. It's simpler to just create fresh name generators when needed.
• Miscellaneous compatibility changes
  • data_itemoflist and operator_letter_of use the new helper functions to return an empty string when the index is out of range
  • operator_contains, data_itemnumoflist, and data_listcontainsitem use new helper functions for compatibility (parity with scratch-vm Cast.compare, most notably these are all case-insensitive)
  • operator_mathop uses new helper function for "tan" operation, Scratch has a custom implementation
  • Reserved name lists have been greatly expanded, newly including reserved names at the module/global-level too (e.g. Costume, Sprite) — sprite names can't conflict with these!
  • When identifiers aren't on a namespace (like this or this.vars), we also include a list of reserved JavaScript words — this avoids issues with custom block arguments with JS-reserved names such as function or class.
  • Target.blocks was dubiously "flat" before, but only one level deep (e.g. "repeat 10" under a "forever" loop, but not "turn 15 degrees" under that "repeat 10"). This has been fixed, which is a sb-edit format change, but since this property seemed to be intended to flatten scripts in the first place, it seems more like a bug fix than a breaking interface change.
  • This fixes nested "show/hide variable/list" blocks being missed when determining which variables have watchers that get dynamically shown/hidden at runtime.
  • For variable watchers, slider min/max and step are now passed through the watcher constructor.
  • step is 1 if "discrete", 0.01 otherwise. Scratch's default is discrete, only non-discrete if at least one of the bounds is written as a decimal e.g. 1.00 — this is conveniently serialized info scratch-vm makes directly available instead of having to parse sliderMin/sliderMax ourselves (which is a number, not a string, anyway).

This is a pretty big PR, but by covering a lot of ground, it should go a long way to make the output of Leopard more legible and usable as an actual basis for starting new projects from. This is what you get when I'm recovering from a cold and don't have anything better to do ^_^ (Except... sleep? It's almost 1AM? Oh, I'll hear none of that! 💤)

Same as in the other PR: @adroitwhiz I've added you as a reviewer if you'd like to! If you're not interested or don't currently have the time, feel free to pass. 👾✨

[adroitwhiz]

I'll try to take a look at this later today. Would you mind rebasing it on top of the main branch since #89 is merged?

EDIT: I can also rebase it and push onto your branch if that's easier

[towerofnix]

Rebase done!

[towerofnix]

All PR's approved so this is good to go! 🚀